Glossary of Requirements Engineering Terms

acceptance criteria: Conditions that a software product must satisfy to be accepted by a user, customer, or other stakeholder.

activity diagram: An analysis model that shows a dynamic view of a system by depicting the flow from one activity to another. Similar to a flowchart.

actor: A person, software system, or hardware device that interacts with a system to achieve a useful goal. Also called a user role.

allocation: See requirements allocation.

alternative flow: A scenario in a use case that leads to success (accomplishing the actor’s goal) but involves a variation from the normal course in the specifics of the task or of the actor’s interaction with the system. Also known as an alternative course.

analysis, requirements: The process of classifying requirements information into various categories, evaluating requirements for desirable qualities, representing requirements in different forms, deriving detailed requirements from high-level requirements, negotiating priorities, and so on.

analyst: See requirements analyst.

architecture: The structure of a software-containing system, including the software and hardware components that make up the system, the interfaces and relationships between those components, and the component behaviors that are visible to other components.

assumption: A statement that is believed to be true in the absence of proof or definitive knowledge.

attribute, requirement: See requirement attribute.

baseline, requirements: A snapshot in time representing the current agreed-upon, reviewed, and approved set of requirements for a specific product release.

business analyst: See requirements analyst.

business requirement: A high-level business objective of the organization that builds a product or of a customer who procures it.

business rule: A policy, guideline, standard, or regulation that defines or constrains some aspect of the business.

cardinality: The number of instances of a given object or data entity that logically relates to an instance of another object or entity. Examples are one-to-one, one-to-many, and many-to-many.

change control board: The group of people responsible for making decisions to accept or reject proposed changes in software requirements.

class: A description of a set of objects having common properties and behaviors, which typically correspond to real-world items (persons, places, or things) in the business or problem domain.

class diagram: An analysis model that shows a set of system or problem domain classes and their relationships.

constraint: A restriction that is imposed on the choices available to the developer for the design and construction of a product.

context diagram: An analysis model that depicts a system at a high level of abstraction. The context diagram identifies objects outside the system that interact with it, but it shows nothing about the system’s internal structure or behavior.

COTS (commercial off-the-shelf ) product: A software package purchased from a vendor and either used as a self-contained solution to a problem or integrated, customized, and extended to satisfy local customer needs.

CRUD matrix: A table that correlates system actions with data entities to show where each data item is created, read, updated, and deleted.

customer: A project stakeholder who requests, pays for, selects, specifies, uses, or receives the output generated by a product.

data dictionary: A collection of definitions for the data elements, structures, and attributes that are important to the problem domain.

data flow diagram: An analysis model that depicts the processes, data collections, and flows among them that characterize the behavior of a business process or of a software system.

decision rule: An agreed-upon way by which a body of people arrives at a decision.

decision table: A table that shows all combinations of values for a set of factors that influence a portion of a system’s behavior and indicates the expected system action in response to each combination.

decision tree: An analysis model that graphically shows a system’s actions in response to all combinations of a set of factors that influence a portion of the system’s behavior.

dependency: A reliance that a project has on an external factor, event, or group outside its control.

dialog map: An analysis model that depicts a user interface architecture, showing the display elements and the navigations permitted between them.

elicitation, requirements: The process of identifying software or system requirements from various sources through interviews, workshops, workflow and task analysis, document analysis, and other mechanisms.

entity: An item in the business domain about which data will be collected and stored.

entity-relationship diagram: An analysis model that identifies the logical relationships between pairs of entities.

essential: Devoid of implementation specifics and constraints. An essential model depicts information at a conceptual level, independent of how it might be implemented in a system.

event: A trigger or stimulus that takes place in a system’s environment that leads to a system reponse, such as a functional behavior or a change in state.

event-response table: A list of the external or time-triggered events that could affect the system and a description of how the system is to respond to each event.

evolutionary prototype: A fully-functional prototype created as a skeleton or an initial increment of the final product, which is fleshed out and extended incrementally as requirements become clear and ready for implementation.

exception: A condition that prevents a use case from successfully concluding. The use case’s postconditions are not reached and the actor’s goal is not satisfied.

extends relationship: A construct in which an alternative course in a use case interrupts the normal sequence of steps. The steps that the actor follows when executing the alternative course can be packaged into an extension use case that is invoked to complete the alternative.

