Dr. Ralph R. Young Director of Software Engineering Systems and Process Engineering Northrop Grumman Information Technol

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

2. What is a Practical Requirements Engineering Approach? Systems Engineering and Program Management WorkshopHow 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.

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

5. Systems Engineering and Program Management WorkshopHow to Implement a Practical Requirements Engineering Approach 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.

6. Systems Engineering and Program Management WorkshopHow to Implement a Practical Requirements Engineering Approach 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 WorkshopHow 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 WorkshopHow 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.