Requirements Engineering

What is Requirements Engineering?

• Requirements Engineering (RE) is not only about identifying system needs, but also
about systematically documenting, validating, and managing those needs throughout
the lifecycle of a software product. RE addresses both what a system should do
(functional requirements) and how it should perform (non-functional requirements). It
also considers business goals, regulatory constraints, and technical feasibility.

RE enables developers to reduce ambiguity, scope creep, and ensures the resulting
software delivers true value to stakeholders. In safety-critical systems, such as medical
devices or aerospace control systems, RE is crucial to ensure compliance with standards
and prevent catastrophic failures.

• Requirements Engineering (RE) is a vital discipline within software engineering that

focuses on understanding what a system must do and under what constraints it must
operate. It provides a roadmap for building systems that align with user goals and
business objectives. Unlike coding or testing, which deal with implementation, RE is
concerned with problem definition.

RE is both a technical and a communication process. It involves interacting with a wide

variety of stakeholders—customers, users, developers, testers, and business managers—
 Why is Requirements Engineering Important?
1. **Avoids Costly Rework**: Mistakes in requirements discovered later in
development cost significantly more to fix.

2. **Improves Communication**: Acts as a common language between users and

technical teams.

3. **Enables Traceability**: Requirements link to design, code, and test cases,

enabling verification and validation.

4. **Supports Project Management**: Enables scheduling, cost estimation, and

risk identification.

Real Example: NASA's Mars Climate Orbiter failed due to inconsistent units in
requirements (pound-force vs newtons). Better RE would have prevented this
disaster.
 Phases of Requirements Engineering

RE is an iterative process consisting of the following activities:

1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Requirements Management

These activities often overlap and feed into each other. Each stage
builds upon the results of the previous one.
 1. Inception
Inception focuses on identifying stakeholders, understanding the overall
vision of the system, and defining the project scope. The goal is to create a
shared understanding of the 'problem space'.

Activities include:
- Identifying stakeholders (users, investors, regulatory bodies)
- Defining the business context
- Setting system boundaries
- Establishing initial use cases

For example, in a Safe Home System, inception identifies homeowners,

emergency responders, and the app development team as stakeholders.
Figure: Inception Stakeholder Context Diagram
 2. Elicitation
• Elicitation can be especially challenging when dealing with tacit knowledge—things
users know but don't easily express. Techniques like prototyping, job shadowing, and
role-playing help uncover such hidden requirements.

In agile environments, elicitation is a continuous activity rather than a one-time phase.

Product Owners and Business Analysts must revisit and refine requirements every sprint
based on evolving feedback.

• This phase involves gathering requirements through direct interaction with stakeholders.
Challenges include poor communication, vague expectations, and hidden needs.

Common techniques include:

- **Interviews**: One-on-one Q&A sessions.
- **Focus Groups**: Group discussions for shared understanding.
- **Observation**: Watching users interact with current systems.
- **Document Analysis**: Studying existing systems or manuals.
- **Prototyping**: Creating mockups to clarify needs.

Elicitation helps bridge the gap between stakeholder expectations and actual system
 3. Elaboration
• Elaboration converts vague stakeholder needs into detailed specifications. Advanced
modeling techniques such as behavioral diagrams (state machines), object
interaction (sequence diagrams), and decision tables are used.

The goal is to make requirements testable, measurable, and implementable.

Elaboration also helps identify edge cases, error scenarios, and alternative flows that
may not be obvious in early discussions.

• During elaboration, informal requirements are translated into formal models and
refined for clarity. Techniques include:

- Use Case Diagrams: Describe functional interactions

- Activity Diagrams: Describe process logic
- Entity-Relationship Diagrams: Data models
- Class Diagrams: Structure of objects in OO(Object-Oriented System) systems

This phase ensures that every stakeholder requirement is captured in an actionable

Figure: Use Case Diagram for Safe Home System
 4. Negotiation

• Negotiation resolves conflicts between stakeholders. When multiple

users demand conflicting features or timelines, trade-offs are made.

Activities:
- List conflicting requirements.
- Identify constraints and feasibility.
- Prioritize using MoSCoW: Must, Should, Could, Won’t.

Example: Choosing between building mobile alerts (Must) versus full

3D camera streaming (Could).
 5. Specification(SRS: Software Requirements
Specification)
• A well-crafted SRS avoids ambiguity by using structured templates, glossary of terms, and measurable criteria.
IEEE 830 is a commonly used standard for writing SRS documents.

