Capability Pattern: Requirements








var defaultQueryStr = '?proc={38A9C609-9A59-4D03-B835-AA84A716E626}&path={38A9C609-9A59-4D03-B835-AA84A716E626}';
var backPath = './../../';
var imgPath = './../../images/';
var nodeInfo=null;
contentPage.preload(imgPath, backPath, nodeInfo, defaultQueryStr, false, true, false);










Capability Pattern: Requirements















This capability pattern covers the activities and workflow for the Requirements discipline.








DescriptionWork Breakdown StructureTeam AllocationWork Product Usage








Relationships



Context


Classic RUP (for large projects)






Description



To help explain the work involved in the Requirements discipline, the activities and work products are organized into a capability pattern for the discipline. Each activity represents a high-level goal that needs to be achieved to perform effective requirements management. Analyzing the problem and understanding the stakeholders needs are the primary requirements goals during the Inception phase of a project. During the Elaboration and Construction phases, the emphasis shifts more towards initially defining and subsequently refining the system definition in terms of the detailed requirements. Managing the system scope and ongoing requirements change are addressed continuously throughout the project. The workflow diagram, shown on the Work Breakdown Structure, shows the activities in a logical, sequential order. These activities are applied continuously in varied order, as needed, throughout the project. The Requirements discipline capability pattern sequences the activities in the order that you would most likely apply them in the first iteration of a new project.  



Properties



Event Driven


Multiple Occurrences


Ongoing


Optional


Planned


Repeatable



Usage



Usage Notes Decide How to Perform the Workflow The following decisions should be made regarding the Requirements discipline's workflow: Decide how to perform the workflow by looking at the activities in this workflow. Study the diagram with its guard conditions. Decide which activities to perform and in which order. Decide what parts of the Requirements activities to perform. The table below shows some parts that can be introduced relatively independently from each other. Decide when, during the project lifecycle, to introduce each part of the workflow. As a general rule, the Requirements discipline should be introduced early in the project. Part of workflow Comments Use-Cases Some projects do not employ use-cases, which means that the project will not develop artifacts such as a Use-Case Model, Use-Case Package and Use Case. Instead use the Software Requirements Specification.  Activity: Manage Changing Requirements This can be introduced after a few iterations in the project when there is a stable baseline.   Document the decisions in the Development Case under a section dealing with the Requirements discipline.



More Information



Guidelines


Important Decisions in Requirements








©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved.







contentPage.onload();




Wyszukiwarka

Podobne podstrony:
review requirements tmS4695E9
BASIC MILITARY REQUIREMENTS 2
manage changing requirements?6AC18D
function require once
test requirement?4A2712
rup software requirements specification?4E66F
TRANSACTION REQUIRED
manage changing requirements?6AC18D
requiresubnet
BASIC MILITARY REQUIREMENTS 17
manage changing requirements?6AC18D
requiresubnet

więcej podobnych podstron