Requirements Workflow in RUP
In the Rational Unified Process, from which some of these notes are taken, the objective for this work is to collect and elicit information from stakeholders in the project. This information can be regarded as a "wish list" that is used as primary input in defining use cases and supplementary requirements.
This workflow detail is performed mainly during iterations in the Inception and Elaboration phases. However, stakeholder requests should be gathered throughout the project by reviewing change requests following your Change Request Management process. You should be aware of incoming stakeholder requests throughout the product lifecycle, to make sure you continue to address your stakeholders' real needs.
The key activity is to elicit stakeholder requests and determine the requested features of the system. The primary outputs are a collection of prioritized Stakeholder Needs and Features, as well as the attributes associated with them. These outputs are recorded in the Vision document. Also, during this workflow, you discuss the system in terms of its use cases and actors. Another important output is an updated Glossary of Terms to facilitate a common vocabulary among team members.
You need to capture requests from all stakeholders and specify how these requests are addressed. Although the system analyst is responsible for gathering this information, many people contribute to it: marketing people, users, customers-anyone who is considered to be a stakeholder in the project.
Other examples of external sources for requirements are:
Any results from requirements elicitation sessions and workshops
|
|
"I need to assess the status of my project."
"I want a trend report that shows the rate issues are being opened and resolved."
Jumping to solution mode is a common problem we humans have. It is because of this that, when you elicit needs from your stakeholders, you often get them expressed as features instead of a statement of what the stakeholder needs from any solution in order to solve the business problem. What do you do with these needs expressed as features? Do you tell the customer to "hold off - we'll get to those later"? No. At this stage, it is a stakeholder request and should be recorded as one. At the appropriate time you should assess whether it is valid and then create a feature requirement for it. The text of the new feature may be identical to the text of the stakeholder request. (In the USA DoD standards, the process of copying the text of a requirement to the next level is called allocation. If you reword the requirement when you create it at the next level, it is called derivation.)
To understand the need behind a request expressed as a feature, you can perform some problem analysis. For example: "The defect tracking system shall provide a project status trending report." This is a stakeholder request expressed as a feature. To understand the need that drives this feature, ask "why?" The answer could be something like: "I need to be able to understand if defects being raised faster than they are being resolved." This is the real need behind the feature, a sub-problem if you like.
Either way, you should record every request and then send it through a standard approval process before it is included in the system. Stakeholder requests expressed as features require a little more analysis to test whether they are valid and that they support the business goals of the system.
|
|
|  |
