INFOTECH 33

Requirements

The descriptions of what the system should do—the services it provides and the constraints on its operation.

Requirements Engineering

The process of finding out, analyzing, documenting, and checking system services and constraints.

User Requirements

Statements in natural language plus diagrams of the services the system provides and its operational constraints; written for customers.

System Requirements

A structured document setting out detailed descriptions of the system's functions, services, and operational constraints; may be part of a contract.

Readers of User Requirements

Client managers, system end-users, client engineers, contractor managers, system architects.

Readers of System Requirements

System end-users, client engineers, system architects, software developers.

System Stakeholders

Any person or organization who is affected by the system in some way and has a legitimate interest; includes end users, system managers, system owners, external stakeholders.

Functional Requirements

Statements of services the system should provide, how it should react to inputs, and how it should behave in situations; may state what the system should NOT do.

Non-functional Requirements

Constraints on the services or functions offered by the system, such as timing constraints or development process constraints; often apply to the system as a whole.

Functional User Requirements

High-level statements of what the system should do (e.g., "A user shall be able to search the appointments lists for all clinics").

Functional System Requirements

Detailed descriptions of the system services (e.g., "The system shall generate each day, for each clinic, a list of patients expected to attend appointments").

Requirements Imprecision

Problems that arise when functional requirements are not precisely stated, leading to ambiguous interpretation by developers and users.

Requirements Completeness

Requirements should include descriptions of all facilities required.

Requirements Consistency

There should be no conflicts or contradictions in the descriptions of the system facilities.

Product Requirements

Non-functional requirements specifying that the delivered product must behave in a particular way (e.g., execution speed, reliability).

Organizational Requirements

Non-functional requirements that are a consequence of organizational policies and procedures (e.g., process standards used).

External Requirements

Non-functional requirements arising from factors external to the system and its development process (e.g., interoperability, legislative requirements).

Non-functional Requirement Types (top-level)

Product requirements, Organizational requirements, External requirements.

Efficiency Requirements

A category of product requirements, split into performance and space requirements.

Dependability Requirements

Non-functional product requirements concerned with reliability of the system.

Regulatory Requirements

External requirements arising from laws/regulations, split into legislative and safety/security requirements.

Speed (metric)

Measured by processed transactions/second, user/event response time, screen refresh time.

Reliability (metric)

Measured by mean time to failure, probability of unavailability, rate of failure occurrence, availability.

Portability (metric)

Measured by percentage of target-dependent statements, number of target systems.

Requirements Engineering Processes (generic activities)

Requirements elicitation, requirements analysis, requirements validation, requirements management.

Requirements Elicitation (aka)

Also called requirements elicitation or requirements discovery; involves technical staff working with customers/stakeholders.

Stages of Requirements Elicitation

Requirements discovery, requirements classification and organization, requirements prioritization and negotiation, requirements specification.

Requirements Discovery

The process of gathering information about the required and existing systems and distilling user and system requirements from this information.

Problems of Requirements Elicitation

Stakeholders don't know what they want, express requirements in their own terms, have conflicting requirements, organizational/political factors influence requirements, requirements change during analysis.

Interviewing (types)

Closed interviews (pre-determined list of questions) and open interviews (various issues explored with stakeholders).

Problems with Interviews

Application specialists use language hard to understand; interviews are not good for understanding domain requirements (terminology, unspoken familiar knowledge).

Ethnography

A social scientist spends considerable time observing and analyzing how people actually work; people don't have to explain/articulate their work.

Scope of Ethnography

Effective for understanding existing processes but cannot identify new features that should be added to a system.

Focused Ethnography

Combines ethnography with prototyping; prototype development results in unanswered questions which focus the ethnographic analysis.

Scenarios

A structured form of user story describing a real-life example of how a system can be used for a particular task.

Scenario Contents

Starting situation, normal flow of events, what can go wrong, concurrent activities, state when scenario finishes.

Use Cases

A requirements discovery technique first introduced in the Objectory method (Jacobson et al., 1993); now part of UML; identifies actors and the type of interaction.

Requirements Specification (definition)

The process of writing down the user and system requirements in a requirements document.

Natural Language Specification

Requirements written as natural language sentences supplemented by diagrams and tables; expressive, intuitive, universal.

Problems with Natural Language

Lack of clarity, requirements confusion (functional/non-functional mixed up), requirements amalgamation (several requirements expressed together).

Structured Specifications

An approach to writing requirements where the writer's freedom is limited and requirements are written in a standard way; good for embedded control systems, too rigid for business systems.

Form-based Specification (contents)

Definition of function/entity, inputs, outputs, needed information, action to be taken, pre/post conditions, side effects.

Tabular Specification

Used to supplement natural language; useful for defining alternative courses of action (e.g., insulin pump dose calculation table).

Guidelines for Writing Requirements

Use a standard format, use language consistently (shall = mandatory, should = desirable), highlight key parts, avoid jargon, include rationale.

Requirements and Design Relationship

In principle requirements state WHAT the system should do and design states HOW; in practice they are inseparable.

Software Requirements Document (purpose)

The official statement of what is required of the system developers; includes user and system requirements; NOT a design document.

Requirements Validation (definition)

Process of checking that requirements actually define the system that the customer really wants.

Requirements Checks

Validity, consistency, completeness, realism, verifiability.

Requirements Validation Techniques

Requirements reviews, prototyping, test-case generation.

Requirements Review

Systematic manual analysis of requirements, involving both client and contractor staff, may be formal or informal.

Review Checks

Verifiability, comprehensibility, traceability, adaptability.

Requirements Management (definition)

The process of managing changing requirements during the requirements engineering process and system development.

Why Requirements Change

Business/technical environment changes, new hardware, new legislation, differing needs of customers vs end-users, diverse stakeholder priorities.

Requirements Management Planning Decisions

Requirements identification, change management process, traceability policies, tool support.

Requirements Change Management Stages

Problem analysis and change specification, change analysis and costing, change implementation.