Downloaded 37 times
More Related Content
Similar to Requirements engineering vii
![Getting Started with Apache Spark: Big Data Made Simple [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/apachesparkgettingstarted-260203175547-8361bcc3-thumbnail.jpg?width=640&height=640&fit=bounds)
Requirements engineering vii
- 1. Requirements Engineering Indri Sudanawati Rozas Juni 2012
- 2. Activities? Feasibility Requirements study elicitation and analysis Requirements specification Feasibility Requirements report validation System models U and system ser requirements Requirements document
- 3. Requirements Management Success Starts with Requirements Management
- 4. Software Crisis • CHAOSreport 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. Causes of SoftwareCrisis • Failures attributed to poor requirements management – Incorrect definition of requirements – Poor management throughout development lifecycle
- 6. Solution to SoftwareCrisis • Effective requirements management! – The factor most related to successful projects – Ensures right problem is solved – Ensures right system is built
- 7. Requirements Management • Asystematic approach to – Eliciting – Organizing – Documenting – And managing the changing requirements of a software project • Not a new concept!
- 8. Rational Approach to RequirementsManagement • Rational provides complete solution to requirements management – Rational Unified Process(RUP) • Recommends specific requirements management skills • Provides specific guidelines to effectively implement skills – Tools to automate these skills • RequisitePro, Rose, ClearCase
- 9. Requirements Management Skills • 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. Analyze the Problem •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. Understand the UserNeeds • Purpose is to: – Collect information from the various stakeholders of the project – Use different elicitation techniques to elicit requests
- 13. Understand the UserNeeds • The key artifacts produced in the workflow: – Refined vision document – Initial Use case model – Supplementary specifications – Refined glossary
- 14. Define the System •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. Define the System •The key artifacts produced in the workflow: – Refined vision document – Refined use case model – Refined Supplementary specifications – Refined glossary
- 16. Manage the Scopeof the System • 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. Manage the Scopeof the System • The key artifacts produced in the workflow: – Iteration plan – Refined vision document – Refined glossary
- 18. Refine the System •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. Refine the System •The key artifacts produced in the workflow: – User-interface prototype – Detailed use case model – Revised iteration plan – Refined vision – Refined glossary
- 20. Manage Changing Requirements • Purpose is to: – Control and manage change – Set up appropriate requirements attributes and traceabilities
- 21. Tool Support -RequisitePro • 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. RequisitePro Manages Requirements • 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. Why Manage Requirements? • Meeting the project’s requirements defines success!
- 24. Why Rational Approach? •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. References • 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. • 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.
- 26. References . • 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. • 6. Parackel, Thomas. Managing Requirements in a Development Cycle. IWD Web Site. On-line at http://www.indiawebdevelopers.com/articles. • 7. Rational RequisitePro. Rational Web Site. On-line at 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.
Editor's Notes
- #5 A report from the Standish Group confirms that only a distinct minority of software projects is completed on time and on budget. In their report, the success rate was only 16.2%, while challenged projects (operational, but late and over budget) accounted for 52.7%. Canceled projects accounted for 31.1%.
- #6 The report indicates that the most significant contributors to projects’ failure relate to requirements. In many cases, requirements are not correctly determined and defined at the outset, or are not well managed as the project unfolds .
- #7 The solution is probably clear to many of us. As a matter of fact, The Standish Group's CHAOS report did establish that managing requirements well was the factor most related to successful projects. Then If projects fail due to ineffective requirements management process, and having a better and effective approach ensures success, so why don’t organizations enforce a better and effective requirements management process? The solution is so simple, why didn’t anybody figure that one out. The truth is they have. Next page !!
- #8 Requirements management is not a new concept. All the software engineering processes have focused on requirements management activities, one way or the other. The traditional waterfall model dedicated an entire phase to requirements management.
- #12 Vision that identifies the high-level user view of the system to be built. In this vision document, initial requirements are expressed as key features the system must possess in order to solve the most critical problems. In addition, all stakeholders are identified at this point.
- #13 Requirements have many sources. They may come from anyone with an interest in the outcome of the project. Customers, partners, end users, and domain experts are some sources of requirements. Management, project team members, business policies, and regulatory agencies can be others. It is important to know how to determine who the sources should be, how to get access to those sources, and how to elicit information from them. The individuals who serve as primary sources for this information are referred to as "stakeholders" in the project.
- #14 The primary outputs are collections of stakeholder requests, which enable refinement of the Vision document.
- #15 The Problem Analysis workflow and the Understanding Stakeholder Needs workflow create early iterations of key system definitions including the vision document, a first outline to the use-case model, and the requirements attributes. The Defining the System workflow completes the description of the system-level requirements with the addition of new actors, use cases, and supplementary specifications.
- #16 Add Use case Specifications
- #17 The main purpose of this technique is prioritize the requirements and determine which requirements to implement first.
- #19 The main purpose of this technique is to provide a more in-depth understanding of the system’s features by further refining the requirements and adding detailed descriptions of the use cases in the Case Specification document.
- #20 Use case model consists of diagrams and specifications.
- #21 The main objective of this technique is not to stop requirements from changing, it is instead meant to control and track the changes. In fact, in the Rational Unified Process change in requirements is not only accepted, it is actually expected. The process recognizes that requirements are dynamic and change in requirements is, in some cases, good. A change in requirements may indicate that the team has spent time and efforts to understand the stakeholder needs and define the system that meets those needs.
- #25 Dedication in the process, and tools that automate these difficult tasks.