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

Requirements Management Success Starts with Requirements Management

APPROACH TO REQUIREMENT MANAGEMENT

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%

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

REQUIREMENT CHANGE

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

Requirements change management All phases make use of requirements traceability

Page 28

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

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