Requirements engineering

• Requirements for a system are descriptions of the services it should provide and the constraints on its
operation.
• They reflect the needs of customers for a system serving a specific purpose, such as controlling a device,
placing an order, or finding information
• Requirements engineering is the process of finding out, analyzing, documenting, and checking the
services and constraints a system should fulfill.
• It involves a systematic approach to understanding and specifying what the system should do.

1. Problem in Requirements Engineering:**

• - Some issues in the requirements engineering process arise due to a lack of clear separation between
different levels of requirement descriptions.

2.Distinction between User and System Requirements:**

- The term 'user requirements' refers to high-level, abstract statements about the services the system
should provide to users and the constraints it must operate under.
- 'System requirements' are more detailed descriptions of the software system's functions, services, and
operational constraints.

3. **Characteristics of User and System Requirements:**

• - User requirements are typically expressed in natural language along with diagrams.
• - System requirements, also known as a functional specification, provide precise details about what the
system should implement and may form part of the contract between the system buyer and software
developers.

4. **Communication and Documentation:**

- Different levels of requirements serve distinct communication purposes for various readers.
- The system requirements document communicates detailed information about the software system.

5. **Example Illustration - Mental Health Care Patient Management System (MHC-PMS):**

- An example from a mental health care patient management system demonstrates how a user
requirement can be expanded into several specific system requirements.
• - The user requirement is general, while the system requirements offer specific details about the
services and functions to be implemented.
Functional and non-functional requirements
1. Functional requirements These are statements of services the system should provide, how the system should
react to particular inputs, and how the system should behave in particular situations. In some cases, the
functional require- ments may also explicitly state what the system should not do.

2. Non-functional requirements These are constraints on the services or functions offered by the system. They
include timing constraints, constraints on the devel- opment process, and constraints imposed by standards.
Non-functional require- ments often apply to the system as a whole, rather than individual system features or
services.

Functional requirements

1. Functional Requirements Overview:

- Functional requirements describe what the system should do and depend on the type of software, expected
users, and organizational approaches to requirements.

2. Abstraction in User Requirements:

- User requirements express functional requirements in an abstract way understandable by system users.
- Specific functional system requirements provide detailed information about system functions, inputs,
outputs, exceptions, etc.

3. Variability in Detail:
- Functional system requirements range from general statements to specific, detailed requirements reflecting
local practices or existing organizational systems.

4. Examples of Functional Requirements:

- Examples for a mental health care patient management system (MHC-PMS) include searching appointments,
generating daily patient lists, and unique staff identification.

5. Imprecision Challenges:
- Imprecision in requirements specifications often leads to software engineering problems.
- Ambiguous requirements may be interpreted differently by system developers, leading to misunderstandings
with customers and necessitating system changes.

6. Example Illustration and Interpretation Issues:

- Example: "A user shall be able to search the appointments lists for all clinics."
- Interpretation issues may arise; for instance, the meaning of "search" might differ between the medical staff's
expectation and the system developers' implementation.

7. Completeness and Consistency Challenges:

- The ideal functional requirements specification should be complete and consistent.
- Completeness means defining all user-required services, and consistency means avoiding contradictory
definitions.

8. Practical Challenges in Large Systems:

- Achieving consistency and completeness is challenging for large, complex systems.
- Mistakes and omissions are common due to the complexity of specifications and the involvement of multiple
stakeholders with varied and sometimes conflicting needs.

9. Stakeholder Inconsistencies:
- Stakeholders, individuals or roles affected by the system, often have inconsistent needs.
- Inconsistent requirements may not be evident initially, leading to problems during deeper analysis or after
system delivery.
Non-functional requirements

1. Definition and Nature of Non-functional Requirements:

- Not directly related to specific services but focus on system properties.
- Include aspects like reliability, response time, and constraints on implementation.

2. Criticality of Non-functional Requirements:

- Typically relate to system-wide characteristics (performance, security, availability).
- Often more critical than individual functional requirements.
- Failure to meet a non-functional requirement can render the entire system unusable.

3. Examples of Critical Non-functional Requirements:

- In aviation, reliability requirements are essential for certification.
- In embedded control systems, meeting performance requirements is crucial for proper operation.

