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:

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.

-- AndyBerner - 11 Aug 2009