Mastering the Requirements Process (2nd Edition)
Accepted Requirement
[Functional Requirement | Nonfunctional Requirement | Project Constraint] A requirement that has passed through the Quality Gateway and will be included in the requirements specification. Actor Name
An actor is a human being (usually), a job, another computer system, or another organizationanything that interacts with the product. Every use case has at least one actor. Assumptions
Refer to section 6 of the Volere Requirements Specification Template for more details about assumptions. Blastoff Meeting Plan
Advice to the stakeholders on the schedule, location, and objectives for the project blastoff meeting. Blastoff Objectives
Deliverables to be produced by the blastoff are some combination of the following depending on the Project Intention:
Blastoff Participants
Name and contact details for each person who is invited to attend the project blastoff meeting. Blastoff Report
Report describing what was accomplished by the blastoff meeting. Business Documents
Reports, forms, specifications, user manualsany document that might contain requirements buried in its depths. Business Event
Business Event Name + (Event Input + Adjacent System Name) + {Event Output + Adjacent System Name} The work context boundaries of a business event. Business Event Boundary
Event Name + {Input Data Flow + Adjacent System Name} + {Output Data Flow + Adjacent System Name} The boundary for studying a business event. Business Events
{Business Event} A list of the business events within the work context. This first-cut functional partitioning is the basis for future detailed analysis and design work. Refer to section 7 of the Volere Requirements Specification Template for more detailed information about business events. Business Opportunities
Ideas for how the product can help to achieve the Product Purpose within the Project Constraints. Client Name
The name of the person or organization who will pay for the development of the product. Context Interfaces
Named interfaces between your system and the world outside your scope of study. Contradictory Requirements
Contradictions between requirements, discovered during the requirements review. Current Organization and Systems
Description of the people who work for the organization, their roles, their responsibilities, their interactions, and the technology that they use to do their work. Current Situation Model
A model that describes aspects of an existing system. It usually focuses on the current partitioning of the problem and the interfaces between the pieces. Customer Name
The name of the person(s) or organization(s) that will buy, or are expected to buy, the product. Customer Value Ratings
Customer satisfaction on a scale from 1 to 5: 1 = Quite happy if this requirement is satisfactorily implemented 5 = Very happy if this requirement is satisfactorily implemented Customer dissatisfaction on a scale from 1 to 5: 1 = Slightly perturbed if this requirement is not satisfactorily implemented 5 = Extremely grumpy if this requirement is not satisfactorily implemented Domain Models
Models that capture the essence of a particular area of subject matter. Event Effort Estimates
Estimated effort in implementing a solution to a use case/event. Event for Prototyping
Produced when we suspect that building a prototype might lead to a better understanding of the requirements for this event or the discovery of other requirements. Event/Use Case Model
Event Name + {Functional Requirement} + {Nonfunctional Requirement} + Event Input + Event Output + (Event Description) A model that isolates the effect of one event/use case on the processes and data within the context of a system. Event/Use Case Models
{Event/Use Case Model} Existing Documents
Reports, forms, specifications, user manualsany document that might contain requirements buried in its depths. Fit Reviewed Requirement
Description of Requirement + Purpose of Requirement + Requirement Source + Requirement Type + Unique Identifier for a Requirement + Requirement Fit Criteria + Customer Satisfaction + Customer Dissatisfaction + Requirement Dependencies + Requirement History Formalized Requirement
[Functional Requirement | Nonfunctional Requirement] A potential requirement that has been formally written according to the guidelines in the Volere Requirements Specification Template. Formalized System Constraint
System Constraints
A system constraint that has been formally written according to the guidelines in the Volere Requirements Specification Template. Functional Requirement
Requirement
Refer to section 9 of the Volere Requirements Specification Template for more details. Go/No-Go Decision
Recommendation based on blastoff results regarding whether to proceed with the project plus the reason for that recommendation. Gold-Plated Requirement
A requirement that is not essential to solving the stated business objectives. Group Comments
Retrospective comments made by the group. high-fidelity Prototype
An automated prototype. Identified Stakeholders
Client Name + {Customer Name} + Sponsor Name + {User Group} + {Developer} + {Domain Expert} + {Technical Expert} People who have been identified to have an interest in the product and whose input is required during requirements gathering. Refer to sections 2 and 3 of the Volere Requirements Template for more detailed information on stakeholders. Individual Comments
Retrospective comments made by an individual. There might be a need to keep these confidential. Initial Estimate
First-cut estimate of the effort required to build the system. Input from Groups
Input from groups collected by the facilitator. Input from Individuals
Input from individuals collected by the facilitator. Intended Operating Environment
Details of the environment in which the product will be installed. Intended Operating Environment Description
A detailed description of the hardware, software, people, and environmental factors under which the product must operate. Knowledge Sources
Any person, place, organization, or document that contains or might contain knowledge about the work within the work context. Low-Fidelity Prototype
A non-automated prototype usually built using some combination of graphic models, screen layouts, and written examples. Major Risks
A blitzed list of the major risks associated with building the product. Meeting Location
Address of the place at which the project blastoff meeting will be held. Meeting Schedule
Time(s) and date(s) for which the project blastoff meeting is scheduled. Missing Requirements
Requirements types that should be included. Nonfunctional Requirement
Requirement Refer to sections 1017 of the Volere Requirements Specification Template for more details about nonfunctional requirements. Objective of Prototype
Why we are building the prototype; what we expect to gain; what are the questions to which we require answers. Points for Clarification
Meetings with individuals sometimes raise questions that the facilitator needs to clarify when meeting with groups. Retrospective Comments
Individual Comments + Project Participant Comments + Group Comments Retrospective Report
A report whose purpose is to communicate noteworthy experiences of the project in a form that is usable by other people. Potential Requirement
A need that has been discovered as a result of learning the work. It might turn out to be a requirement but we will not be sure until it has been formalized and has passed through the Quality Gateway. Potential Stakeholders
A list of people considered to have an interest in the project. Product Scope
Use Case + {Business Event Name} Project Constraint
Refer to section 6 of the Volere Requirements Specification Template for more details. Project Constraints
Constraints on the way that the product must be produced:
Project History
Project Plans + Project Progress History + Specification Changes Project Intention
Guidelines from the customer:
Project Participant Comments
Comments made by participants at the retrospective meeting Project Purpose
Business problem(s) that this product is intended to solve plus criteria for determining whether the objective(s) have been met. Refer to section 1 of the Volere Requirements Specification Template for more details about project purpose. Prototype Building Effort
Time to Build Prototype + Context of Prototype + Form of Prototype Prototypes
{[Low-Fidelity Prototype | high-fidelity Prototype] + Prototyping Metrics} Prototyping Metrics
Context of Prototype + Number of Function Points + Form of Prototype + Time to Build Prototype + Problems Experienced + Lessons Learned Measurements of how long it took to build a particular prototype within a particular environment. Prototyping Opportunity
Context of Prototype + Objective of Prototype + Interested Stakeholders + {Requirement} Prototyping Plan
Context of Prototype + Objective of Prototype + Interested Stakeholders + [Low-Fidelity Prototype | high-fidelity Prototype] + Existing Prototypes + Prototyping Tool Quantified Findings
The result of the facilitator reviewing all comments from individuals and from groups. Rejected Requirement
A requirement or constraint that has failed to pass through the Quality Gateway. Relevance Reviewed Requirement
A requirement that has passed the Quality Gateway's relevance test. Relevant Facts
Refer to section 5 of the Volere Requirements Specification Template for more details. Required Facilities
All the physical arrangements necessary to satisfy the Blastoff Objectives, including:
Requirement
Requirement Number + Requirement Type + {Use Case Number} + Requirement Description + Requirement Rationale + Requirement Source + Fit Criteria + Customer Satisfaction + Customer Dissatisfaction + {Requirement Dependency} + {Requirement Conflict} + Supporting Materials + Requirement History This identifies all components of a complete functional or nonfunctional requirement. The components are gradually added during the process of trawling for knowledge and writing the requirements. Requirement Interaction Summary
Lists interactions between requirements. Two requirements interact if a design solution to one of them makes it more difficult (or easier) to do anything about the other. Identifying requirement interaction at the specification stage provides input when evaluating requirements risk and estimating effort. Requirement Measurement
Description of Requirement + Purpose of Requirement + Requirement Type + Unique Identifier for a Requirement + Requirement Fit Criteria + Customer Satisfaction + Customer Dissatisfaction Requirement Questions
Outstanding questions that prevent a project blastoff from being considered complete or that prevent a requirement or constraint from passing through the Quality Gateway. Contains everything that is currently known about the requirement or constraint. Requirement Type
[Functional | Nonfunctional] Requirements
{Requirement} Requirements Filter
A tool for assessing the completeness of a requirements specification. Requirements Skeleton
Product Purpose + Work Context + Identified Stakeholders + Business Events + System Terminology + Initial Estimate + Major Risks + Project Constraints + Intended Operating Environment Description Used to keep track of the knowledge discovered during the blastoff. Requirements Specification
Product Purpose + Product Context + Identified Stakeholders + {Use Case} + System Terminology + {Functional Requirement} + {Nonfunctional Requirement} + {Project Constraint} + Assumptions + Relevant Facts + Project Issues + Requirement Interaction Summary Requirements Template
Template for a requirements specification. See the example Volere Requirements Specification Template. Reusable Requirement
A requirement that has been put into the Reuse Library because it is considered to be a candidate for reuse. Reuse Library
{Reusable Requirement} A collection of potentially reusable requirements. Reviewed Specification
Requirements Specification + Risk Analysis + Effort Estimates Risk Analysis
Detailed assessment of all risks identified by doing a risk analysis of the requirements specification. Risk Checklist
Risk checklists produced by researchers such as Capers Jones and Barry Boehm. Stakeholder Wants and Needs
Functional requirements, nonfunctional requirements, and constraints that the stakeholders want the system to have. Strategic Plan for Product
Product management's input into the constraints that apply to the product. External influences might cause this plan to change during the course of the requirements specification. System Constraints
Product Purpose + Identified Stakeholders + Business Events + System Terminology + Project Constraints + Relevant Facts + Assumptions System Experience
Relevant experience of the stakeholders in building similar products, using similar technology, dealing with similar problems, and/or working in a similar environment. System Terminology
Definitions of the terms that people use for data within the context of this project. Refer to section 4 of the Volere Requirements Specification Template for more details. Trawling Techniques
A variety of techniques used by requirements engineers and business analysts for discovering requirements. Usage Feedback
User comments, new requirements, and requirements changes as a result of using a prototype. Use Case
Use Case Name + {Actor Name} + Use Case Boundary Data User Group
User Group Name + User Group Skills Work Context
A summary of the parts of the world that we intend to study to satisfy the system objectives. The model shows the adjacent systems (square boxes), our specific interest in each adjacent system (interfaces), and the intersections of those adjacent systems (context process). Refer to section 8 of the Volere Requirements Specification Template for more detailed information about the work context. Work Description and Demonstration
Current Organization and Systems + Business Documents + Stakeholder Experience Work Knowledge
Work Context +Business Documents + Market Surveys + Job Descriptions + Company Reports + Current Organization and Systems + Stakeholder Experience + {Business Event Boundary + Knowledge Sources + Trawling Techniques} + {Potential Requirement} + Event Models + System Terminology + Data Models + Scenario Models Any artifact that contains knowledge about the subjects within the context of the work. |
Категории