1. Computer Engineering 203 R Smith Requirements Management 6/2009 1 Requirements IEEE Standard Glossary A condition or capability needed by a user to solve a problem or achieve an objective. A condition or capability that must be met or processed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.

2. Computer Engineering 203 R Smith Requirements Management 6/2009 2 Quote from Frederick Brooks The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.

3. Computer Engineering 203 R Smith Requirements Management 6/2009 3 Why are Requirements Critical? In over 8,000 projects conducted by 350 companies, only 16 percent of projects were considered successful, on time and within budget. Studies continue to show that errors in requirements are the most significant factor in project failure. Errors in requirements have the greatest impact on project resources, time, personnel, etc. – Costs to correct problems increase over time

4. Computer Engineering 203 R Smith Requirements Management 6/2009 4 Scope and Requirements The text uses the term “scope” to cover both the project vision and requirements. Think about project vision, scope and requirements as layers of detail. Project vision being the highest level and requirements being the most detailed. Each layer addresses a different need.

5. Computer Engineering 203 R Smith Requirements Management 6/2009 5 Scope and Requirements While each layer provides greater detail each layer must fit within the higher layers. The Project Vision provides a filter to measure all requirements. For example all requirements must be traced back to the project scope and the scope must fit within the project vision.

6. Computer Engineering 203 R Smith Requirements Management 6/2009 6 Vision/Scope Statement Provides the answers to basic questions – What need will the project satisfy? – Who is the project for? – What is not in the project? The Vision statement provides a base to trace all requirements too. The Vision statement help establish project buy-in.

7. Computer Engineering 203 R Smith Requirements Management 6/2009 7 From Vision to Requirements The Vision/Scope sets the framework, creating requirements adds detail. All code that is written for a project should be in response to a requirement. The Vision justifies all other work

8. Computer Engineering 203 R Smith Requirements Management 6/2009 8 What Makes Good Requirement? All stakeholders have the same vision of the requirement. That it can be built and tested. The end result of different developers each developing the same requirement will be essentially the same.

9. Computer Engineering 203 R Smith Requirements Management 6/2009 9 Unambiguous All readers of a requirement statement should arrive at a single consistent interpretation of it. How to achieve unambiguous requirements: – Ensure the frame of reference is consistent – Use modeling, UML – Use prototypes

10. Computer Engineering 203 R Smith Requirements Management 6/2009 10 Necessary Each requirement should document something the customer needs. – The need can be traced back to the vision. The Vision can be traced back to the customer.

11. Computer Engineering 203 R Smith Requirements Management 6/2009 11 Complete Is each requirement fully described? Does the developer have all the information needed to begin design? Will the developer need to refer to the customer for missing details?

12. Computer Engineering 203 R Smith Requirements Management 6/2009 12 Realistic Is the requirement beyond the limitations of the systems environment? Is the requirement beyond the scope of technology?

13. Computer Engineering 203 R Smith Requirements Management 6/2009 13 Verifiable Can tests be written to verify that the requirement can be met? – Can you write a test that verifies that a user interface is: “Good” “Easy to use” Can it be determined objectively if a requirement has been met?

14. Computer Engineering 203 R Smith Requirements Management 6/2009 14 Consistent Do requirements conflict with other requirements? Being easy to “learn” and “feature rich” are often in conflict. Developing something in a set time frame and having a limited budget are often in conflict.

15. Computer Engineering 203 R Smith Requirements Management 6/2009 15 Traceable Traceable goes in both directions – External to the customer – Internal to the code Can you trace the requirement back to the customer? Can elements, code, test cases and documentation be traced to a requirement? If code does not implement a requirement then why is it being implemented?

16. Computer Engineering 203 R Smith Requirements Management 6/2009 16 Why are Good Requirements Important? Improved Efficiency – Reduces delays for clarification. Less Rework – Getting it right the first time reduces waste. Reduced Risk Less Friction – Giving the customer what they want.

17. Computer Engineering 203 R Smith Requirements Management 6/2009 17 Scope and Requirements Does user involvement solve everything? – Is the user fully informed? Do they have authority? – Is what is in and what is not included clearly described? Assumptions are made too easily – Is a change control mechanism provided. Ensure changes happen in planned manner – Communications Everyone is informed when changes happen

18. Computer Engineering 203 R Smith Requirements Management 6/2009 18 Role of a Requirements Process Provides discipline to make requirements gathering predictable. Communicates to those involved what is expected of them. Establishes a baseline for future improvement to gathering requirements.

19. Computer Engineering 203 R Smith Requirements Management 6/2009 19 Why is a requirements process needed? Ensure quality in establishing the requirements. Change will always be expensive.

20. Computer Engineering 203 R Smith Requirements Management 6/2009 20 Steps in the Requirements Process Requirements Elicitation – How are we going to get the requirements? – From whom do we get requirements? Requirements Analysis – What do the requirements actually mean? Requirements Documentation – Making a record of the decisions made. Requirement Verification – Getting agreement on the work to be done.

21. Computer Engineering 203 R Smith Requirements Management 6/2009 21 Common Problems with Requirements Requirements are not Consistent with the Vision. Requirements are ambiguous and are based on assumptions, which allows multiple interpretations. Requirements are based on the design and not the Vision.