external interface requirement: A description of an interface between a software system and a user, another software system, or a hardware device.

Extreme Programming: An "agile" software development methodology characterized by face-to-face collaboration between developers and an on-site customer representative, limited documentation of requirements in the form of "user stories," and rapid and frequent delivery of small increments of useful functionality.

facilitator: A person who is responsible for planning and leading a group activity, such as a requirements elicitation workshop.

feature: A set of logically related functional requirements that provides a capability to the user and enables the satisfaction of a business objective.

flowchart: An analysis model that shows the processing steps and decision points in the logic of a process or of a program.

function point: A measure of software size, based on the number and complexity of internal logical files, external interface files, external inputs, outputs, and queries.

functional requirement: A statement of a piece of required functionality or a behavior that a system will exhibit under specific conditions.

gold plating: Unnecessary or excessively complex functionality that is specified or built into a product.

horizontal prototype: A partial or possible implementation of a user interface for a software system. Used to evaluate usability and to assess the completeness and correctness of requirements. Also called a behavioral prototype or a mock-up.

IEEE: The Institute of Electrical and Electronics Engineers. A professional society that maintains a set of standards for managing and executing software and systems engineering projects.

includes relationship: A construct in which several steps that recur in multiple use cases are factored out into a separate use case, which the parent use cases then invoke when needed.

inspection: A type of peer review that involves a trained team of individuals who follow a well-defined and rigorous process to examine a work product carefully for defects.

navigation map: See dialog map.

nonfunctional requirement: A description of a property or characteristic that a software system must exhibit or a constraint that it must respect, other than an observable system behavior.

normal flow: The default sequence of steps in a use case, which leads to satisfying the use case’s postconditions and letting the user achieve his goal. Also known as the normal course, main course, normal sequence, and main success scenario.

object: A specific instance of a class for which a set of data attributes and a list of operations that can be performed on those attributes can be collected. For example, "Mary Jones" is a specific instance of the class "Customer."

operational profile: A suite of scenarios that represent the expected usage patterns of a software product.

paper prototype: A nonexecutable mock-up of a software system’s user interface using inexpensive, low-tech screen sketches.

peer review: An activity in which one or more persons other than the author of a work product examine that product with the intent of finding defects and improvement opportunities.

pilot: A controlled execution of a new process with the objective of evaluating the new process under real project conditions to assess its readiness for general deployment.

Planguage: A keyword-oriented language developed by Tom Gilb that permits precise and quantitative specification of requirements.

postcondition: A condition that describes the state of a system after a use case is successfully completed.

precondition: A Condition that must be satisfied before a use case may begin.

procedure: A written description of a course of action to be taken to perform a given activity, describing how the activity is to be accomplished.

process: A sequence of activities performed for a given purpose. A process description is a documented definition of those activities.

process assets: Documents such as templates, forms, checklists, procedures, process descriptions, and sample work products that are collected to assist an organization’s effective application of improved software development practices.

product champion: A designated representative of a specific user class who supplies the user requirements for the group that he or she represents.

prototype: A partial, preliminary, or possible implementation of a program. Used to explore and validate requirements and design approaches. Types of prototypes include evolutionary, throwaway, paper, horizontal, and vertical. These can be combined, as in an evolutionary vertical prototype.

quality attribute: A kind of nonfunctional requirement that describes a quality or property of a system. Examples include usability, portability, maintainability, integrity, efficiency, reliability, and robustness. Quality attribute requirements describe the extent to which a software product demonstrates desired characteristics, not what the product does.

requirement: A statement of a customer need or objective, or of a condition or capability that a product must possess to satisfy such a need or objective. A property that a product must have to provide value to a stakeholder.

requirement attribute: Descriptive information about a requirement that enriches its definition beyond the statement of intended functionality. Examples include origin, rationale, priority, owner, release number, and version number.

requirements allocation: The process of apportioning system requirements among various architectural subsystems and components.

requirements analyst: The role on a project team who has lead responsibility for working with stakeholder representatives to elicit, analyze, specify, validate, and manage the project’s requirements. Also called a business analyst, system analyst, requirements engineer, and simply analyst.