Common Structure of SRS:

1. Introduction (Purpose, Scope, Definitions)
2. Overall Description (Product Perspective, User Classes)
3. Specific Requirements (FRs and NFRs)
4. Appendices (References, Glossary)
5. Index

A good SRS acts as a legal contract and can be used to derive test cases, traceability matrices, and acceptance
criteria.

• Specification results in a written document (SRS) that details what the system will do, how it will behave, and
under what constraints.

SRS Sections include:

- Purpose and Scope
- Functional Requirements (FR): Login, alert triggering
- Non-Functional Requirements (NFR): Performance, security
- External Interfaces: APIs, UI, sensors
- Assumptions and Constraints
 6. Validation

Validation ensures the requirements are correct and reflect stakeholder

intent. Key validation techniques:

- **Reviews**: Peer or client evaluation

- **Walkthroughs**: Step-by-step explanation
- **Prototypes**: Early model demonstration
- **Checklists**: Ensure completeness

Example: A prototype mobile app interface for the Safe Home system is
tested by homeowners for usability feedback.
 7. Requirements Management
• Requirements change due to business evolution, customer feedback, or technical innovation. RE
management ensures each change is justified, approved, and analyzed for its downstream
impact.

Modern tools offer:

- Version control
- Change logs
- Baseline tracking
- Traceability matrix (to design, code, and tests)

Stakeholders are notified of changes, and project managers assess how updates affect deadlines,
budgets, and deliverables.

• Requirements evolve. This phase ensures changes are tracked, approved, and impact is analyzed.

Activities:
- Maintain a versioned SRS
- Change control board reviews
- Update traceability matrix
Functional vs Non-Functional Requirements
**Functional Requirements:** Define what the system should do.
Example: "System shall lock all doors when 'secure' command is given."

**Non-Functional Requirements:** Define how the system behaves.

Example: "System shall respond to alerts within 2 seconds."

Both are essential for system success.

 Tools for Requirement Management

- **JIRA**: Agile project and requirement tracking.

- **IBM DOORS**: Enterprise-grade tool for RE lifecycle.
- **ReqView**: Lightweight tool for SRS authoring.
- **Helix RM**: For high-assurance and compliance-heavy projects.
- **Visual Paradigm**: Modeling and diagramming for RE.
 Challenges in Requirements Engineering

1. Ambiguity: Requirements may be vague.

2. Evolving Needs: Stakeholders may change expectations.
3. Conflicting Requirements: Business vs technical needs.
4. Technical Constraints: Budget, tech stack limitations.
5. Poor Stakeholder Involvement: Leads to gaps in understanding.

Overcoming these requires communication, continuous feedback,

prototyping, and agile practices.
 SafeHome Example – Functional Requirements

The SafeHome security system enables a homeowner to monitor and

control security in their house. The system is equipped with sensors,
keypad interface, and a control panel as shown in the image.

**Functional Requirements include:**

- The system must allow the user to arm and disarm the alarm.
- The user must be able to configure different security modes: away,
stay, instant, and bypass.
- The system shall notify the user when a sensor detects motion.
- The keypad must accept a 4-digit code for secure access.
- The system must indicate armed and power status through LED lights.
 SafeHome Example – Use-Cases and Actors
Actors involved in the SafeHome system include:
- **Homeowner**: Main user who configures and monitors the system.
- **Security Company**: Optional actor who may receive alerts.

**Use Cases include:**

1. Arm System
2. Disarm System
3. Monitor Sensors
4. Configure Security Modes
5. Respond to Alerts

Each use case represents a scenario in which the user interacts with the system.
Diagrams are used to visualize these interactions clearly.
 SafeHome Example – Requirements Modeling
Requirements modeling focuses on creating visual and textual representations of
how the SafeHome system should function.

Models Used:
- **Use Case Diagrams**: Show interactions between actors and use cases.
- **Activity Diagrams**: Show workflows for specific tasks like 'Arming the
System'.
- **State Diagrams**: Represent states such as Armed, Disarmed, and Triggered.
- **Sequence Diagrams**: Show how objects (e.g., sensors, controller) interact
over time.

This modeling ensures a complete understanding of system behavior and helps

bridge communication between stakeholders and developers.
Figure: Keypad interface of the SafeHome security system