1. Dr. Ralph R. Young Director of Software Engineering Systems and Process Engineering Northrop Grumman Information Technology young_ralph@prc.com (703) 556-1030 How to Implement a Practical Requirements Engineering Approach

2. Systems Engineering and Program Management Workshop How to Implement a Practical Requirements Engineering Approach An organization should develop a requirements process and tailor it for use on each project. The requirements engineering process is a full system life cycle process. A lot of the issues and problems are created in the requirements gathering activities. –We can save a lot of time by addressing this area more effectively. Industry data supports this view (see next slide). –Further, doing a better job in requirements elicitation reduces rework downstream. Rework = 45% of total project effort, industry wide. –The requirements are often unknowable at the inception of many systems and projects. We need to recognize this and deal with it. A requirements tool should be used on every project. Tools don’t obviate the need for trained people, a requirements process, effective practices, and formal requirements training. Customer involvement throughout the project is essential. An incremental development approach works best when the requirements are evolving and changing. What is a Practical Requirements Engineering Approach?

4. Developer and Customer Tasks Amount of effort User requirements System requirements Architectural design Detailed design & component development Defining results for users Optimizing the cost- benefits Defining what the system must do Deciding on potential changes Customer work Developer work Provisional & final acceptance Acceptance, integration & verification Qualifying the design Verifying & validating the product Linking deliverables to requirements Storing and using knowledge from previous projects Informing the enterprise

5. Effective Requirements Practices: Obtain commitment. –Consider “Partnering Workshops.” –Have and use a “Requirements Policy.” Define the real customer needs and the real requirements. –Industry experience shows that the “stated requirements” are never adequate. –Consider utilizing a “Joint Team” to be responsible for the requirements. Use and continually improve a requirements process. Iterate the system requirements and architecture repeatedly. Control changes to requirements and new requirements. Select familiar methods. Maintain effective project communication. Maintain a set of work products that together describe the requirements. Perform requirements verification and validation. Use proven development practices. Systems Engineering and Program Management Workshop How to Implement a Practical Requirements Engineering Approach

6. Effective Requirements Gathering Practices: Interviews Document Analysis Brainstorming Requirements Workshops, including JAD Workshops Prototyping Use Cases Storyboards Interfaces Analysis Modeling Performance and Capacity Analysis Information Assurance

7. Systems Engineering and Program Management Workshop How to Implement a Practical Requirements Engineering Approach The Set of Work Products that might be considered the “Requirements Specification:” The database in your automated requirements tool –Provides “attributes” for each requirement The “Vision and Scope Document” for the project The Requirements Document and other lists or descriptions of requirements provided by the customers and users Lists of requirements met by related legacy (historical) systems The list of system-level (real) requirements evolved by the requirements manager/requirements analysts/engineers

8. Systems Engineering and Program Management Workshop How to Implement a Practical Requirements Engineering Approach Some Guidelines to Consider: Meet minimum requirements. Anything more is too much. Prioritize requirements. All requirements are not equal. Address top priority requirements in the initial release. Train requirements analysts/engineers: –Not to make requirements decisions. –Not to “gold plate.” –How to avoid common requirements problems (incorrect facts [49%], omitted requirements [29%], inconsistencies [13%], ambiguities [5%]). Conduct peer reviews of all work products. Document the rationale for each requirement (why it is needed)—this step alone can eliminate up to half of the stated requirements! A one-third change in the requirements equates to a doubling of the cost of the system. –Consider having versions/subsequent releases –Make concomitant changes in the budget and schedule An agreed-upon understanding of the system is critical to a successful project.