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 NameAn 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. AssumptionsRefer to section 6 of the Volere Requirements Specification Template for more details about assumptions. Blastoff Meeting PlanAdvice to the stakeholders on the schedule, location, and objectives for the project blastoff meeting. Blastoff ObjectivesDeliverables to be produced by the blastoff are some combination of the following depending on the Project Intention:
Blastoff ParticipantsName and contact details for each person who is invited to attend the project blastoff meeting. Blastoff ReportReport describing what was accomplished by the blastoff meeting. Business DocumentsReports, forms, specifications, user manualsany document that might contain requirements buried in its depths. Business EventBusiness Event Name + (Event Input + Adjacent System Name) + {Event Output + Adjacent System Name} The work context boundaries of a business event. Business Event BoundaryEvent 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 OpportunitiesIdeas for how the product can help to achieve the Product Purpose within the Project Constraints. Client NameThe name of the person or organization who will pay for the development of the product. Context InterfacesNamed interfaces between your system and the world outside your scope of study. Contradictory RequirementsContradictions between requirements, discovered during the requirements review. Current Organization and SystemsDescription 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 ModelA 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 NameThe name of the person(s) or organization(s) that will buy, or are expected to buy, the product. Customer Value RatingsCustomer 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 ModelsModels that capture the essence of a particular area of subject matter. Event Effort EstimatesEstimated effort in implementing a solution to a use case/event. Event for PrototypingProduced 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 ModelEvent 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 DocumentsReports, forms, specifications, user manualsany document that might contain requirements buried in its depths. Fit Reviewed RequirementDescription 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 ConstraintSystem ConstraintsA system constraint that has been formally written according to the guidelines in the Volere Requirements Specification Template. Functional RequirementRequirementRefer to section 9 of the Volere Requirements Specification Template for more details. Go/No-Go DecisionRecommendation based on blastoff results regarding whether to proceed with the project plus the reason for that recommendation. Gold-Plated RequirementA requirement that is not essential to solving the stated business objectives. Group CommentsRetrospective comments made by the group. high-fidelity PrototypeAn automated prototype. Identified StakeholdersClient 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 CommentsRetrospective comments made by an individual. There might be a need to keep these confidential. Initial EstimateFirst-cut estimate of the effort required to build the system. Input from GroupsInput from groups collected by the facilitator. Input from IndividualsInput from individuals collected by the facilitator. Intended Operating EnvironmentDetails of the environment in which the product will be installed. Intended Operating Environment DescriptionA detailed description of the hardware, software, people, and environmental factors under which the product must operate. Knowledge SourcesAny person, place, organization, or document that contains or might contain knowledge about the work within the work context. Low-Fidelity PrototypeA non-automated prototype usually built using some combination of graphic models, screen layouts, and written examples. Major RisksA blitzed list of the major risks associated with building the product. Meeting LocationAddress of the place at which the project blastoff meeting will be held. Meeting ScheduleTime(s) and date(s) for which the project blastoff meeting is scheduled. Missing RequirementsRequirements types that should be included. Nonfunctional RequirementRequirement Refer to sections 1017 of the Volere Requirements Specification Template for more details about nonfunctional requirements. Objective of PrototypeWhy we are building the prototype; what we expect to gain; what are the questions to which we require answers. Points for ClarificationMeetings with individuals sometimes raise questions that the facilitator needs to clarify when meeting with groups. Retrospective CommentsIndividual Comments + Project Participant Comments + Group Comments Retrospective ReportA report whose purpose is to communicate noteworthy experiences of the project in a form that is usable by other people. Potential RequirementA 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 StakeholdersA list of people considered to have an interest in the project. Product ScopeUse Case + {Business Event Name} Project ConstraintRefer to section 6 of the Volere Requirements Specification Template for more details. Project ConstraintsConstraints on the way that the product must be produced:
Project HistoryProject Plans + Project Progress History + Specification Changes Project IntentionGuidelines from the customer:
Project Participant CommentsComments made by participants at the retrospective meeting Project PurposeBusiness 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 EffortTime to Build Prototype + Context of Prototype + Form of Prototype Prototypes{[Low-Fidelity Prototype | high-fidelity Prototype] + Prototyping Metrics} Prototyping MetricsContext 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 OpportunityContext of Prototype + Objective of Prototype + Interested Stakeholders + {Requirement} Prototyping PlanContext of Prototype + Objective of Prototype + Interested Stakeholders + [Low-Fidelity Prototype | high-fidelity Prototype] + Existing Prototypes + Prototyping Tool Quantified FindingsThe result of the facilitator reviewing all comments from individuals and from groups. Rejected RequirementA requirement or constraint that has failed to pass through the Quality Gateway. Relevance Reviewed RequirementA requirement that has passed the Quality Gateway's relevance test. Relevant FactsRefer to section 5 of the Volere Requirements Specification Template for more details. Required FacilitiesAll the physical arrangements necessary to satisfy the Blastoff Objectives, including:
RequirementRequirement 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 SummaryLists 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 MeasurementDescription of Requirement + Purpose of Requirement + Requirement Type + Unique Identifier for a Requirement + Requirement Fit Criteria + Customer Satisfaction + Customer Dissatisfaction Requirement QuestionsOutstanding 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 FilterA tool for assessing the completeness of a requirements specification. Requirements SkeletonProduct 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 SpecificationProduct Purpose + Product Context + Identified Stakeholders + {Use Case} + System Terminology + {Functional Requirement} + {Nonfunctional Requirement} + {Project Constraint} + Assumptions + Relevant Facts + Project Issues + Requirement Interaction Summary Requirements TemplateTemplate for a requirements specification. See the example Volere Requirements Specification Template. Reusable RequirementA 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 SpecificationRequirements Specification + Risk Analysis + Effort Estimates Risk AnalysisDetailed assessment of all risks identified by doing a risk analysis of the requirements specification. Risk ChecklistRisk checklists produced by researchers such as Capers Jones and Barry Boehm. Stakeholder Wants and NeedsFunctional requirements, nonfunctional requirements, and constraints that the stakeholders want the system to have. Strategic Plan for ProductProduct 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 ConstraintsProduct Purpose + Identified Stakeholders + Business Events + System Terminology + Project Constraints + Relevant Facts + Assumptions System ExperienceRelevant experience of the stakeholders in building similar products, using similar technology, dealing with similar problems, and/or working in a similar environment. System TerminologyDefinitions 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 TechniquesA variety of techniques used by requirements engineers and business analysts for discovering requirements. Usage FeedbackUser comments, new requirements, and requirements changes as a result of using a prototype. Use CaseUse Case Name + {Actor Name} + Use Case Boundary Data User GroupUser Group Name + User Group Skills Work ContextA 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 DemonstrationCurrent Organization and Systems + Business Documents + Stakeholder Experience Work KnowledgeWork 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. |