M. Elowitz 4/11/07 1 REQUIREMENTS FOR PROJECT SUCCESS A Paper by Ralph Young in Crosstalk December, Presented by Murray Elowitz JJ & E Research Corp (505) April 11, 2006

M. Elowitz 4/11/07 2 Background This paper was published in Crosstalk –Dept of Defense publication –By Air Force Software Support Center Youngs paper is a valuable presentation of requirements methodology Applicable to SYSTEMS as well as software Presentation is with permission of the author My Comments Youngs Material

M. Elowitz 4/11/07 3 Key Points For success, you MUST work on continuous improvement Industry practice hasnt 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

M. Elowitz 4/11/07 4 Twelve Requirements Basics for Project Success 1.Include a trained and experienced manager 2. Partner with customer. 3.Invest in requirements process. 4. Project vision and scope document. 5.Use proven requirements techniques. 6. Evolutionary or incremental approach. 7.Effective changes control 8. Automated requirements tool 9.Ascertain the rationale for every requirement 10.Inspections of documents. 11.All project staff perform requirements work. 12.Proactively address requirements-related risks.

M. Elowitz 4/11/07 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.

M. Elowitz 4/11/07 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 highunless 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.

M. Elowitz 4/11/07 7 Requirements Secrets (3) Its neither difficult nor expensive to incorporate inspections in your projects approach; although this technique has been available for a long time, most projects dont 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 dont 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.

M. Elowitz 4/11/07 8 Twelve Requirements – Trained & experienced manager 1.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

M. Elowitz 4/11/07 9 Analyst Skills (Sample)

M. Elowitz 4/11/07 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

M. Elowitz 4/11/07 11 Twelve Requirements – Invest 3.Invest in the projects requirements process. Understand your resource requirements NASA data: Spend more for successful project *Lower cost and improved schedule Req. Process% of Project Industry Avg3 Successful*8-14

M. Elowitz 4/11/07 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

M. Elowitz 4/11/07 13 Twelve Requirements – Real Requirements 5.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

M. Elowitz 4/11/07 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

M. Elowitz 4/11/07 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

M. Elowitz 4/11/07 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

M. Elowitz 4/11/07 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

M. Elowitz 4/11/07 18 The Criteria of a Good Requirement (1) Necessary -- If system can meet real needs without it, it isnt. 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.

M. Elowitz 4/11/07 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.

M. Elowitz 4/11/07 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

M. Elowitz 4/11/07 21 Twelve Requirements – I nspections 10. Conduct inspections of all requirements-related documents. (Inspections are a more rigorous form of peer reviews). Utilize inspections –Not widely used

M. Elowitz 4/11/07 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

M. Elowitz 4/11/07 23 Twelve Requirements – Address Risks 12. Proactively address requirements-related risks. Address risks with discipline –Most projects dont

M. Elowitz 4/11/07 24

M. Elowitz 4/11/07 25 Summary Paper is based on Youngs experience No good excuse for high amount of: –Rework –Project failures –Missing schedules, budgets Use the requirements basics in this article