Requirements Engineering Overview

Requirements Engineering

• Functional and non-functional requirements are crucial aspects
• Requirements elicitation, specification, validation, and change are key processes in requirements engineering
• Requirements are descriptions of services and constraints on a system's operation and implementation
• Requirements range from high-level statements of service or system constraints to detailed mathematical specifications
• Requirements can serve dual roles: as a basis for contract bids (open to interpretation) or contracts themselves (detailed)
• User requirements are natural language statements and diagrams of system services and operational constraints, written for customers
• System requirements are structured documents with detailed descriptions of system functions, services, and operational constraints, intended as a client and contractor contact.

Types of Requirements

• User requirements are written in natural language and diagrams to explain system functionalities and operational constraints
• System requirements are detailed documents specifying how the system should function, including its operational aspects.

User and System Requirements Definition

• Example of user requirement: The system should generate monthly reports on drug costs prescribed per clinic.
• An example of a system requirement: Provide monthly summaries of drugs, cost and clinics (by 17:30).
• Examples of requirements: Specific drug names, total prescriptions, dose numbers, and total costs for each clinic

Readers of Requirements Specifications

• Readers of user requirements include client managers, system end-users, client engineers, contractors and system architects
• Readers of system requirements include system end-users, client engineers, system architects, and software developers

System Stakeholders

• Stakeholders are any person or organization affected by a system, having a legitimate interest.
• Stakeholder types include end-users, system managers, system owners, and external stakeholders
• Examples of stakeholders in a healthcare system: patients, doctors, nurses, medical receptionists, IT staff, medical ethics managers, health care managers, and medical records staff

Agile Methods and Requirements

• Agile methods often argue that detailed system requirements are a waste of time due to rapid changes in requirements
• Agile methods prefer incremental requirements expressed as "user stories." This approach is practical for business systems but may be troublesome for systems needing pre-delivery analysis (e.g. critical systems) or developed by multiple teams

Functional and Non-functional Requirements

• Functional requirements define the services a system should provide/how it reacts to inputs, how it behaves in different situations, and what it should not do
• Non-functional requirements specify constraints on services/functions, including timing constraints, development process constraints, and standards. These can be critical for functionality

Functional Requirements

• Describe system functionality or services in detail and state requirements with high-level statements
• Examples: User should be able to search appointment lists, system generates a list of patients for each clinic, staff identification by 8-digit employee number

Requirements Imprecision

• Ambiguous requirements may be interpreted differently by users and developers
• Precision in requirements is crucial; its lack can lead to disputes, delays, and increased costs
• An example is the word "search" in a requirement—it can mean different things across varying clinics

Requirements Completeness and Consistency

• Requirements should be complete and consistent
• Complete requirements include all necessary components/features
• Consistent requirements have no conflicts or contradictions

Non-Functional Requirements Implementation

• Non-functional requirements influence system architecture, rather than individual components
• Examples: performance requirements may necessitate system components to minimize communication (between components), a security requirement can create related functional requirements

Non-functional Classifications

• Product requirements describe constraints in runtime behavior
• Organizational requirements follow from organizational policies
• External requirements arise from external factors, for example interoperability or legislative requirements.

Types of Non-Functional Requirements

• A diagram shows a hierarchical breakdown of different categories of non-functional requirements

Examples of Non-Functional Requirements in Mentcare

• Product requirement: availability of system within working hours (08:30-17:30)
• Organizational requirement: user authentication using health IDs
• External requirement: compliance with privacy regulations (e.g., HStan-03-2006-priv)

Goals and Requirements

• Non-functional requirements can be hard to state precisely and verify
• Stakeholders often propose goals, such as ease of use or minimizing errors
• Requirements should be presented as verifiable quantifiable facts, for instance, "medical staff should accomplish all functions after four hours of training and not exceed 2 errors per hour"

Metrics for Specifying Nonfunctional Requirements

• A list of properties and their associated measures required for non- functional requirements—in terms of speed, size, ease of use, reliability, robustness, and portability

Requirements Engineering Processes

• Requirements engineering processes vary widely based on application scope, involved parties, and organization design but share common generic activities
• Activities include elicitation, analysis, validation, and management
• RE is an iterative process, meaning these processes often overlap

Requirements Elicitation and Analysis

• Elicitation and analysis (or discovery) aims to understand stakeholder work and to identify new ways a system can support their work.
• May involve end-users, managers, maintainance engineers, domain experts, trade unions, etc. (called stakeholders)
• Stakeholders offer insights into application domains, services, operational constraints (including system performance and hardware constraints), and other systems.

Problems with Requirements Elicitation

• Potential problems: Stakeholders might not know their true needs, conflicting requirements, changing requirements during analysis, emerging stakeholders, and changing business circumstances.

Process Activities

