COMP 1821 - Requirements Engineering & LSEP Issues

Vocabulary flashcards covering key concepts from Requirements Engineering, including elicitation, functional vs non-functional classifications, specification notations, LSEP design goals, and analysis models.

Requirement

An externally observable characteristic of a desired system that must meet two criteria: (1) it must be externally observable, and (2) it must be desired.

Requirements Definition

A high-level abstract description of requirements specifying external system behavior, services, and operational constraints in a way that is comprehensible by the customer, management, and users.

Requirements Engineering

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

Requirements Elicitation

The phase where technical staff work with customers and stakeholders to discover the application domain, required system services, and operational constraints.

User Requirements

Statements in natural language plus diagrams describing the services the system provides and its operational constraints, written primarily for customers.

System Requirements

A structured document setting out detailed descriptions of the system's functions, services, and operational constraints, defining what should be implemented for developers and contractors.

User and System Requirements Readers

User requirements are read by client managers, system end-users, client engineers, contractor managers, and system architects. System requirements are read by system end-users, client engineers, system architects, and software developers.

Functional Requirements

Statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in certain situations.

Non-Functional Requirements

Constraints on the services or functions offered by the system, such as timing constraints, standards, or development process requirements, which often apply to the overall system.

Domain Requirements

System requirements and constraints derived directly from the specific operational domain of the system.

Complete Requirements

A property of a requirements document where descriptions of all facilities required by the customer are included.

Consistent Requirements

A property of a requirements document where there are no conflicts or contradictions in the descriptions of the system facilities.

Goal (in Requirements Engineering)

A general intention of the user, such as ease of use, which helps convey user expectations to developers.

Verifiable Non-Functional Requirement

A non-functional requirement statement formulated using specific, objective measures that can be tested.

Product Requirements

A class of non-functional requirements specifying that the delivered product must behave in a particular way, such as execution speed or reliability.

Organisational Requirements

A class of non-functional requirements resulting from organizational policies and procedures, such as process standards or implementation requirements.

External Requirements

A class of non-functional requirements arising from factors external to the system and its development, such as interoperability or legislative requirements like GDPR.

Structured Natural Language

A requirement specification notation written in natural language on a standard form or template, where each field provides information about an aspect of the requirement.

Design Description Languages

An approach using a programming-like language with abstract features to specify requirements by defining an operational model of the system, useful for interface specifications.

Graphical Notations

Graphical models supplemented by text annotations used to define functional requirements, such as UML use case and sequence diagrams.

Mathematical Specifications

Unambiguous requirement notations based on mathematical concepts such as finite-state machines or sets.

Structured Systems Analysis and Design (SSAD)

A requirement specification approach using process models, data models, and behavior models through orderly decomposition.

Object Oriented Analysis and Design (OOAD)

A requirement specification approach using Use Case, Object, and Dynamic models in an iterative and incremental manner supporting abstraction rather than decomposition.

Requirements Checking Criteria

The five standard checks performed on requirements: Validity, Consistency, Completeness, Realism, and Verifiability.