1. IT Requirements Management Balancing Needs and Expectations

2. Agenda IT requirements issues What does it mean to manage requirements Balancing need and expectation Trends in requirements management Risks of poor requirements management Benefits of good requirements management

3. Impact of Requirements Defects Requirements Issues 40% of software project errors are caused by requirements errors 70% of project rework cost is attributable to requirements errors 50% of total project cost is attributable to rework

4. Requirements Issues What is requested is not always what is needed Requirements address symptoms, not problems Expectations don’t match requirements Conflicting voices giving requirements Designs and solutions are mixed with requirements Development work starts before requirements are baselined Baselined requirements will change

5. Requirements Requirements define the products or services that a project must deliver, and the standards for creating and validating those deliverables, in order to satisfy the terms of the project Requirements management is the process of defining, controlling, developing, validating, and verifying the completion of project requirements

6. What does it mean to manage requirements?

7. Initiation – Product description Planning – Project scope, schedule, cost, quality Execution – Gather, develop, validate Close-down - Verification Control – Change management, Quality Assurance

8. Initiation Dreams and visions are not requirements, but set the stage for the project product Initial product description and project charter present highest level requirements Contracts may include high level requirements - constraints

9. Planning Refine requirements – Decreasing levels of granularity – Dependencies Project schedule includes time for requirements determination, evaluation, development, and validation Project budget includes costs to realize requirements Integration of scope, schedule, cost, and quality – Business trade-offs – Technical trade-offs

10. Execute Conduct requirements gathering Conduct requirements evaluation Baseline requirements Develop product to meet requirements Validate the product against requirements Implement approved changes to requirements

11. Close-down Final check of traceability matrix – Nothing forgotten! Client verification

12. Change Management Accept change requests Perform impact analysis Conduct review process Follow action for approvals Follow action for rejections Establish new baseline for requirements

13. Control Establish validation techniques – Demonstration – Test – Inspections Establish review and approval process Establish standards and templates Quality Assurance

14. Standards to Establish Techniques for collecting, prioritizing, documenting, tracing, testing, validating Tools for recording, tracing, and managing requirements Processes for change requests, reviews and approvals, requirements determination, requirements management, continuous improvement Deliverables / templates for requirements statement, approvals and verification sign-offs, change requests, traceability matrix Roles for requirements determiners, client subject matter experts, reviewers, testers, developers, technical consultants Training to ensure requirements determiners are proficient in techniques, project team proficient in processes

15. Balancing Need and Expectation

16. Need Perceived need Best solution Schedule need Financial need Prioritized need Dependencies What will best address the client’s business problem

17. Expectation Efficient User Friendly Reliable Correct General Knowledge How the client perceives the product “That’s not what I meant!”

18. Manage All Requirements Business (Functional) Requirements – A function of the project product or service that directly addresses a client’s business need Non Functional Requirements – A property the end product must satisfy – Standards by which the product must be created – Support structure that make the product possible – Environment in which the product must exist

19. Business Requirements Information Timing of events Format and content of – Reports – Web pages – Transactions Calculations and Formulae Laws and Regulations Security Data validation Roles and Responsibilities Process flow

20. Non Functional Requirements Auditable Available Usable Legal Cultural Standards Robustness Responsibilities Disaster Recover Backup / Restore Conversion Data Integrity Deployment Documentation Support Environment Hardware Software Performance Capacity Security Training Scalability Interoperability Non functional requirements are often overlook and under-planned

21. Characteristics of Good Requirements Appropriate Attainable Correct Complete Concise Unambiguous Consistent Testable Verifiable Modifiable Traceable Implementation Independent

22. Industry Trends

23. Trends Tools Agile methods Client participation Reusable requirements Requirements Engineering Defect collection

24. RM Tools Record requirements Track dependencies among requirements Trace dependencies to components and validations Track status of requirements Manage versions and changes to baselined requirements Store requirement attributes Control access to requirements data Trigger communications (emails) to stakeholders

25. Agile Methodologies Alternative to strict processes Dynamic requirements Adaptable to changes in technical and business needs Short term planning Client participation Focus on testing for verification Quick ROI

26. Client Participation Keep the client involved throughout the project life cycle Reviews Functional Testing Issue Resolution Status updates Requirements clarification

27. Reusable Requirements Object or components from one project: Available for use in another project Object Libraries Converted for use in another project

28. SEI SW-CMM and CMMI Requirements Management Baseline requirements Manage the requirements Maintain consistency across Requirements Plans Products Activities

29. SWEBOK – IEEE Computer Society Software requirements knowledge area for Engineering process Elicitation Analysis Specification Validation Management Software Engineering Body of Knowledge

30. Requirements Engineering Supported as a specialization for requirements management Focused training Improved quality and consistency in requirements statements Improved requirements management Efficiency of process Metrics collection

31. Defect Collection Support importance of strong requirements management Demonstrate quality improvement in process and product as defects reduce over time Identify phases where process improvement is most needed Support Root Cause Analysis Recognize severity levels in defects

32. Risks of poor requirements management Benefits of good requirements management

33. Risks of Poor Requirements Management Inadequate statement of requirements – Non functional requirements omitted – Unstated requirements – Poorly stated requirements – Misunderstood requirements Failure to consult the right people – End user – Technical experts – Business experts

34. Risks of Poor Requirements Management Lack of commitment – Review with client – Review with developers Lack of client participation during development – Create what you think they want Uncontrolled changed requirements – No change management – Scope creep

35. Risks of Poor Requirements Management Lack of requirements accountability – Failure to trace to completion – Omitted requirements – Imagined requirements (do work that was never asked for) Short-cut the requirements analysis phase – Anxious for return on investment – Start work before know what to deliver

36. Benefits of Good Requirements Management Reduce rework on projects Reduce cancelled projects Increase client satisfaction