Dr. Ralph R. Young Director of Software Engineering PRC, Inc. young_ralph@prc.com (703) 556-1030

1. Fifth IEEE International Symposium on Requirements Engineering What If There’s No Time for Requirements Engineering? Dr. Ralph R. Young Director of Software Engineering PRC, Inc. young_ralph@prc.com (703) 556-1030

2. Things I’ve Noticed From My Requirements Engineering Experience Fifth IEEE International Symposium on Requirements EngineeringWhat If There’s No Time for Requirements Engineering? • Information and guidance concerning effective requirements practices is available but is not applied by most Project Managers. • Although 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. • Therefore, in my opinion, we can save a lot of time by addressing this area more effectively. Industry data supports this view. • 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. • Tools don’t obviate the need for people, a requirements process (in all situations), effective practices, and formal training. • Customer involvement throughout the project is essential. • An incremental development approach works best when the requirements are evolving and changing.

3. Fifth IEEE International Symposium on Requirements EngineeringWhat If There’s No Time for Requirements Engineering? Practices, Methods, Techniques, and Tools That May Be New, Different, and Especially Important • Create or tailor a requirements process. • Use effective requirements practices, tailored as needed to the size and scope of the project, e.g.,: • a “joint team;” • defining the “real requirements;” • iterating the requirements and architecture repeatedly; • achieving effective communication; and • use your requirements process and practice continuous improvement. • Consider having an organizational requirements working group. • Consider time-boxes to set limits on prototype iterations. • Consider Requirements Based Product Development (RBPD) utilizing an effective automated requirements tool. • Have an organizational center of excellence to enable and empower your organization, e.g.: • requirements and architecture working groups • a process improvement group • organizational “process owners” • an electronic process asset library to share and reuse artifacts

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