4. Challenges in Identifying Components for Non-functional Requirements:

- Difficult to associate components directly with non-functional requirements.
- Implementation of non-functional requirements may be diffused throughout the system.

5. Reasons for Diffusion of Non-functional Requirements:

- Non-functional requirements may impact overall system architecture.
- A single non-functional requirement (e.g., security) may generate various related functional requirements.

6. Origins of Non-functional Requirements:

- Arise from user needs, budget constraints, organizational policies, interoperability requirements, safety
regulations, and privacy legislation.

7. Classification of Non-functional Requirements:

- **Product Requirements:** Specify or constrain software behavior (e.g., performance, reliability, security,
usability).

- **Organizational Requirements:** Derived from customer and developer policies and procedures (e.g.,
operational processes, development standards, environmental requirements).
- **External Requirements:** Stem from factors external to the system and its development process (e.g.,
regulatory, legislative, and ethical requirements).

8. Types of Non-functional Requirements:

- Product requirements, organizational requirements, and external requirements are three broad categories.

- Examples within each category include performance, reliability, security, operational processes, development
standards, and ethical considerations.
The software requirements document
1. Defini)on and Purpose:
- So5ware requirements document (SRS) is an official statement of what system developers should
implement.
- It includes both user requirements and detailed system requirements.

2. Integra)on of User and System Requirements:

- User and system requirements may be integrated into a single descrip)on or defined separately.
- Large sets of requirements might have detailed system requirements in a separate document.

3. Importance in Outsourced Development:

- Essen)al when an outside contractor is developing the so5ware system.
- Agile methods argue against formal documents due to rapidly changing requirements.

4. Agile Development Approach:

- Agile methods like Extreme Programming collect user requirements incrementally as user stories on cards.
- Requirements are priori)zed for implementa)on in the next system increment.

5. Suppor)ng Document for Business Systems:

- Suggests wri)ng a short suppor)ng document defining business and dependability requirements, even in
agile environments.
- Helps to remember overall system requirements amidst a focus on func)onal requirements for the next
release.

6. Diverse Users and Usage:

- Users range from senior management to so5ware engineers.
- Document is a compromise between communica)ng to customers, detailing for developers and testers, and
including informa)on about system evolu)on.

7. Level of Detail:
- Cri)cal systems require detailed requirements, especially for safety and security analysis.
- Outsourced projects need detailed and precise specifica)ons.
- In-house itera)ve development allows for less detail, resolving ambigui)es during system development.

8. Possible Organiza)on Based on IEEE Standard:

- Figure 4.7 presents one possible organiza)on for a requirements document based on an IEEE standard.
- Extended to include informa)on about predicted system evolu)on.

9. Adapta)on to Development Approach:

- The level of detail depends on the type of system and the development process.
- Evolu)onary approaches focus on user and high-level non-func)onal requirements, leaving detailed
chapters out.

10. Considera)ons for Large System Projects

Necessary to define requirements when so5ware is part of a larger project with interac)ng hardware and
so5ware systems.
1. Requirements Specification Process:

- Involves writing down user and system requirements in a requirements document.

- Ideal requirements are clear, unambiguous, easy to understand, complete, and consistent.

2. Challenges in Achieving Ideal Requirements:

- Difficult due to different interpretations by stakeholders and inherent conflicts and inconsistencies.

3. User Requirements:
- Describe both functional and non-functional requirements in a way understandable by users without
technical knowledge.
- Should specify only the external behavior of the system.
- Should be written in natural language with simple tables, forms, and intuitive diagrams, avoiding software
jargon.

4. System Requirements:
- Expanded versions of user requirements used by software engineers for system design.
- Add detail and explain how user requirements should be provided.
- Used as part of the contract for system implementation.
- Ideally, describe only the external behavior and operational constraints of the system.

5. Exclusion of Design Information:

- Ideally, system requirements should not include details of system architecture or design.
- Practically challenging due to the need for an initial system architecture, interoperability with existing
systems, and fulfilling non-functional requirements.

6. Reasons for Including Design Information:

- Initial architecture aids in structuring the requirements specification.
- Interoperability with existing systems imposes design constraints.
- Specific architecture may be required for non-functional requirements, especially in safety-critical systems.

