INFOTECH 33
Introduction to Requirements and Requirements Engineering
Requirements Definition: Descriptions of what a system should do, signifying the services it provides and the constraints on its operation. They reflect customer needs for systems serving specific purposes, such as controlling devices, placing orders, or finding information.
System Requirements: Detailed descriptions of system services and constraints generated during the requirements engineering process.
Requirements Engineering (RE):
The process of finding out, analyzing, documenting, and checking system services and constraints.
The process of establishing the services a customer requires from a system and the constraints under which it operates and is developed.
Objectives of Requirements Engineering
Understand the concepts of user and system requirements and the necessity of writing them in different ways.
Differentiate between functional and non-functional software requirements.
Understand the organization and structure of a software requirements document.
Identify principal requirements engineering activities: elicitation, analysis, and validation, including their interrelationships.
Recognize the necessity of requirements management to support other engineering activities.
Types of Requirements
User Requirements:
High-level statements written in natural language supplemented by diagrams.
Describe the services the system provides and its operational constraints.
Primary target audience: Customers.
System Requirements:
A structured document providing detailed descriptions of the system's functions, services, and operational constraints.
Defines exactly what should be implemented.
Often serves as part of the legal contract between the client and the contractor.
Example: MHC-PMS (Mental Healthcare Patient Management System)
User Requirement Definition: The MHC-PMS shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month.
System Requirements Specification:
1.1 On the last working day of each month, a summary of the drugs prescribed, their cost, and the prescribing clinics shall be generated.
1.2 The system shall automatically generate the report for printing after on the last working day of the month.
1.3 A report shall be created for each clinic and shall list the individual drug names, the total number of prescriptions, the number of doses prescribed, and the total cost of the prescribed drugs.
1.4 If drugs are available in different dose units (e.g., , ) separate reports shall be created for each dose unit.
1.5 Access to all cost reports shall be restricted to authorized users listed on a management access control list.
Readers of Requirements Specifications
User Requirements Readers:
Client managers.
System end-users.
Client engineers.
Contractor managers.
System architects.
Note: These readers are typically not concerned with implementation details but rather how the system supports business processes.
System Requirements Readers:
System end-users.
Client engineers.
System architects.
Software developers.
Note: These readers require precise technical detail for implementation and management.
System Stakeholders
A stakeholder is any person or organization affected by the system with a legitimate interest in it.
Types of Stakeholders:
End users.
System managers.
System owners.
External stakeholders (e.g., regulators).
MHC-PMS Stakeholder Examples:
Patients (data subjects).
Doctors (responsible for assessment and treatment).
Nurses (coordinate consultations and administer treatment).
Medical receptionists (manage appointments).
IT staff (installation and maintenance).
Medical ethics manager (ensuring adherence to ethical guidelines).
Healthcare managers (utilize management information).
Medical records staff (ensure data preservation and procedure implementation).
Functional and Non-functional Requirements
Functional Requirements:
Statements of services the system should provide.
Define how the system reacts to particular inputs and behaves in specific situations.
May explicitly state what the system should not do.
User-level functional requirements are high-level; system-level functional requirements are detailed.
Example (User): A user shall be able to search the appointments lists for all clinics.
Example (System): The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day.
Non-functional Requirements:
Constraints on services or functions, such as timing, development process standards, or storage.
Apply to the system as a whole rather than specific features.
If not met, the system may become useless, making these potentially more critical than functional requirements.
Non-functional Requirement Classifications
Product Requirements: Specify delivered product behavior (e.g., execution speed, reliability).
Example: The MHC-PMS shall be available to all clinics during normal working hours (Mon–Fri, –). Downtime within these hours shall not exceed seconds in any one day.
Organizational Requirements: Derived from organizational policies and procedures (e.g., process standards, implementation requirements).
Example: Users of the MHC-PMS shall authenticate themselves using their health authority identity card.
External Requirements: Arise from factors external to the system and development process (e.g., interoperability, legislative requirements).
Example: The system shall implement patient privacy provisions as set out in HStan-03-2006-priv.
Metrics for Specifying Non-functional Requirements
Speed:
User/event response time.
Screen refresh time.
Size:
Number of ROM chips.
Ease of Use:
Training time.
Number of help frames.
Reliability:
Mean time to failure.
Probability of unavailability.
Rate of failure occurrence.
Availability.
Robustness:
Time to restart after failure.
Percentage of events causing failure.
Probability of data corruption on failure.
Portability:
Percentage of target dependent statements.
Number of target systems.
Requirements Imprecision, Completeness, and Consistency
Imprecision: Ambiguous requirements lead to different interpretations. For example, a "search" requirement might be interpreted by a user as a global search across all clinics, while a developer might interpret it as a search within a specific clinic after selection.
Completeness: Requirements should include descriptions of all required facilities.
Consistency: Requirements should have no conflicts or contradictions.
Practicality: In complex environments, achieving 100% completeness and consistency is essentially impossible.
Requirements Engineering Processes
The RE process is iterative and interleaved, varying by application domain and organization.
Common Generic Activities:
Requirements Elicitation: Finding out what is required.
Requirements Analysis: Clarifying and deepening understanding of requirements.
Requirements Validation: Checking if requirements meet customer needs.
Requirements Management: Handling changes to requirements.
Spiral View: RE is often viewed as a spiral where activities are repeated and refined over multiple cycles.
Requirements Elicitation and Analysis
Also referred to as requirements discovery.
Involves technical staff working with stakeholders (end-users, managers, domain experts, trade unions, etc.) to understand the application domain and system constraints.
Stages of Elicitation:
Requirements Discovery: Interacting with stakeholders to gather information and distill requirements.
Requirements Classification and Organization: Grouping related requirements into coherent clusters.
Prioritization and Negotiation: Resolving conflicts and ordering requirements by importance.
Requirements Specification: Documenting requirements for the next iterative cycle.
Problems in Elicitation:
Stakeholders may not know what they want.
Stakeholders use domain-specific terminology difficult for engineers to grasp.
Conflicting requirements from different stakeholders.
Organizational and political influences.
Changing requirements during analysis due to new stakeholders or environment shifts.
Elicitation Techniques
Interviewing:
Closed Interviews: Based on pre-determined questions.
Open Interviews: Exploratory discussions without a fixed agenda.
Effective interviews require open-mindedness and prompts (springboard questions or prototypes).
Limitation: Specialists may find it hard to articulate "familiar" domain knowledge or use complex jargon.
Ethnography:
A social scientist observes actual work practices.
Effective for discovering requirements from actual work patterns and cooperation rather than formal process definitions.
Limitation: Cannot identify new features being added, only existing practices.
Focused Ethnography: Combines observation with prototyping to answer specific questions.
Stories and Scenarios:
Real-life examples of system use.
Scenario Components:
Initial assumption/starting situation.
Normal flow of events.
What can go wrong (exceptions).
Concurrent activities.
State of the system upon completion.
Detailed Scenario Example: MHC-PMS Medical History Collection
Initial Assumption: The patient has seen a medical receptionist who created a record with personal info (name, address, age, etc.). A nurse is logged on and collecting medical history.
Normal Flow:
Nurse searches for patient by family name. If duplicates exist, use given name and date of birth.
Nurse chooses "add medical history" menu option.
Nurse enters consultation info (free text), medical conditions (menu selection), current medication (menu selection), allergies (free text), and home life (form).
What Can Go Wrong:
Record not found: Nurse creates a new record.
Conditions/Medications not in menu: Nurse selects "other" and enters free text.
Patient refuses/cannot provide info: Nurse records this in free text. System prints an exclusion form stating treatment may be delayed. Form is signed and given to the patient.
Other Activities: Records may be consulted but not edited by other staff during input.
System State on Completion: User remains logged on. Patient record and medical history are saved in the database. System log records start/end time and staff involved.
Use Cases
Introduced in the Objectory method () and fundamental to the Unified Modeling Language (UML).
Identify the actors involved and the type of interaction.
A set of use cases describes all possible system interactions.
Often supplemented by sequence diagrams to show processing detail.
Requirements Specification Notations
Natural Language: Numbered sentences. Expressive and intuitive but can lack clarity and lead to requirement amalgamation (mixing multiple requirements in one sentence).
Structured Natural Language: Uses standard forms/templates to limit the writer's freedom and ensure consistency.
Design Description Languages (DDL): Programming-like languages with abstract features for operational models; now rarely used except for interfaces.
Graphical Notations: UML use case and sequence diagrams supplemented by text.
Mathematical Specifications: Based on finite-state machines or sets. Unambiguous but difficult for customers to understand.
Writing Requirements Guidelines
Use a standard format for all requirements.
Use language consistently: "shall" for mandatory, "should" for desirable.
Use text highlighting for key parts.
Avoid computer jargon.
Include a rationale (explanation) for why each requirement is necessary.
Example: Insulin Pump Software System Requirements
Requirement 3.2: The system shall measure the blood sugar and deliver insulin, if required, every minutes. (Rationale: Changes in blood sugar are slow; frequent measurement is unnecessary, but too infrequent leads to high sugar levels.)
Requirement 3.6: The system shall run a self-test routine every minute with the conditions and actions defined in Table 1. (Rationale: Routine discovery of hardware/software problems alerts the user if normal operation is impossible.)
Tabular Specification of Computation:
Sugar level falling (r2 < r1):
Sugar level stable :
Sugar level increasing and rate of increase decreasing ((r2 - r1) < (r1 - r0)):
Sugar level increasing and rate of increase stable or increasing : . If rounded result is , .
Software Requirements Document Structure
The official statement of requirements; NOT a design document. It focus on "what" not "how."
Standard Chapters:
Preface: Readership, version history, and rationale for changes.
Introduction: Need for system, functions, and business objectives.
Glossary: Definition of technical terms.
User Requirements Definition: Services and non-functional requirements in natural language/diagrams.
System Architecture: High-level overview of distribution of functions.
System Requirements Specification: Detailed functional and non-functional requirements.
System Models: Graphical models (object, data-flow, etc.).
System Evolution: Fundamental assumptions and anticipated future changes.
Appendices: Detailed info like hardware/database configurations.
Index: Alphabetic, diagram, or function indexes.
Requirements Validation
The process of checking that requirements define the system the customer truly wants.
Validation is critical because fixing a requirement error after delivery can cost up to times more than fixing an implementation error.
Validation Checks:
Validity: Does it support the customer's needs?
Consistency: Are there conflicts?
Completeness: Are all required functions included?
Realism: Can it be built with the given budget and tech?
Verifiability: Can it be tested?
Techniques:
Requirements Reviews: Systematic manual analysis.
Prototyping: Using an executable model.
Test-case Generation: Developing tests to check testability.
Requirements Evolution and Management
Requirements inevitably change due to hardware updates, new legislative regulations, changing business priorities, and shifting user needs after initial delivery.
Requirements Management: The process of managing changing requirements during RE and system development.
Planning Decisions:
Requirements Identification: Unique IDs for cross-referencing.
Change Management Process: Activities to assess change impact and cost.
Traceability Policies: Defining relationships between requirements and design.
Tool Support: Using spreadsheets or specialized database systems.
Change Management Process Stages:
Problem Analysis and Change Specification: Checking if the change is valid.
Change Analysis and Costing: Assessing the effect using traceability information.
Change Implementation: Modifying documents, design, and implementation.