- Requirements Management. - 4.2.3.2 Requirements Specification Properties...6. - 4.3 REQUIREMENTS ENGINEERING CHECKLIST ...7. - Requirements define the purpose of a project and are the foundation of the project plan. - One of the primary reason software projects fail is because requirements are incomplete or incorrect. - [1] If the requirements are not done right, the project will probably fail, no matter what is done in subsequent phases. - Table 4-1 shows the relative costs of fixing software requirements defects in different phases of the project. - Whatever it may cost to do things right in the requirements phase, it will be 3 to 1000 times more costly to fix later if not done right.. - Requirements engineering is a sub-discipline of systems engineering. - This chapter presents an overview of require- ments and requirements engineering. - when the power switch is first turned to “On” the radio will perform the standard self-check routines.) [4] This is shown in Figure 4-1.. - The requirements engineering process is the primary work of the Requirements phase of the project, but it continues throughout the project to some degree because of requirements changes in later phases. - The second is requirements management, which is all other requirements activities which are not part of the development process. - Figure 4-2 shows the breakout of the major activities of requirements engi- neering.. - Requirements Engineering. - Elicitation Analysis Specification Validation Requirements Specification Requirements. - Figure 4-2 Requirements Engineering Process Overview [5]. - The process shows user needs being used to generate a Requirements Specification and a Requirements Traceability Matrix (RTM). - Each of the activities will be discussed greater de- tail.. - Confirm your understanding of requirements with the users.. - Synthesize appropriate statements of the requirements.. - The analysis process consists of developing a set of high-level requirements describing the functionality of the overall system, followed by a stepwise process of decomposing the higher-level requirements into succes- sively more detailed functional and nonfunctional re- quirements. - In addition to these levels there will probably be different sets of requirements developed for hardware, software, and the interfaces between them. - Specification is the documentation of the requirements developed through requirements analysis. - Requirements must be carefully worded to state clearly what is wanted. - Validation should not be confused with verification, which means to determine whether the product meets the requirements.. - Validation’s purpose is to ensure the requirements describe what the user really needs. - Once requirements are validated through a formal re- view process, the requirements specification becomes the baseline for all subsequent development and testing ac- tivities. - It also ensures that lower-level requirements have a higher-level source and have not been arbitrarily added to the scope of the project. - This effort generally employs some type of database tool and produces the requirements traceability matrix. - This process defines the requirements manage- ment activity and continues on throughout the remainder of the project. - The second responsibility of change management is to document the changes and make the appropriate updates to the requirements documents and databases. - 4.2.3 Requirements Specification. - The requirements specification is the primary product of the requirements phase, and the directing document for all development and testing efforts. - Fig- ure 4-4 shows the requirements specification broken out into a top-level system definition of specification, and three major subsystem specifications for hardware, software, and the interface between them. - Also shown are those de- velopment efforts that are directed by the software requirements specification. - Requirements Specification. - Figure 4-4 Requirements Specification and Follow-on Products. - In addition to dividing requirements into different system levels and different disciplines, the requirements specifi- cation should contain the following types of requirements and information:. - In software intensive systems these requirements may take the form of natural language, as well as making extensive use of entity relationship diagrams [8], data flow diagrams [9], or other software requirements specification meth- ods.. - The requirements specification should not include project requirements, designs, or product assurance plans (Con- figuration management plan, test plans, validation &. - 4.2.3.2 Requirements Specification Properties. - A good requirements specification should have the following properties: [10]. - The RTM consists of a database of requirements in a matrix format. - The arrows represent the flow down of requirements from higher levels to more detailed levels. - The circles contain the letter of the appendix in the RTM which traces the requirements between the two documents.. - 4.3 Requirements Engineering Checklist. - This checklist is provided to assist you in requirements engineering. - Have you had extensive user involvement in developing the requirements?. - Are all stakeholders satisfied with the requirements?. - Do the developers understand the requirements?. - Has design detail been left out of the requirements?. - Have the requirements been prioritized?. - Is the specification written so that it can be modified when necessary, with minimal impact to the rest of the document?. - Are you conducting formal and informal reviews of requirements documents?. - 4.3.2 Requirements Management. - Have all requirements been entered into the requirements database?. - Are the requirements traces sorted to allow requirements lookup by paragraph number, requirement number, or other useful index?. - Have you identified members of the requirements change board?. - Do you have a process in place to maintain and control the different versions of the requirements specifica- tion?. - DoDI 5000.2, Operation of the Defense Acquisition System, 4.6.1.1. - [1] The Standish Group, “The Scope of Software Development Project Failures,” 1995.. - [5] Wiegers, Karl E., “When Telepathy Won’t Do: Requirements Engineering Key Practices,” Cutter IT Journal, May 2000. - www.processimpact.com/articles/telepathy.html. - Ford, “Lecture Notes of Requirements Elicitation,” 1994:. - www.sei.cmu.edu/publications/documents/ems/94.em.010.html. - [7] Henderson, Lisa G.R., “Requirements Elicitation in Open-Source Programs”, Crosstalk, 2000, www.stsc.hill.af.mil/crosstalk/2000/jul/henderson.asp. - [8] SmartDraw, Entity Relationship Diagram tutorial: www.smartdraw.com/resources/centers/software/erd.htm [9] SmartDraw, Data Flow Diagram tutorial: www.smartdraw.com/resources/centers/software/dfd.htm. - www.sei.cmu.edu/publications/documents/92.reports/92.tr.012.html Crosstalk Magazine: www.stsc.hill.af.mil/crosstalk/. - www.stsc.hill.af.mil/crosstalk/1999/feb/wilson.asp. - “Experiences in the Adoption of Requirements Engineering Technologies”:. - www.stsc.hill.af.mil/crosstalk/1998/dec/cook.asp. - “An Examination of the Effects of Requirements Changes on Software Releases”:. - www.stsc.hill.af.mil/crosstalk/1998/dec/stark.asp. - “Doing Requirements Right the First Time”: www.stsc.hill.af.mil/CrossTalk/1998/dec/hammer.asp. - “Four Roads to Use Case Discovery”: www.stsc.hill.af.mil/CrossTalk/1998/dec/ham.asp. - www.stsc.hill.af.mil/CrossTalk/1998/dec/stark.asp. - www.stsc.hill.af.mil/CrossTalk/1998/dec/cook.asp. - “Recommended Requirements Gathering Practices”: www.stsc.hill.af.mil/crosstalk/2002/apr/young.asp. - “Making Requirements Management Work for You”: www.stsc.hill.af.mil/crosstalk/1999/apr/davis.asp Department of Energy (DOE) Software Engineering Methodology, Chapter 4: http://cio.doe.gov/sqse/sem_toc.htm Department of Energy, Software Risk Management Practical Guide: http://cio.doe.gov/sqse/pm_req.htm. - www.usdoj.gov/jmd/irm/lifecycle/table.htm IEEE Computer Society: http://computer.org. - 4th International Conference on Requirements Engineering (ICRE'00):. - 3rd International Conference on Requirements Engineering (ICRE'98):. - 2nd International Conference on Requirements Engineering (ICRE '96):. - http://computer.org/proceedings/icre/7252/7252toc.htm INCOSE Requirements Working Group: www.incose.org/rwg/. - “Characteristics of Good Requirements”: www.incose.org/rwg/goodreqs.html. - “Requirements Management Technology Overview”: www.incose.org/tools/reqsmgmt.html. - “What is a Requirement. - www.incose.org/rwg/what_is.html. - Available for download at: www.stsc.hill.af.mil/gsam/guid.asp Heimdahl and Associates, “Requirements Verification Checklist”:. - Hooks, Ivy F., “Why Johnny Can’t Write Requirements”: www.complianceautomation.com/papers/whyjohnny.htm Leffingwell, Dean A., “A Field Guide to Effective Requirements Management Under SEI's Capability Maturity. - Model”: www.rational.com/products/whitepapers/299.jsp Ludwig, J., Requirements management site: www.jiludwig.com. - http://www.dai-sho.com/pgsa2/index.html. - www.geia.org/sstc/G47/SWMgmtGuide%20Rev%200.4.doc. - Requirements Management Place, The: www.rmplace.org Requirements Generation System, Joint Chiefs of Staff:. - www.jsc.mil/jsce3/EMCSLSA/stdlib/cd/Added/3170_01b.pdf Wiegers, Karl E.,. - “10 Requirements Traps to Avoid”: www.processimpact.com/articles/reqtraps.html. - “Writing Quality Requirements”: www.processimpact.com/articles/qualreqs.html. - “First Things First: Prioritizing Requirements”: www.processimpact.com/articles/prioritizing.html. - “Automating Requirements Management”: www.processimpact.com/articles/rm_tools.html. - “In Search of Excellent Requirements”: http://www.processimpact.com/articles/exc_reqs.html. - “Habits of Effective Analysts”: www.processimpact.com/articles/analyst_habits.html
Xem thử không khả dụng, vui lòng xem tại trang nguồn hoặc xem
Tóm tắt