7. Notations for Writing System Requirements:

- User requirements mostly in natural language, supplemented by diagrams and tables.
- System requirements can be written in natural language, graphical models (e.g., UML sequence charts, state
charts), or formal mathematical specifications (rarely used except for safety- or security-critical systems).

8. Graphical Models Usage:

- Useful for showing state changes or describing sequences of actions.
- UML sequence charts and state charts are examples.

9. Formal Mathematical Specifications:

- Occasionally used for safety- or security-critical systems.
- Rarely used in other circumstances.
1.Requirements Validation:
- Process of ensuring that requirements define the system as desired by the customer.
- Overlaps with analysis to identify and address problems with the requirements.

2. Importance of Requirements Validation:

- Errors in requirements can lead to extensive rework costs during development or after system deployment.
- Fixing requirements problems is costlier than fixing design or coding errors.

3. Checks During Requirements Validation:

- **Validity Checks:** Identify if additional or different functions are required based on further thought and
analysis.
- **Consistency Checks:** Ensure no conflicts or contradictions exist in the requirements.
- **Completeness Checks:** Verify that all functions and constraints intended by the system user are defined.
- **Realism Checks:** Assess if requirements can be realistically implemented with existing technology,
considering budget and schedule constraints.
- **Verifiability:** Write requirements so that they are verifiable through a set of tests demonstrating system
compliance.

4. Requirements Validation Techniques:

- **Requirements Reviews:** Systematically analyze requirements for errors and inconsistencies with a team
of reviewers.
- **Prototyping:** Demonstrate an executable model of the system to end-users and customers for
experimentation.
- **Test-Case Generation:** Develop test cases during validation to reveal requirements problems. Difficult
tests indicate potential implementation challenges.

5. Challenges in Requirements Validation:

- Difficult to show conclusively that a set of requirements meets user needs.
- Users struggle to visualize the system in operation and its fit into their work.
- Abstract analysis is challenging even for skilled computer professionals.
- Requirements problems may not all be discovered during the validation process, leading to inevitable changes
after agreement on the requirements document.

Requirements management

**Requirements Management:**
1. **Nature of Changing Requirements:**
- Large software systems often developed for 'wicked' problems, making complete definition challenging.
- Stakeholders' evolving understanding of the problem leads to changing requirements.

2. **Post-Installation Changes:**
- New requirements emerge after system installation due to unforeseen effects on business processes.
- Users discover new needs and priorities based on system experience.

3. **Reasons for Inevitable Change:**

- Business and technical environment changes after installation.
- System customers and end-users have different requirements.
- Diverse user community results in conflicting priorities.

4. **Requirements Management Process:**

 - Process of understanding and controlling changes to system requirements.
- Establish formal process for change proposals and maintain links between dependent requirements.

**Requirements Management Planning:**

1. **Essential Planning Considerations:**
- Requirements identification for cross-referencing.
- Change management process for assessing impact and cost.
- Traceability policies defining relationships between requirements.
- Tool support for requirements storage, change management, and traceability.

**Requirements Change Management:**

1. **Automated Support:**
- Automated tools needed for requirements storage, change management, and traceability.
- Tool support aids in processing large amounts of requirements information.

2. **Change Management Stages:**

- **Problem Analysis and Change Specification:**
- Analyze identified requirements problems or change proposals.
- Feedback to change requestor for more specific proposals or withdrawal.

- **Change Analysis and Costing:**

- Assess the proposed change's effect using traceability information.
- Estimate the cost in terms of modifications to the requirements document, system design, and
implementation.
- Decide whether to proceed with the change.

- **Change Implementation:**
- Modify requirements document and, if necessary, system design and implementation.
- Organize the document for ease of change without extensive rewriting.

3. **Challenges with Urgent Changes:**

- Avoid retrospective modification of the requirements document after system changes.
- Urgent changes can lead to misalignment between the requirements specification and system
implementation.

4. **Agile Development Approach:**

- Agile processes like extreme programming handle changing requirements by prioritizing changes without a
formal change management process.

- Users prioritize changes, and high-priority changes may lead to dropping planned features in the next iteration.