Requirements Engineering Overview

Requirements Engineering

• Requirements are descriptions of services a system should provide and its operational constraints.
• Requirements can range from high-level, abstract statements to detailed functional specifications.
• Requirements may serve a dual function: forming the basis for a bid or the contract itself.
• Requirements elicitation is a process for discovering and understanding the needs of users
• Requirements specification defines system functions, services, and operational constraints in detail.
• User requirements are statements in natural language and diagrams describing system services and constraints.
• System requirements are more detailed descriptions of system functions, written for the implementers.
• Requirements should be complete, consistent, and verifiable.
• Stakeholders are any affected individuals or organizations who have an interest in the system. These could include end-users, system managers, system owners, and external stakeholders.
• Agile methods often use incremental requirements engineering, expressing requirements as "user stories" instead of detailed specifications.

Types of Requirements

• User Requirements: Statements, described in natural language, with diagrams detailing the system's services and operational constraints written for customers.
• System Requirements: Detailed descriptions of system functions, operational constraints, and services.

User and System Requirements Example

• Mentcare System Example:
  • User Requirement: Generate monthly management reports of drug costs per clinic.
  • System Requirement: Generate reports on the last business day of each month, showing details of all drugs and prescribing clinics, including individual drugs, total prescriptions, doses, and total costs, for authorized users only. Separate reports by dose unit if applicable.

Stakeholders

• Stakeholders involved in Mentcare: patients, doctors, nurses, receptionists, IT staff, medical ethic managers, healthcare managers, and medical record staff.

Agile Methods and Requirements

• Agile methods often reduce the importance of detailed requirements documents, as requirements change quickly without a detailed document.
• User stories may be used for requirements.
• Agile methods are often more practical for business systems, but can be problematic for critical systems with pre-delivery analysis needs or for systems built by multiple teams.

Functional and Non-Functional Requirements

• Functional Requirements: Describe the services and behaviors of the system (how it should respond to particular inputs and actions in specific situations).
• Non-Functional Requirements: Constraints on the services or functions. Examples include timing constraints, standards, reliability, and availability, usually applicable to the system as a whole and not specific features.

Requirements Imprecision

• Ambiguous requirements can be interpreted in different ways by developers and users leading to problems and delays/higher costs.

Requirements Completeness and Consistency

• Requirements should be complete and consistent.
• Requirements should include all requested functions and features.
• There should be no conflicts or contradictions in the descriptions of the system facilities.
• While ideal, it's practically impossible to create perfect requirements for highly complex systems.

Non-Functional Requirements Implementation

• Non-functional requirements can impact system architecture as a whole, not just individual parts.
• A single non-functional requirement may lead to a series of related functional requirements, for example a security requirement might lead to system access restrictions.

Non-Functional Classifications

• Product Requirements: Constraints on the system's runtime behavior (e.g., execution speed, memory use, and reliability).
• Organizational Requirements: Consequence of organizational policies and procedures (e.g., coding standards and development process).
• External Requirements: From external factors (e.g., interoperability, and regulatory requirements).

Types of Non-Functional Requirements

• These can be grouped according to various characteristics such as performance, security, reliability, usability, and more.

Examples of Non-Functional Requirements (Mentcare System)

• Product Requirement: The system shall be available to all clinics during normal working hours.
• Organizational Requirement: Users of the system must authenticate using their identity card.
• External Requirement: The system must comply with privacy regulations.

Requirements Discovery

• This is the process of gathering information to develop user and system requirements from existing systems and information.
• Techniques include interviews, observation (ethnography), and user stories.

Interviewing

• Interviewing is a common process using formal or informal questioning techniques.
• Types include open-ended and closed questions.
• Effective interviewing requires open-mindedness and an understanding of stakeholder needs to discover various issues and potential challenges.

Ethnography

• Observation-based process for understanding operational procedures to discover support requirements, which reflects how people actually work, as opposed to hypothetical work processes.
• Ethnography is good for understanding existing processes and procedures, but may not suggest new features that could be added to the system.

Stories and Scenarios

• Stories and scenarios describe how a system can be used and are detailed descriptions of specific use cases.
• Scenarios describe practical situations that stakeholders can understand and which are useful for eliciting more requirements.

Requirements Specification

• The process of writing down user and system requirements in a document that's understandable by customers and users and is the foundation for all future developments.

Ways of Writing System Requirements:

• This involves natural language, supplemented by diagrams, tables, and specifications. These help clarify and ensure completeness of user/system needs.

Requirements Validation

• This process validates if the system's requirements truly meet the customer's needs, and checks for inconsistencies.
• Errors identified early during validation are crucial since fixing them late in development can be costly and time-consuming.

Requirements Checking

• Validity: Does the system correctly perform its tasks and support the users?
• Consistency: No internal conflicts or inconsistencies in the requirements.
• Completeness: All necessary features and functionalities are included.
• Realism: Can the system be built with available resources?
• Verifiability: Can the system's features be tested?

Requirements Reviews

• Regular reviews should involve both clients and developers.
• Reviews may be formal or informal, and good communication can prevent problems or issues from occurring at a later point.

Requirements Change

• Requirements change as the business and technical environment evolves.
• Changes may be driven by new hardware, interface changes, business priorities, new legislations, organizational, or budgetary constraints.
• Effective management of these changes is crucial in large/complex projects.

Requirements Management

• The process of managing changing requirements during development and after deployment.
• This involves tracking changes, assessing their impact, managing proposals, and ensuring all changes are documented effectively.