Non-functional Requirements in Systems

Non-functional Requirements

• Classifications include product, organizational, and external requirements.
• Product Requirements: Define product behaviors like execution speed and reliability.
• Organizational Requirements: Result from organizational policies, including process standards and implementation guidelines.
• External Requirements: Arise from external factors such as legislative and interoperability requirements.

Mentcare System Examples

• Product Requirement: The Mentcare system shall be available Mon–Fri, 0830–17.30, with downtime not exceeding five seconds daily.
• Organizational Requirement: Users must authenticate with their health authority identity card.
• External Requirement: Patient privacy provisions must conform to regulations, e.g., HStan-03-2006-priv.

Goals and Requirements

• Non-functional requirements can be challenging to specify precisely; vague requirements complicate verification.
• Goals express general user intentions, such as ease of use.
• Verifiable non-functional requirements have measurable attributes that can be objectively tested.

Usability Requirements

• The system should minimize user errors and be straightforward for medical staff.
• After four hours of training, staff should operate the system while averaging no more than two errors per hour.

Requirements Engineering Processes

• Core activities include requirements elicitation, analysis, validation, and management.
• Requirements engineering is iterative, with processes interweaving as development progresses.

Requirements Elicitation and Analysis

• Involves collaboration between technical staff and various stakeholders to uncover application domain needs and constraints.
• Stakeholders encompass end-users, managers, engineers, and experts in the relevant field.

Problems of Requirements Elicitation

• Stakeholders may be unaware of their true needs or express requirements in non-standard terms.
• Conflicts may arise between different stakeholders, and ongoing changes can disrupt analysis.

Process Activities

• Requirements Discovery: Interacting with stakeholders to identify needs.
• Classification and Organization: Grouping related requirements into coherent clusters.
• Prioritization and Negotiation: Resolving conflicts and establishing requirement importance.
• Requirements Specification: Documenting requirements for future iterations.

Interviews in Requirements Gathering

• Utilize both closed and open-ended questions during interviews for comprehensive insights.
• Effective interviewing requires open-mindedness and willingness to listen without bias.
• Interviewers should guide discussions by prompting with proposals or prototypes.

Challenges with Interviews

• Technical jargon from subject matter experts may obscure understanding.
• Interviews may inadequately capture domain-specific requirements due to unfamiliarity with terminology.

Stories and Scenarios

• Scenarios provide practical, relatable examples of system usage for stakeholder engagement.
• Include elements such as starting conditions, workflow, potential issues, and completion state.

Requirements and Design Relationship

• Requirements outline what the system should achieve; design details how these goals will be met.
• Requirements and design are interdependent due to system architecture, interoperability, and regulatory demands.

Natural Language Specification

• Requirements documentation typically utilizes natural language, supplemented by diagrams and tables for clarity.
• Natural language is accessible but may lack precision.

Guidelines for Writing Requirements

• Standardize format and consistent language use in requirements documentation.
• Use "shall" for mandatory and "should" for desirable requirements, highlighting key requirements for emphasis.

Problems with Natural Language

• Clarity suffers due to inherent imprecision and mixing of functional and non-functional specifications.
• Requirements can become amalgamated, obscuring distinct needs.

Structured Specifications

• Standardized frameworks limit the writer's flexibility, promoting clarity and precision for certain types of requirements.
• This approach may be too rigid for dynamic business system requirements.

Software Requirements Document

• Serves as the official outline for system developers, specifying user and system requirements but not design directives.
• Focus is on what the system must do rather than how it will accomplish these tasks.

Requirements Document Variability

• The content and detail of requirements documents vary by system type and development approach.
• Incrementally developed systems usually have less detailed requirement specifications, adhering to standards like IEEE guidelines.

This quiz focuses on understanding various non-functional requirements, such as product, organizational, and external requirements. It will explore the implications of each type and how they apply to system designs like the Mentcare system. Enhance your knowledge of how these requirements influence system behavior and compliance.