• Requirements discovery: interaction with stakeholders, also identifying domain requirements, followed by classifying requirements and organizing them into clusters.
• Prioritization and negotiation: Prioritize and resolve conflicting requirements.
• Requirements specification: documenting final requirements and inputting into the next spiral iteration.

Requirements Discovery

• Gathering information regarding required/existing systems and distilling user/system requirements from this information
• Interaction is needed across stakeholders (from managers to regulators)
• Discovery methodologies involve interviewing and ethnography

Interviewing

• Used in both formal and informal ways with stakeholders.
• Interview types include closed (pre-determined question lists/open (open-ended explorations of issues)).
• Effective interviewing requires mixed question types, openness, and good listening to stakeholders.
• Common problems include overly technical language and issues with articulating known domain requirements

Ethnography

• An observational technique to understand operational processes and derive supporting requirements for processes.
• Helps identify implicit system requirements reflecting how people work, and requirements derived from work cooperation and awareness of other people's work (and awareness).

Stories and Scenarios

• Scenarios/user stories are real-life illustrations of system use
• Stories describe how a system is used for specific tasks, allowing stakeholders to relate to practical situations and comment on the story.
• Stories can be used in interviews to elicit further requirements details and scenarios describe specific actions, conditions, interactions, and consequences.

Photo Sharing in the Classroom (iLearn) Story

• This is a use-case example highlighting how a photo-sharing system enables pupils' gathering and sharing of stories about the fishing industry in a Scottish village.

Scenarios

• Structure of user story for use cases to describe the big picture
• Scenarios can detail specific use cases, including the beginning, the normal action sequence, what can go wrong, other concurrent activities, and the end state

Uploading Photos (iLearn)- Scenario

• Assumptions: User uploads digital photos, logged into a photo sharing platform (KidsTakePics), and has access to the required system.
• Normal conditions show the steps for selecting images, naming, and storing photos and provide automatic notification for moderation requirements.
• Problems/errors are addressed if a selected moderator doesn't exist, when users upload photos with similar names, or additional actions/activities involving uploading approvals.

Scenario for Collecting Medical History in MentCare

• Assumptions: there is a patient record, user is a nurse.
• Normal conditions show searching patients, adding medical histories, and following prompts to enter details.
• Problems/errors addressed such as missing patient records, improper input, or unwillingness of patient to provide information

The Software Requirements Document

• The official document that defines the system's requirements for developers
• Should contain: definition of user requirements and specification of system requirements
• Is not a design document and aims to clarify "what" the system needs to do, rather than "how" it should do it

Users of a Requirements Document

• The users of the requirements document include system customers, managers, and system engineers; each user has different needs when interacting with the requirements document

Requirements Document Variability

• The complexity in communicating and specifying requirements is balanced by user and customer requirements, which are often different from each other in focus.
• Level of detail depends on the nature of the system.
• Outsourcing projects frequently rely on a highly detailed document

The Structure of a Requirements Document (Based on IEEE Standard)

• The structure covers various aspects of a requirement document: preface, introduction, glossary, user requirements, system architecture description, system evolution, and appendices.

Requirements Validation

• This aspect of requirements engineering aims to show that the user requirements correctly reflect the customers needs.
• Overlaps with analysis, as it's about problems in the requirements and requires validation at crucial times.

Validation checks include validity, consistency, completeness, realism, and verifiability for accurate and detailed requirements.

Requirements Validation Techniques

• Requirements reviews use systematic analysis techniques, also prototyping provides an executable system representation to check requirements, and test-case generation aims to ensure requirements are testable

Requirements Reviews

• Regular reviews are essential during requirement definition
• This includes reviews done by clients, contractors, developers, customers, and users. Useful for early problem identification and resolution, both formally (using written documents) and informally

Review Checks

• Verifiability: are the requirements testable?
• Comprehensibility: are the requirements understandable?
• Traceability: is the origin of requirements clear?
• Adaptability: can requirements change with minimal impact on other areas?

Requirements Change

• Business and technical environments change in multiple ways and impact systems after implementation.
• Users often have different needs and conflicting requirements.
• System needs adaptation and frequent changes

Requirements Evolution

• Requirements evolving over time needs to be anticipated in system development
• The initial understanding of a problem changes over time, leading to changes in requirements

Requirements Management

• Managing evolving and changing user requirements is part of requirements engineering
• Tracking individual requirements and their relationships is crucial to assess the impact of changes, and establishing processes/procedures for managing future changes

Requirements Management Planning

• Determining the level of requirement management detail is needed
• Establishing criteria of identification, change management processes, and traceability policies
• Specifying how requirements are linked within the system and how changes affect each other

Requirements Change Management

• Includes stages of analyzing, specifying, and implementing change
• Traceability/general system knowledge/cost analysis are used.
• System documents and design are modified, aiming for smooth implementation.