Although many groups have created definitions, there is no standard requirements terminology.

Allocate: to map or assign to.

Business requirements: see user requirements on this page. Some authors define business requirements as the high-level goals and objectives of the system.

Child: a child requirement has a hierarchical relationship to its parent.  The parent requirement is not satisfied (met) until all of its children are satisfied.

Decompose: to break down into component parts.  For example, ABCD decomposes to AB and CD.  AB then decomposes to A and B, and CD decomposes to C and D.  The Magic Square diagrams the relationship between decomposition and refinement.

Deliverable: a work product or item to be delivered, usually specified in a contract.

Derived: derived requirements trace back to a driving requirement(s). The derived requirement is identified during the development process. The driving requirement is not satisfied unless the derived requirement is. Interfaces with other systems are an example of derived requirements. Some authors use derive to mean decompose.

Design: design specifications address how the system will accomplish the functional requirements and include: algorithms, input/output formats, interface descriptions, and data definitions. Defining architecture is part of the design process.

Diagrams: see models on this page.

Functional primitive: in a data flow diagram, the bottom-most bubble, which is reached when further decomposition would yield the function's logic (if then or case,case) rather than child functions.

Functional requirement: these include inputs, outputs, calculations, external interfaces, communications, and special management information needs. Functional requirements are also called behavioral requirements because they address what the system does.

Gap analysis: an analysis of the gap between requirements that are met and not met; a deficiency assessment.

Gold plating: adding more to the system than specified in the requirements. Gold plating is not a bargain. It can increase operation and maintenance costs and reduce quality. Gold plating indicates project processes are out of control. Gold plating can also be accomplished by adding unnecessary requirements. Risk adjusted cost-benefit analyses can help avoid this form of gold plating.

Inverse: a requirement stated as a negative proposition (shall not).  An inverse requirement is untestable. See more about negative requirements. Read more about what can make a requirement untestable.

Models: models are an idealized view of reality. A model is devised to provide a certain view of the requirements; consequently, selection of the appropriate modelling type for a particular system is important. Because models do not depict every requirement category, they must be supplemented with text requirements. Some examples of model types include: prototypes, data flow diagrams, story boards, and entity relationship diagrams.

Non-functional: these requirements include areas such as performance and design and implementation constraints. Also known as non-behavioral because they address an attribute or quality of the system. In general, these requirements are not decomposed, but require proxies. See some categories of performance requirements.

Non-technical: agreements, conditions, and/or contractual terms that affect and determine the management activities of a project. See some requirements categories.

Parent: parent and child requirements have a hierarchical relationship.  In functional decomposition, a parent may have many children, but a child can have only one parent.  Where there is more than one level of decomposition, some requirements will be both parent and child.  Functional primitives have no children. Some authors refer to them as "leaves." Parent-child is also used to describe traceable relationships. Traceable relationships can be one-to-one, one-to-many, many-to-one, or many-to-many.

Process specification: describes what is happening inside the functional primitive. It is also called a "mini-spec."

Proxy: may be used in place of an untestable requirement that cannot be decomposed.  For example, the requirement to be "user friendly" could have a proxy that online help be available. See some proxy examples.

Requirement: something wanted or needed. Term is often used to mean "system functional requirement."

Requirements definition: an assessment of the needs a system is to fulfill, including why the system is needed; what features will service or satisfy the need; and how the system is to be constructed.

SDLC: system development life cycle, which includes the activities prior to operations and maintenance. "System life cycle" includes development, operations and maintenance through to system decommission.

System-level: requirements that address an entire system, a major system division (e.g., hardware or software), or more than one subsystem; global requirements. It is not the breadth of the wording that makes a requirement system-level, but the extent of its impact on the system. More information about requirement levels.

System requirement: usually used as shorthand for "system functional requirement" but, depending on the speaker's perspective, could also mean "system-level," "operating system," or something else.  Clarify what the speaker means to avoid miscommunication.

System functional requirement: these requirements specify a condition or capability that must be met or possessed by a system or its component(s). System functional requirements include functional and non-functional requirements. System functional requirements are developed to directly or indirectly satisfy user requirements.

Traceable: the origin of each requirement or requirement satisfier is clear (backwards trace); the allocation or satisfier of a requirement is clear (forwards trace).

User requirements: address what users need to do their jobs.  These requirements are implementation independent and are sometimes called "business requirements." Read about the importance of user requirements.

Validation: includes what is commonly thought of as testing and comparing test results to expected results. Validation occurs at the end of the development process.

Verification: uses reviews, inspections, and demonstrations throughout development to ensure the quality of the product of that phase, including that it meets the requirements from the previous phase.

Work Breakdown Structure: The WBS is a categorization or hierarchical set of codes assigned to some activities and to products that will result from the project.  It is used in developing a project plan. A WBS provides a single, consistent, and visible framework for reporting progress, for identifying status of planned and expended costs, and for controlling expenditures throughout the life of a project. A WBS is independent of time: it indicates what is to be done, not how, when, or by whom. Because what is to be done is based on requirements, it makes sense to associate requirements and WBS codes.

Find more definitions: Wideman Comparative Glossary of Project Management Terms

Page updated 8/22/2008
Ludwig Consulting Services, LLC