Dictionary of Terms Used in the Requirements Process Model


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:

  • Project Goals

  • Work Context Model

  • Identified Stakeholders

  • Anticipated Developers

  • System Events

  • Top 10 Requirements

  • Event/Use Case Models

  • System Terminology

  • Scenario Models

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:

  • Technology to be used (or not used)

  • Budget

  • Time

  • Operating environment

Project History

Project Plans + Project Progress History + Specification Changes

Project Intention

Guidelines from the customer:

  • Product desired from the project

  • Anticipated budget

  • Technological constraints

  • Problem the product is intended to solve

  • Anticipated scope

  • Reasons for doing the project

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:

  • Accommodations

  • Stationery

  • Catering

  • Equipment

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.




Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net