Requirements Engineering Quiz

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.

Test your knowledge on non-functional requirements in software engineering. Explore various classifications, including product, organizational, and external requirements. This quiz will help you understand how these requirements impact software development.