Improving Quality Through Better Requirements

1. Improving Quality Through Better Requirements Dr. Ralph R. Young Northrop Grumman Information Technology www.ralphyoung.net

2. The Importance of Requirements • Requirements are the basis of all of the technical work performed on projects. • Requirements errors are the largest class of errors typically found in a project (41-56% of errors discovered). • Reducing requirements errors is the single most effective action developers can take to improve project outcomes. • There is great leverage (and cost savings) in identifying omitted requirements and in finding errors in the requirements stage vs. in later stages of the life-cycle. • The cost of rework is typically 45% of projects. • Requirements-related activities can reduce rework.

3. Industry Experience The quality of software development efforts improves when the investment in requirements-related activities is increased from the industry average of 3% to an optimum level of 8-14% of total project costs.

4. Areas to Focus On • Identify the real requirements (vice stated requirements). The stated requirements are never the real requirements. Customers and users need assistance in identifying the real requirements. This work needs to be accomplished jointly.

5. Acceptance, integration & verification Informing the enterprise Provisional & final Detailed Storing acceptance design & knowledge from component previous projects development User requirements Involve Your Customers and Users! Supplier work Amount of effort Architectural 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

6. Involve All Project Participants: Suggested Topics for “Early Project Requirements Briefing” • Industry issues in requirements engineering • The value of investing more in the requirements process • The project and/or organization’s “Requirements Process” • Overview of the methods and techniques that will be used • Types of requirements • Gathering requirements • Roles of the requirements analyst • Criteria of a good requirement • Types of requirements errors and how these can be reduced • How we will reduce rework on our project • Peer Reviews • Inspections of all requirements-related documents

7. Areas to Focus On(continued) 2. Document the rationale for each requirement (why it is needed). You may be able to eliminate up to half of the requirements—saving a lot of technical work and reducing cost, schedule, and risk.

8. Types of Requirements Errors(with thanks to Ivy Hooks)

9. Areas to Focus On(continued) 3. Meet minimum requirements that satisfy real needs. We over-design systems, including many features and capabilities that are not “needed.” The result: added cost, schedule, and risk.

10. Areas to Focus On(continued) 4. Use established criteria of a good requirement. Include this checklist in your automated requirements tool. Ensure each requirements meets these criteria.

11. Criteria of a Good Requirement • •Necessary -- If the system can meet prioritized real needs without the requirement, it isn’t necessary • •Feasible -- The requirement is doable and can be accomplished within cost and schedule • •Correct -- The facts related to the requirement are accurate • •Concise – The requirement is stated simply • •Unambiguous – The requirement can be interpreted in only one way • •Complete -- All conditions under which the requirement applies are stated and it expresses a whole idea or statement • •Consistent -- Not in conflict with other requirements • •Verifiable -- Implementation of the requirement in the system can be proved • •Traceable -- Can trace to the source of the requirement 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 -- Does not pose a specific implementation solution • •Standard construct – The requirement is stated as an imperative using “shall” • •Unique identifier – Each requirement shall have a unique identifying number

12. Areas to Focus On(continued) 5. Provide an effective mechanism to control and manage new requirements and changes to requirements. This is how many projects get out of control. We need to explain to customers and users how baselines, releases, versions, and updated products can be used.

13. Areas to Focus On(continued) 6. Write and use a requirements plan. Consider employing proven effective requirements practices and utilizing requirements best practices.

14. Areas to Focus On(continued) 7. Perform peer reviews and inspections of all requirements-related materials. Using peer reviews is a proven technique to identify errors and save money. The added cost of providing inspections of requirements-related materials is cost effective.

15. Use Metrics for Requirements • Number of requirements • Total number of requirements as of various dates • Number approved, added, deleted, modified • Number that are not clear • Number of requirements satisfied per build • Project resources devoted to requirements process (calendar time, staff hours, dollars) • Percent requirements volatility per unit of time (month and year), perhaps by functional component of the system

16. Examples of Effective Requirements Practices • Establishing and utilizing a “Joint Team” responsible for the requirements. • Using and continually improving a requirements process. • Iterating the requirements and the architecture. • Performing requirements verification and validation activities. • Providing an effective mechanism to control requirements changes.

17. Examples of Some Project Best Practices • Write (and iterate) a task or project “vision and scope document.” • Identify and involve all of the stakeholders of the task or project. • Use requirements workshops to achieve a shared vision, facilitate commitment, and gain buy-in of all stakeholders. • Use effective requirements gathering techniques. • Use a project glossary and a project acronyms list. • Prioritize requirements early and often. • Use an industrial-strength automated requirements tool. Provide and use attributes of requirements. • Develop, implement, and enforce meeting rules that describe how project staff members are to treat one another.

18. Provide Training for Requirements Analysts • Suggested Topics: • The critical roles of the requirements analyst • Skills and characteristics of effective requirements analysts • The organizational and project requirements policies • The need for senior management sponsorship • The requirements process (flowchart and a narrative description) • Recommended project-approved methods, techniques, and tools • Metrics for the requirements-related activities • Suggested readings and reference materials • Effective communication techniques and mechanisms • How to control changes to requirements • Criteria of a good requirement • How to use the selected automated requirements tool • How to calculate the ROI from applying an improved practice • How to write a “Requirements Plan” • The value of a “Project Acronym List” and a “Project Glossary”

19. In Summary: • We can improve software quality by paying more attention to requirements activities. • Requirements are important and provide many opportunities to further strengthen and improve what we are doing. • Several areas were suggested to focus on in your practical work. • A set of “Effective Requirements Practices” was suggested. • Some project best practices were suggested. • It is only by making a few improvements in the actual practices of what we do that we will get better. • Inculcating values of continuous improvement, teamwork, and support of each other will help.