This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
RmHome
>
RmScenarios
>
RmScenariosRavenflow
(12 Aug 2009,
DavidRuiz
)
(raw view)
-- Main.DavidRuiz - 07 Aug 2009 *Overview* It is recommended that we organize and describe the Collaboration Scenarios in the context of an end-to-end Requirements Definition & Management (RDM) lifecycle. One view of this lifecycle might be: <img width="550" alt="RDM Lifecycle Graphic" src="http://www.imageurlhost.com/images/bkuwi8bmwjexkf16ogjf_RDM-Lifecycle.png" title="RDM Lifecycle" height="192" /> *Requirements Planning:* The activities associated with application or product planning, including collecting stakeholder ideas, describing the business vision, defining the project scope in terms of high-level business requirements, developing the business case, and assuming business justification, approving the project for implementation. *Requirements Elicitation:* The activities associated with working with the business to understand their core needs, including engaging business stakeholders, facilitating and conducting requirements elicitation meetings, discovery and gathering of requirements, and confirming business goals, expectations and success criteria for the project. *Requirements Specification:* The activities associated with organizing and detailing the project requirements, including analyzing the requirements gathered during elicitation, defining a glossary of business terms, modeling business processes and use cases, identifying key business rules, designing user experiences, storyboarding interaction flows, prototyping applications, defining functional and non-functional requirements, and publishing requirements documents and specifications. *Requirements Validation:* The activities associated with confirming project requirements with both business and IT stakeholders, including scheduling requirements reviews, preparing review packages, distributing review requests, providing requirements feedback, collecting and incorporating feedback for subsequent review, securing stakeholder approval, and maintaining the review history. *Requirements Management:* The activities associated with tracking project requirements throughout the lifecycle, including uniquely identifying requirements, prioritizing requirements, classifying and storing requirements, linking and cross-referencing requirements, baselining requirements for traceability, processing requirements change requests, versioning requirements, and reporting on requirements status. This organization should make it easier to communicate and collaborate on Scenario definition, while also mapping more clearly to potential touchpoints between products across the RDM lifecycle. This could include integrations between the following products: * Project & Portfolio Management (PPM) * Business Process Modeling & Analysis * Use Case Modeling & Specification * Requirements Elicitation & Validation * User Experience Design * Application Simulation & Prototyping * Requirements Management * Project Management --- *Requirements Planning Scenarios* (RPS) _RPS-1: Project is Proposed_ _RPS-2: Project is Evaluated_ _RPS-3: Project is Approved_ --- *Requirements Elicitation Scenarios* (RES) RES-1: RES-2: RES-3: --- *Requirements Specification Scenarios* (RSS) RSS-1: RSS-2: RSS-3: --- *Requirements Validation Scenarios* (RVS) _RVS-1: Requirements Review Package Prepared_ _RVS-2: Requirements Review Package Distributed_ _RVS-3: Requirements Review Feedback Captured_ _RVS-4: Requirements Review Feedback Received_ _RVS-5: Requirements Review Feedback Incorporated_ --- *Requirements Management Scenarios* (RMS) _RMS-1: Requirements Collection Posted_ _RMS-2: Requirements Collection Implemented_ _RMS-3: Requirements Collection Verified_ _RMS-4: Requirements Collection Delivered_ _RMS-5: Requirements Deficiency Identified_ _RMS-6: Requirements Change Requested_ _RMS-7: Requirements Change Verified_ ---++ Comments Add your comments here: After our discussion, I suggest a modification to the lifecycle model shown in the graphic in this article. We can combine "elicit, specify, and validate" into a single "bubble" (perhaps "define requirements"), and add a new bubble, "implement" which overlaps with "manage". Scenario A around linking requirements with implementation and test then is part of the "implement" bubble (note that just as validating that the stated requirements are precisely what's intended would now be part of the "define" bubble, so would validating that the implementation meets the requirement, which is part of the scenario, is part of the "implement" bubble), and Scenario B, about an enhancement, is in the overlap between manage and implement. With this revised high level life cycle, we can deal with the worries that "you can't do everything at once". We could start working on two or three scenarios, but balance between the "downstream" manage and implement bubbles, and the "upstream" plan and define. I suggest we look at scenario A and find a "define" scenario so that we get a more balanced view of what a "requirement resource" needs to be. Then the sub-committee that Ian is forming to define the resource representation has a better input. -- Main.AndyBerner - 11 Aug 2009 %COMMENT%
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r8
<
r7
<
r6
<
r5
<
r4
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r8 - 12 Aug 2009 - 18:16:06 -
DavidRuiz
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback