Chapter 01: Software Requirements

A set of vocabulary flashcards based on SWEBOK Chapter 1, covering the fundamental concepts, categories, activities, and tools of software requirements.

ATDD

Acceptance Test Driven Development

BDD

Behavior Driven Development

CIA

Confidentiality, Integrity, and Availability

FSM

Functional Size Measurement

INCOSE

International Council on Systems Engineering

JAD

Joint Application Development

JRP

Joint Requirements Planning

SME

Subject Matter Expert

SysML

Systems Modeling Language

TDD

Test Driven Development

UML

Unified Modeling Language

Software Requirement (Formal Definition)

A condition or capability needed by a user to solve a problem or achieve an objective, or a condition that must be met by a system to satisfy a contract, standard, or formally imposed document.

Incompleteness

A primary requirements problem where stakeholder needs and necessary details exist but are not revealed or communicated to software engineers.

Ambiguity

A requirements problem where communications are open to multiple interpretations, with only one being correct.

Defect (Bug)

An observable difference between what the software is intended to do and what it actually does.

Software Product Requirements

Specifications that describe the software's expected form, fit, or function.

Software Project Requirements

Also called process or business requirements, these constrain the project constructing the software, such as cost, schedule, and staffing.

Functional Requirements

Specifications of observable behaviors, policies to be enforced, and processes to be carried out by the software.

Nonfunctional Requirements

Constraints on the technologies used in the implementation or the performance levels of the automated solution.

Technology Constraints

Requirements that mandate or prohibit the use of specific automation technologies or infrastructures, such as specific programming languages or database engines.

Quality of Service (QoS) Constraints

Requirements specifying acceptable performance levels, such as response time, throughput, accuracy, reliability, and scalability.

Perfect Technology Filter

A concept used to separate functional from nonfunctional requirements by assuming a computer with infinite speed, memory, and zero cost exists.

System (INCOSE Definition)

An interacting combination of elements, including hardware, software, firmware, people, and facilities, intended to accomplish a defined objective.

Derived Requirements

Requirements not made by an external stakeholder but imposed inside the development team, such as an architect's design decision seen as a requirement by a sub-team.

Requirements Development

The collective activities involved in reaching an agreement on what software is to be constructed.

Requirements Management

The process of maintaining the agreement on software requirements over time.

Stakeholder

Any person, group, or organization actively involved in a project, affected by its outcome, or able to influence its outcome.

Stakeholder Analysis

The process of identifying important stakeholder classes to reduce bias in requirements and inform conflict resolution.

5-whys Technique

A method involving repeated questioning to converge on the true problem rather than a suggested solution.

Perfection Point

The most favorable level of performance in an economic value curve beyond which there is no additional benefit to the customer.

Fail Point

The least favorable level of performance in an economic value curve beyond which there is no further reduction in benefit.

Most Cost-Effective Performance Level

The performance level where the positive difference between the value and the cost to achieve it is at its maximum.

Priority Formula Example

$$\text{Priority} = \frac{\text{Value} \times (1 - \text{Risk})}{\text{Cost}}$$

Formal Analysis

The use of specification languages with formally defined semantics to reduce misinterpretation and permit reasoning/proof of software properties.

Product Family Development

An approach to managing conflict by separating requirements into invariants (agreed upon by all) and variants (where conflict exists).

Unstructured Natural Language

A requirements specification format using common, ordinary language statements, often following a "The system shall…" pattern.

Actor-Action Format

A structured natural language format consisting of a triggering event, an actor, an action, and optional conditions.

ATDD Process

A three-step cycle where a unit of functionality is selected, test cases are agreed upon before construction, and code is written only to pass a failing test case.

BDD Scenario Format

A structured form for specifying unit functionality: "Given , when , then ."

Structural Models

Model-based specifications used for specifying policies to be enforced, such as logical class models or entity-relationship diagrams.

Behavioral Models

Model-based specifications for processes, including use case modeling, interaction diagrams, and state modeling.

Incremental Specification

A documentation approach where a requirements version contains only additions, modifications, and deletions from the previous version.

Comprehensive Specification

A documentation approach where each version contains all requirements, allowing the reader to find everything in a single document.

Requirements Validation

The process of gaining confidence that requirements represent stakeholders' true needs through reviews, simulation, or prototyping.

Requirements Scrubbing

The process of finding the smallest set of requirements that meet stakeholder needs by eliminating out-of-scope or low-ROI items.

Scope Matching

Ensuring the scope of requirements does not exceed a project's cost, schedule, or staffing constraints.

Kano Model

A prioritization framework that weights both the satisfaction from having a feature and the dissatisfaction from lacking it.

Requirements Tracing

The practice of documenting consistency between related work products, such as tracing a requirement forward to design elements or backward to source documentation.

Functional Size Measurement (FSM)

A technique for evaluating the size of a body of functional requirements.

Requirements Modeling Tools

Tools that support visual creation and modification of models, and sometimes provide static analysis or simulation.