Presented by Murray Elowitz JJ & E Research Corp (505) 453-6358 April 11, 2006

1. REQUIREMENTS FOR PROJECT SUCCESSA Paper by Ralph Youngin Crosstalk December, 2006http://www.stsc.hill.af.mil/crosstalk/2006/12/0612Young.html Presented by Murray Elowitz JJ & E Research Corp (505) 453-6358 April 11, 2006

2. Background • This paper was published in Crosstalk • Dept of Defense publication • By Air Force Software Support Center • Young’s paper is a valuable presentation of requirements methodology • Applicable to SYSTEMS as well as software • Presentation is with permission of the author Young’s Material My Comments

3. Key Points • For success, you MUST work on continuous improvement • Industry practice hasn’t improved much • Failure to work on improving is root cause • Need to be AGILE is important Successful Requirements Process Will Improve Project Success and Control Costs

4. Twelve Requirements Basics for Project Success • Include a trained and experienced manager • “Partner” with customer. • Invest in requirements process. • Project vision and scope document. • Use proven requirements techniques. • Evolutionary or incremental approach . • Effective changes control • Automated requirements tool • Ascertain the rationale for every requirement • Inspections of documents. • All project staff perform “requirements work”. • Proactively address requirements-related risks.

5. Requirements Secrets (1) • Half of the features provided in most delivered software are never used once. • More than half of the effort on most systems and software projects is wasted. • The “stated requirements” (i.e., the list of requirements provided to the developer by the customer and users) are never the “real requirements”. • 80% of requirements errors found in system testing are a result of incorrect “facts” about the requirements or omitted requirements. • Spending a lot of effort on testing may be misguided; better to invest more in an effective requirements process that results in higher quality products being provided to test.

6. Requirements Secrets (2) • Given that (a) systems and software development is complex, and b) people (with all of our frailties) are involved, the probability of the development effort becoming derailed is very high—unless a proactive effort is made to “partner for success”. • The documents we produce are fraught with errors; the earlier in the development effort those errors (defects) are discovered, the less costly it is to fix them. A peer review process should be implemented to reduce errors. All requirements-related documents should be inspected. • Project managers should pay added attention to the requirements basics and allot sufficient funding for requirements-related activities.

7. Requirements Secrets (3) • It’s neither difficult nor expensive to incorporate inspections in your project’s approach; although this technique has been available for a long time, most projects don’t use it. • A “defect prevention process” is also very easy to train, deploy, and implement, based on experience on 25 projects. It can save a lot of money and time; again, most projects don’t use it. • Communication on most projects is challenged; a proactive effort to foster good communications is required • An effective automated requirements tool is required to support requirements development and requirements management on all but tiny projects.

8. Twelve Requirements –Trained & experienced manager • Make sure the project staff includes a trained and experienced requirements manager or requirements analyst. • Provide training for all project participants • Need a skilled requirements engineer • Require a requirements analyst • See skills matrix • Document the requirements process This may be a role for a consultant

9. Analyst Skills(Sample)

10. Twelve Requirements –Partnering 2. Proactively “partner” with your customer • Advantage is evolution of a team committed to project success • This can help keep projects funded

11. Twelve Requirements –Invest 3. Invest in the project’s requirements process. • Understand your resource requirements NASA data: Spend more for successful project *Lower cost and improved schedule

12. Twelve Requirements –Vision And Scope 4. Write a project vision and scope document • For stakeholders and to obtain buy-in • Upward to customers and users • Downward to project contributors • Everyone helps solve problems

13. Twelve Requirements –Real Requirements • Use proven requirements elicitation techniques • Need to identify real requirements • Vs. stated requirements • Especially at project start-up • Recommendation: use 2 techniques • Workshops • Prototypes • Involve all key members of team

14. Additional Value • Rushing to start design is a major start-up problem • Ready-Fire-Aim syndrome • Design decisions made too early • Reflects need to staff rapidly, meet early milestones, provide jobs • Designers think they know what THEY have to do Involving all key members in Requirements Process alleviates issue

15. Twelve Requirements –Evolutionary Approach 6. Utilize an evolutionary or incremental project approach to development, deployment, and implementation of the capabilities • Look for and use new approaches • Have someone with experience on staff or USE A CONSULTANT!!! • Pay attention to lessons learned

16. Twelve Requirements –Requirements Changes 7. Use an effective mechanism to control changes to requirements and new requirements. • Use high-level CCB for requirements • Prioritize requirements • Some requirements are “unknowable” • Recommendation: < 0.5% changes per month

17. Twelve Requirements –Automated Tool 8. Use an effective automated requirements tool to maintain information about the requirements. • Required! • Entries must be good requirements • See next chart • 11 suggested attributes of data • Serve needs of different people

18. The Criteria of a Good Requirement (1) •Necessary -- If system can meet real needs without it, it isn’t . •Feasible -- The requirement is “doable” within available cost and schedule. •Correct -- The facts related to the requirement are accurate ,,,. •Concise -- The requirement is stated simply. •Unambiguous -- The requirement can only be interpreted one way. •Complete -- Requirement expresses all conditions and whole idea or statement. •Consistent -- The requirement is not in conflict with other requirements. •Verifiable -- Can be proved.

19. The Criteria of a Good Requirement (2) •Traceable -- The requirement can be traced to its source and it can be tracked throughout the system (e.g., to the design, code, test, and documentation). •Allocated --The requirement is assigned to a component of the designed system. •Design independent -- The requirement does not pose a specific implementation solution. •Nonredundant -- The requirement is not a duplicate requirement. •Stated using a standard construct -- The requirement is stated as an imperative using the word shall. •Associated with a unique identifier -- Each requirement has a unique identifying number. •Devoid of escape clauses -- Requirements do not use “if”, “when”, “but”, “except”, “unless”, and “although” and do not include speculative or general terms such as “usually”, “generally”, “often”, “normally”, and “typically”.

20. Twelve Requirements –Accurate & Complete 9. Ensure the facts concerning the requirements are accurate and that important requirements are not omitted. Ascertain the rationale for every requirement (why it is needed). • Stakeholder & source docs reviews • Completeness by using variety of stakeholders, formal reviews

21. Twelve Requirements – Inspections 10. Conduct inspections of all requirements-related documents. (“Inspections” are a more rigorous form of peer reviews). • Utilize inspections • Not widely used

22. Twelve Requirements –Enlist support 11. Enlist the support and assistance of all members of the project staff in helping to perform “requirements work”. • Use all members of project staff • Develops strong sense of teamwork • Empowerment Helps hold back rush to design

23. Twelve Requirements –Address Risks 12. Proactively address requirements-related risks. • Address risks with discipline • Most projects don’t

25. Summary • Paper is based on Young’s experience • No good excuse for high amount of: • Rework • Project failures • Missing schedules, budgets Use the requirements basics in this article