requirements development: The process of defining a project’s scope, identifying user classes and user representatives, and eliciting, analyzing, specifying, and validating requirements. The product of requirements development is a requirements baseline that defines the product to be built.

requirements engineering: The domain that encompasses all project life cycle activities associated with understanding a product’s necessary capabilities and attributes. Includes requirements development and requirements management. A subdiscipline of system engineering and software engineering.

requirements management: The process of working with a defined set of product requirements throughout the product’s development process and its operational life. Includes tracking requirements status, managing changes to requirements and versions of requirements specifications, and tracing individual requirements to other project phases and work products.

requirements specification: See software requirements specification and specification, requirements.

requirements traceability matrix: A table that illustrates logical links between individual functional requirements and other types of system artifacts, including other functional requirements, use cases, architecture and design elements, code modules, test cases, and business rules.

retrospective: A review in which project participants reflect on the project’s activities and outcomes with the intent of identifying ways to make the next project be even more successful.

risk: A condition that could cause some loss or otherwise threaten the success of a project.

root cause analysis: An activity that seeks to understand the underlying factors that contribute to an observed problem.

scenario: A description of a specific interaction between a user and a system to accomplish some goal. An instance of usage of the system. Often presented in the form of a story.

scope: The portion of the ultimate product vision that the current project will address. The scope draws the boundary between what’s in and what’s out for the project.

scope creep: A condition in which the scope of a project continues to increase, typically in an uncontrolled fashion, throughout the development process.

sequence diagram: An analysis model that shows the order in which messages pass in a system or the chronological sequence of steps that take place in an activity and the entities or classes involved in the activity.

software development life cycle: A sequence of activities by which a software product is defined, designed, built, and verified.

software requirements specification: A collection of the functional and nonfunctional requirements for a software product.

specification, requirements: The process of documenting a system’s requirements in a structured, shareable, and manageable form. Also, the product from this process (see software requirements specification).

stakeholder: A person, group, or organization that is actively involved in a project, is affected by its outcome, or can influence its outcome.

statechart diagram: An analysis model that shows the sequence of states that an object in a system goes through during its lifetime in response to specific events that take place. Similar to a state-transition diagram.

state-transition diagram: An analysis model that shows the various states that a system can be in, or the statuses that an object in the system can have, and the permitted transitions that can take place between states. Similar to a statechart diagram.

subject matter expert: An individual who has extensive experience and knowledge in a domain and who is recognized as an authoritative source of information about the domain.

system requirement: A top-level requirement for a product that contains multiple subsystems, which could be all-software or software and hardware.

template: A pattern to be used as a guide for producing a complete document or other item.

terminator: An object on a context diagram or a data flow diagram that represents a user class, actor, software system, or hardware device that is external to the system being described but interfaces to it in some fashion. Also called an external entity.

throwaway prototype: A prototype that is created with the express intent of discarding it after it has served its purpose of clarifying and validating requirements and design alternatives.

tracing (also traceability): The process of defining logical links between one system element (use case, functional requirement, business rule, design component, code module, test case, and the like) and another.

usage scenario: See scenario.

use case: A description of an interaction between an actor and a system that results in an outcome that provides value to the actor.

use case diagram: An analysis model that identifies the actors who can interact with a system to accomplish valuable goals and the various use cases that each actor will perform.

user: A customer who will interact with a system either directly or indirectly (for example, using outputs from the system but not generating those outputs personally). Also called end user.

user class: A group of users for a system who have similar characteristics and requirements for the system.

user requirement: User goals or tasks that users must be able to perform with a system, or statements of the user’s expectations of system quality.

user role: See actor.

validation: The process of evaluating a work product to determine whether it satisfies customer requirements.

verification: The process of evaluating a work product to determine whether it satisfies the specifications and conditions imposed on it at the beginning of the development phase during which it was created.

vertical prototype: A partial implementation of a software-containing system to evaluate technical feasibility and performance. Also called a structural prototype or proof of concept.

vision: A long-term strategic concept of the ultimate purpose and form of a new system.

vision and scope document: A document that presents the business requirements for a new system, including a product vision statement and a project scope description.

waterfall development life cycle: A model of the software development process in which the various activities of requirements, design, coding, testing, and deployment are performed sequentially with little overlap or iteration.