1. Requirement Engineering Management Amna Shifia Nisafani Feby Artwodini M. Department of Information Systems Subject : Requirement Engineering

2. Requirements Management Success Starts with Requirements Management

3. APPROACH TO REQUIREMENT MANAGEMENT

4. Page 4  CHAOS report indicates only a distinct minority of software projects is completed on time and under budget  Successful projects are only 16.2%  Challenged projects accounted for 52.7%  Impaired projects accounted for 31.1%

5. Page 5  Failures attributed to poor requirements management  Incorrect definition of requirements  Poor management throughout development lifecycle

6. Page 6  Effective requirements management!  The factor most related to successful projects  Ensures right problem is solved  Ensures right system is built

7. Page 7  A systematic approach to  Eliciting  Organizing  Documenting  And managing the changing requirements of a software project  Not a new concept!

8. Page 8  Rational provides complete solution to requirements management  Rational Unified Process(RUP) o Recommends specific requirements management skills o Provides specific guidelines to effectively implement skills  Tools to automate these skills o RequisitePro, Rose, ClearCase

9. Page 9  Six essential management skills:  Analyze the problem.  Understand the user needs.  Define the system.  Manage the scope of the system.  Refine the system definition  Manage the changing requirements

10. Requirements Management in RUP  Requirements management skills implemented in the requirements core- workflow  Considered workflows

11. Page 11  Purpose is to:  Gain an agreement on system features and goals  Develop Vision document for the project  The key artifacts produced in the workflow:  Vision document  Requirement management plan for the project  Glossary

12. Page 12  Purpose is to:  Collect information from the various stakeholders of the project  Use different elicitation techniques to elicit requests

13. Page 13  The key artifacts produced in the workflow:  Refined vision document  Initial Use case model  Supplementary specifications  Refined glossary

14. Page 14  Purpose is to:  Ensure that all project team members understand the system  Perform high-level analysis on the results collected in previous workflows  Formally document results

15. Page 15  The key artifacts produced in the workflow:  Refined vision document  Refined use case model  Refined Supplementary specifications  Refined glossary

16. Page 16  Purpose is to:  Define the set of requirements to be included in this version of the system  Define a set of architecturally-significant features and uses cases  Define attributes and traceability to help prioritize requirements

17. Page 17  The key artifacts produced in the workflow:  Iteration plan  Refined vision document  Refined glossary

18. Page 18  Purpose is to:  Provide a more in-depth understanding of the system’s features  Provide detailed descriptions of use cases  Model and prototype user interfaces

19. Page 19  The key artifacts produced in the workflow:  User-interface prototype  Detailed use case model  Revised iteration plan  Refined vision  Refined glossary

20. Page 20  Purpose is to:  Control and manage change  Set up appropriate requirements attributes and traceabilities

21. Page 21  Easy to use requirements management tool  Leverages the power of database with the freedom of Word  Multi-user support  Provides distributed access to projects via its Web interface  Provides document templates and capability to import existing documents

22. Page 22  Define System – templates, import capability, requirement and document types  Manage scope – Traceability matrix and tree, attribute types  Manage change – Suspect links, group discussions, revision history

23. Page 23  Meeting the project’s requirements defines success!

24. Page 24  Rational provides a more disciplined approach to requirements management.  Does not only tell organizations what to do, provides assistance on how to do it  Rational dedicated the last few years to requirements management

25. REQUIREMENT CHANGE

26. Page 26  Enduring requirements. Stable requirements derived from the core activity of the customer organisation.  E.g. a hospital will always have doctors, nurses, etc.  May be derived from domain models  Volatile requirements. Requirements which change during development or when the system is in use.  In a hospital, requirements derived from health-care policy

27. Requirements change management All phases make use of requirements traceability

28. Page 28

29. Page 29  1. Davis, Alan, Leffingwell, Dean. Using Requirements Management to Speed Delivery of Higher Quality Applications. Rational Web Site. On-line at http://www.rational.com/products/whitepapers.http://www.rational.com/products/whitepapers  2. Kruchten, Philippe. The Rational Unified Process: An Introduction, Second Edition. Reading MA: Addison Wesley Longman, October 2000, pp.155-169.  3. Leffingwell, Dean. A Field Guide to Effective Requirements Management under SEI’s Capability Maturity Model. Rational Web Site. On-line at http://www.rational.com/products/whitepapers.http://www.rational.com/products/whitepapers

30. Page 30  4. Leffingwell, Dean. Managing Software Requirements: A Unified Approach. Reading MA: Addison Wesley Longman, November 2000.  5. Oberg, Roger. Applying Requirements with Use Cases. Rational Web Site. On-line at http://www.rational.com/products/whitepapers.http://www.rational.com/products/whitepapers  6. Parackel, Thomas. Managing Requirements in a Development Cycle. IWD Web Site. On-line at http://www.indiawebdevelopers.com/articles. http://www.indiawebdevelopers.com/articles  7. Rational RequisitePro. Rational Web Site. On-line at http://www.rational.com/products/reqpro. http://www.rational.com/products/reqpro  8. Royce, Walker. Software Project Management: A Unified Framework. Reading MA: Addison Wesley Longman, December 1999, pp.118-124.