22. Computer Engineering 203 R Smith Requirements Management 6/2009 22 Common Problems with Requirements All sources of requirements are not identified. All stakeholders are not informed of the requirements.

23. Computer Engineering 203 R Smith Requirements Management 6/2009 23 Relationship between Planning and Requirements You need requirements to have a completed plan. You need a plan too know if your requirements can be successfully implemented.

24. Computer Engineering 203 R Smith Requirements Management 6/2009 24 Where do Requirements come from? Customers Industry standards Business goals Company priorities Government standards

25. Computer Engineering 203 R Smith Requirements Management 6/2009 25 Types of Requirements Functional requirements Nonfunctional and Pseudo requirements Systems requirements User requirements Business requirements Quality attributes

26. Computer Engineering 203 R Smith Requirements Management 6/2009 26 Functional Requirements Behavior of the system Operations it should perform Inputs it should accept Output it should produce

27. Computer Engineering 203 R Smith Requirements Management 6/2009 27 Nonfunctional and Pseudo Requirements Industry/Company standards – Windows Look and Feel Government regulations – How records are kept Market requirements – Internet/X.400

28. Computer Engineering 203 R Smith Requirements Management 6/2009 28 Best Practices in Requirements Elicitation Have a vision and scope statement – Agree on the project’s objective Define the requirements procedure Identify users/stakeholders – Where do we get requirements from Involve the user Analyze user workflow – Uncover what assumptions have been made.

29. Computer Engineering 203 R Smith Requirements Management 6/2009 29 Requirements Analysis Draw a system context diagram Create models and prototypes Create a data dictionary Analyze feasibility Prioritize requirements Risk Management

30. Computer Engineering 203 R Smith Requirements Management 6/2009 30 Create Models and Prototypes Use Cases Data Flow Diagrams Entity Relationship Diagrams State Transition Diagrams

31. Computer Engineering 203 R Smith Requirements Management 6/2009 31 Create a Data Dictionary The Data Dictionary is the glue that holds requirements and models together. Primitive data elements Data structures or records Iterations within data structures

32. Computer Engineering 203 R Smith Requirements Management 6/2009 32 Analyze Feasibility Determine the risks – Unfamiliar tools, technologies, methods, hardware, etc How complex is it? How rigid are the requirements?

33. Computer Engineering 203 R Smith Requirements Management 6/2009 33 Prioritize Requirements Look at the risks. Look at the dependencies. Look at the availability of resources. Look at customer interest. – What will make the customer happy. Look at visibility. – Can we show progress?

34. Computer Engineering 203 R Smith Requirements Management 6/2009 34 Risk Management How do risks impact the requirements? What are priorities? What requirements can be delayed to make time to allow for risks?

35. Computer Engineering 203 R Smith Requirements Management 6/2009 35 Traceability Matrix Best practice would establish a traceability matrix for all requirements. All code, tests and documentation must trace back to a requirement. Requirements must have associated code, tests and documentation. The matrix ties everything together.

36. Computer Engineering 203 R Smith Requirements Management 6/2009 36 Best Practices in Documenting Requirements Requirements should be inspected – Unambiguous – Measurable Use writing standards, common syntax when documenting requirements Define all data Use pictures and diagrams

37. Computer Engineering 203 R Smith Requirements Management 6/2009 37 Requirements Verification Inspect requirements documents – Look for common errors Write test cases from requirements Write user manual from requirements Is sign-off enough? – If there is not informed buy-in then there is always room for disagreement.

38. Computer Engineering 203 R Smith Requirements Management 6/2009 38 Inspect Requirements Documents Doing formal inspections of requirements eliminates requirements problems early in the development process Builds a common understanding of the requirements

39. Computer Engineering 203 R Smith Requirements Management 6/2009 39 Is Sign-off Enough? Is sign-off enough if you know the work is sub-par? Avoided problems will come back to haunt you. Was the sign-off done after careful review or was it done because it was expected in the schedule?

40. Computer Engineering 203 R Smith Requirements Management 6/2009 40 Requirements Management From Requirements to Project Plans Change Control Version Control Requirements Tracing Requirements Status Tracking

41. Computer Engineering 203 R Smith Requirements Management 6/2009 41 From Requirements to Project Plans Creating the roadmap – Priorities – Estimates – Risks – Dependencies

42. Computer Engineering 203 R Smith Requirements Management 6/2009 42 Change Control Change Control Boards Use of contingency in estimating the size of the work

43. Computer Engineering 203 R Smith Requirements Management 6/2009 43 Version Control Tracking when requirements were added or dropped Tracking who and why a change was requested Tracking the impact of the change Tracking who approved the change

44. Computer Engineering 203 R Smith Requirements Management 6/2009 44 Requirements Tracing What is needed to justify the work involved in tracing requirements? – Customer satisfaction – Not doing more work then required – Ensuring that all parts of the project come together Documentation Support Test

45. Computer Engineering 203 R Smith Requirements Management 6/2009 45 Requirements Status Tracking As part of normal schedule tracking, follow the progress of development. Allow for partial releases of functionality within status tracking.