Lecture 3: Software Requirements - Vocabulary Flashcards

Vocabulary flashcards covering key terms and concepts from Lecture 3 on Software Requirements, including definitions of requirements, types, quality attributes, and common guidelines.

Requirement

A singular documented need of what a product or service should be or perform.

IEEE Definition of a Requirement

(1) a condition or capability needed by a user to solve a problem or achieve an objective; (2) a condition or capability that must be met by a system or component to satisfy a contract, standard, or specification.

Requirement Engineering

The process of establishing the services the customer requires from a system and the constraints under which it operates and is developed.

User requirements

Statements in natural language (and diagrams) about the services and constraints written for customers.

System requirements

A structured document detailing the system’s services and constraints; usually a contract between client and contractor.

SRS (Software Requirements Specification)

The official statement of what is required of the system developers; recorded in natural language, formal, symbolic, or graphical representations.

Use-case

A graphical language (often with text) used to define functional requirements; commonly represented to illustrate how the system will be used.

Unitary (Cohesive) requirement

A requirement that addresses one and only one thing.

Complete requirement

Fully stated in one place with no missing information.

Consistent requirement

Does not contradict any other requirement.

Atomic (Non-Conjugated) requirement

Atomic in form; does not contain conjunctions; should be split into separate requirements.

Traceable requirement

A requirement that can be traced backward to business needs and forward to design, implementation, and tests.

Feasible requirement

A requirement that can be implemented within the project’s constraints.

Unambiguous requirement

Concise and free from vagueness or jargon; one clear interpretation.

Mandatory requirement

A stakeholder-defined characteristic whose absence would cause a deficiency.

Verifiable requirement

A requirement whose implementation can be verified through inspection, demonstration, or testing.

Functional requirements

Statements describing what the system must do; include inputs, outputs, exceptions, data, workflows, and reports.

Non-functional requirements

Constraints on the software itself and how well it performs its functions (e.g., timing, standards, security).

Performance requirement

A non-functional requirement specifying timing or throughput (e.g., response time, capacity).

Design constraints

Constraints such as required database systems or memory limits that shape the solution.

Design directives

Guidelines on how to design certain functionality (e.g., use of a specific algorithm).

Implementation directives

Guidelines on how to implement functionality (e.g., preferred programming language for portability).

NFR Classification

Categories of non-functional requirements including product, organizational, external; with types like efficiency, reliability, portability, usability, privacy, safety.

Requirements Analysis problems

Issues like ambiguities, platitudes, omissions, inconsistencies, mixtures of abstraction, and FRs/NFRs mixed up.

Ambiguity in natural language

NL can be interpreted differently by readers and writers, leading to confusion.

Platitudes in requirements

Vague FRs or non-measurable NFRs that are untestable.

Omissions in requirements

Essential information left out of a requirement.

Inconsistencies in requirements

Contradictory statements within or between requirements.

Mixtures of abstraction

Different levels of detail in the same section of a requirements document.

FRs and NFRs mixed up

Functional and non-functional requirements stated together in a confusing way.

Alternatives to natural language

Structured language, program-description language, graphical notations (Use-case), and formal specifications.

Audiences for SRS

Customers, project managers, developers, testers, maintenance staff, publications, and training personnel.

Guidelines for writing requirements (numbering, phrasing)

Use a standard numbering format; use ‘shall’ for mandatory, ‘should’ for desirable; avoid jargon; quantify when possible.