Non-Functional Requirements in Systems Analysis

Interviews structured with a predetermined set of questions, providing specific answers to questions to elicit specific information.

Interviews exploring various issues with stakeholders, allowing for more flexibility and in-depth discussion.

Combining closed and open interview techniques, avoiding pre-conceived notions, and actively encouraging stakeholder input.

Understanding stakeholder's system interactions and overall workflow.

Difficulty in understanding specialized domain language and in extracting implicit or deeply ingrained requirements.

Observational technique to understand real-world operational processes, leading to better support requirement derivation.

Helps unearth implicit system requirements that accurately reflect real work processes and requirements stemming from cooperation, awareness of other people's actions, and work context.

Characteristics of a system, rather than specific functions. Examples include speed, size, reliability, and ease of use.

A general intention or desired outcome for a system, often imprecise and difficult to verify.

Non-functional requirements that can be measured and tested objectively.

Non-functional requirements expressed using specific numerical values and metrics.

The rate at which a system processes transactions or responds to user events.

The physical or storage capacity of the system.

How user-friendly the system is. Measured by factors such as training time or error rate.

The consistency and dependability of the system (measured through metrics like mean time to failure).

Ability of the system to handle unexpected input or errors without crashing (measured by rates of failure, corruption).

How easily the system can be transferred to different environments or platforms.

Observational study to understand real-world processes impacting system use.

Creating a preliminary version of a system. Helps identify missing requirements.

Real-life examples of system use, reflecting how users interact with it.

Structured descriptions of system use cases.

Process to identify what a system needs to do.

Changes in behavior resulting from awareness of other users' actions.

A table used to define requirements, especially alternative courses of action in a system. It supplements natural language descriptions, particularly helpful for systems with multiple options.

A system for calculating insulin dosage based on the rate of change in blood sugar levels. It uses a table to determine dosage based on different conditions.

Visual and textual descriptions of interactions between users and a system. They identify actors and the nature of the interaction.

Unified Modeling Language. A standard for creating technical diagrams to describe software and systems.

Requirements describe what a system should do, while design describes how it does it.

Requirements and design are intertwined; design can influence requirements, and vice-versa.

The overall structure and organization of a system. It can structure requirements.

Systems interacting with each other. Interactions can influence design requirements of new systems.

System characteristics (e.g., speed, reliability, size).

Using natural language (sentences, etc.) and diagrams/tables to define system requirements.

Ambiguity, lack of clarity, and mixing of functional and non-functional requirements.

Ensuring requirements are unambiguous; precise language often hinders readability.

Mixing functional and non-functional requirements in descriptions.

Combining multiple requirements into a single statement, making them harder to understand or test.

A prescribed format for writing all requirements for consistency.

Using terms and phrases consistently within the requirements document.

Different systems and development approaches require varying levels of detail in the requirements document to balance user communication, developer understanding, and future system evolution.

Essential for critical systems (safety/security) and outsourced projects due to the need for precise specifications.

Allows for less detailed requirements up front as ambiguities can be addressed during development.

Consist of Preface, Introduction, Glossary, User Requirements, and Non-Functional Requirements sections, following a standardized format.

Defines the document's readership, version history, and the rationale for updates.

Describes system need, functions, interaction with other systems, and alignment with business objectives.

Defines technical terms used in the document to avoid misunderstandings.

Describes services provided to users and non-functional system characteristics.