Software Requirements Engineering

• Software requirements are descriptions and specifications of a system

Requirements Engineering

• Requirements engineering is the process of establishing customer needs from a system and the conditions under which it operates and develops.
• Requirements are descriptions of system services and constraints generated during engineering.

What is a Requirement?

• A requirement can range from a high-level abstract statement of a service or system constraint to a detailed mathematical functional specification.
• Requirements may serve a dual function as the basis for a bid for a contract or the basis for the contract itself.

Types of Requirements

• User requirements are statements in natural language plus diagrams of the services the system provides and its operational constraints for customers.
• System requirements consist of a structured document setting out detailed descriptions of system services, written as a contract between client and contractor.
• Software specifications are detailed descriptions that serve as a basis for design or implementation, written for developers.

Definitions and Specifications

• Requirements definition involves software providing a way to represent and access external files from other tools.
• Requirements specification involves users being provided with facilities to define external file types.

Requirements Readers

• User requirements are for client managers, system end-users, client engineers, contractor managers, and system architects.
• System requirements are for system end-users, client engineers, system architects, and software developers.
• Software design specifications are for client engineers and system architects.

Functional and Non-Functional Requirements

• Functional requirements define services the system should provide, how to react to inputs, and behave in situations.
• Non-functional requirements are constraints on services/functions, such as timing, development process, and standards.
• Domain requirements come from the application domain, reflecting its characteristics.

Functional Requirements Details

• Functional requirements describe functionality or system services.
• They depend on software, users, and system type.
• User requirements are high-level, while system requirements describe services in detail.

Requirements Imprecision

• Problems arise when requirements are not precisely stated or are ambiguous.
• Consider user intention with special-purpose viewers for each document type, and developer interpretation using a text viewer.

Requirements Completeness and Consistency

• Requirements should be complete (include all facilities) and consistent (no conflicts).

Non-Functional Requirements Details

• Focus on defining system properties and constraints like reliability, response time, and storage.
• Constraints include I/O device capability and system representations.
• Process requirements may specify a CASE system, language, or development method.
• Non-functional requirements may be critical; if unmet, the system fails.

Non-Functional Classifications

• Product requirements specify product behavior (e.g., speed, reliability).
• Organizational requirements result from policies/procedures (e.g., standards, implementation).
• External requirements arise from outside factors (e.g., interoperability, legislative).

Goals and Requirements

• Non-functional requirements may be hard to state precisely and verify.
• Goals are general user intentions like ease of use.
• Verifiable requirements use objective measures.

Requirements Measures

• Speed is measured in transactions/second, User/Event response time, or screen refresh time.
• Size is measured in K Bytes or RAM chips.
• Ease of use is measured in training time or help frames.
• Reliability is measured in mean time to failure, unavailability probability, or failure rate.
• Robustness is measured in restart time, events causing failure percentage, or data corruption probability.
• Portability is measured in target-dependent statements percentage or target systems number.

Domain Requirements Details

• Domain requirements stem from the application domain and describe system characteristics.
• They may introduce new functional requirements, constraints, or specific computations.
• Dissatisfaction with domain requirements can make a system unworkable.

Database and Grid Requirements

• Database requirements include conceptual and detailed info.
• Grid requirements mix the needs for a grid, grid units and grid switching.

Guidelines for Writing Requirements

• Use a standard format consistently.
• Use consistent language.
• Use 'shall' for mandatory and 'should' for desirable requirements.
• Highlight key parts of the requirement.
• Avoid computer jargon.

Requirements and Design

• Requirements state what the system should do, design shows how.
• Requirements and design are inseparable, leading to system architecture to structure the requirements.

Specifications

• A limited form of natural language may be used to express requirements to remove ambiguity and flexibility whilst imposing uniformity.
• They are often supported using a forms-based approach.

Form Based Sepcifications

• Form-based specifications involve defining function/entity, inputs, outputs, other entities, pre/post conditions, and side effects.

Interface Specifications

• Most systems operate with other systems, making interfaces critical.
• It is important to define procedural interfaces, data structures exchanged, and data representations.

The Requirements Document

• The requirements document is the official statement of what is required of the system developers, not a design document.
• It specifies what the system should do rather than how it should do it.
• System customers specify and validate requirements.
• Managers use it to plan bids and development.
• System engineers use it to understand the system.
• Test engineers use it for validation tests.
• Maintenance engineers use it to understand and relate system parts.

Requirements Document Details

• Requirements documents must specify external system behavior, implementation constraints, be easy to change, serve as a maintenance tool, record lifecycle forethought, and characterize unexpected responses.
• Has an introduction, glossary, architecture, specification, system model and evolution.