2. Activities?
Feasibility Requirements
study elicitation and
analysis
Requirements
specification
Feasibility Requirements
report validation
System
models
U and system
ser
requirements
Requirements
document
4. Software Crisis
• 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. Causes of Software Crisis
• Failures attributed to poor
requirements management
– Incorrect definition of requirements
– Poor management throughout
development lifecycle
6. Solution to Software Crisis
• Effective requirements management!
– The factor most related to successful
projects
– Ensures right problem is solved
– Ensures right system is built
7. Requirements Management
• A systematic approach to
– Eliciting
– Organizing
– Documenting
– And managing
the changing requirements of a software
project
• Not a new concept!
8. Rational Approach to
Requirements Management
• 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 User Needs
• Purpose is to:
– Collect information from the various
stakeholders of the project
– Use different elicitation techniques to
elicit requests
13. Understand the User Needs
• 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 Scope of 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 Scope of 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
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
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%.
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 .
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 !!
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.
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.
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.
The primary outputs are collections of stakeholder requests, which enable refinement of the Vision document.
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.
Add Use case Specifications
The main purpose of this technique is prioritize the requirements and determine which requirements to implement first.
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.
Use case model consists of diagrams and specifications.
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.
Dedication in the process, and tools that automate these difficult tasks.
