Requirements Engineering: Main Activities and Characteristics of a Good SRS Document

Part 1: Main Activities in Requirements Engineering

Requirements Engineering (RE) is the process of understanding and defining what services are required from a system and identifying the constraints on its operation and development. It is a critical stage because errors here propagate into design and implementation.

The main activities in requirements engineering are:

1. Feasibility Study

Before beginning full requirements analysis, a feasibility study is conducted to determine whether the proposed system is worth developing.

• It checks technical feasibility (can it be built?), economic feasibility (is it cost-effective?), and operational feasibility (will users use it?).
• Example: Before building an online banking system, the team checks whether the existing network infrastructure can support it and whether the budget is sufficient.

2. Requirements Elicitation and Analysis

This activity involves gathering requirements from stakeholders (customers, end users, domain experts).

Techniques used include:

• Interviews with stakeholders
• Observation of existing workflows
• Questionnaires and surveys
• Prototyping to clarify vague requirements
• Workshops and brainstorming sessions

Example: A developer interviews hospital staff to understand how patient records are currently managed before designing a Hospital Management System.

Challenges in this activity:

• Stakeholders may not know exactly what they want.
• Different stakeholders may have conflicting requirements.
• Domain knowledge may be difficult to understand.

3. Requirements Specification

Once requirements are gathered and analyzed, they are documented formally in a Software Requirements Specification (SRS) document.

Requirements are classified as:

• Functional Requirements: What the system should do (e.g., "The system shall allow users to log in using a username and password.")
• Non-Functional Requirements: Constraints on the system (e.g., "The system shall respond to any query within 2 seconds.")
• Domain Requirements: Requirements derived from the application domain (e.g., "The system shall comply with banking regulations.")

Example: For a library management system, a functional requirement is "The system shall allow librarians to add new books," and a non-functional requirement is "The system shall be available 99.9% of the time."

4. Requirements Validation

This activity checks that the documented requirements actually define the system the customer wants. It verifies that requirements are:

• Complete
• Consistent
• Realistic
• Verifiable

Techniques used:

• Requirements reviews (formal inspection by a team)
• Prototyping (building a quick model to validate understanding)
• Test-case generation (writing test cases to check if requirements are testable)

Example: A review team checks the SRS of a payroll system and discovers that the requirement "The system shall process salaries quickly" is not measurable, so it is revised to "The system shall process all salary transactions within 5 seconds."

5. Requirements Management

Requirements change over time due to evolving business needs, new regulations, or stakeholder feedback. Requirements management handles:

• Tracking changes to requirements
• Maintaining traceability (linking requirements to design and test cases)
• Controlling the impact of changes

Example: If a client requests a new feature in an e-commerce system after development has started, requirements management ensures the change is documented, evaluated for impact, and approved before implementation.

Summary Diagram of RE Activities

Feasibility Study
       |
       v
Requirements Elicitation and Analysis
       |
       v
Requirements Specification (SRS Document)
       |
       v
Requirements Validation
       |
       v
Requirements Management (ongoing)

Part 2: Desirable Characteristics of a Good SRS Document

A Software Requirements Specification (SRS) is a formal document that describes the intended behavior, functionality, and constraints of a software system. A good SRS must have the following characteristics:

1. Correctness

Every requirement stated in the SRS must accurately represent what the customer needs. There should be no false or misleading statements.

Example: If the customer needs the system to support 500 concurrent users, the SRS must state exactly that, not "a large number of users."

2. Completeness

The SRS must cover all functional and non-functional requirements, all possible inputs and outputs, and all constraints. Nothing important should be left out.

Example: An SRS for an ATM system must include requirements for cash withdrawal, balance inquiry, PIN change, and error handling for invalid PIN, not just the main transaction flow.

3. Consistency

No two requirements in the SRS should contradict each other.

Example: It would be inconsistent to state both "The system shall store user passwords in plain text" and "The system shall ensure all passwords are encrypted."

4. Unambiguity

Each requirement must have only one possible interpretation. Vague language like "fast," "user-friendly," or "efficient" should be avoided or precisely defined.

Example: Instead of writing "The system shall respond quickly," write "The system shall respond to all user requests within 3 seconds under normal load."

5. Verifiability (Testability)

Every requirement must be written in such a way that it can be tested or verified. If a requirement cannot be tested, it is not useful.

Example: "The system shall allow login" is verifiable. "The system shall be good" is not verifiable.

6. Modifiability

The SRS should be structured so that changes can be made easily without affecting the entire document. It should have a clear organization, table of contents, and cross-references.

Example: Using numbered sections and a requirements traceability matrix makes it easy to update one requirement without confusion.

7. Traceability

Each requirement should be traceable back to its source (customer need or business goal) and forward to design and test cases.

Example: Requirement R-12 "User shall be able to reset password via email" can be traced to the customer's security policy and linked to Test Case TC-12.

8. Ranked for Importance and Stability

Requirements should be prioritized (e.g., mandatory, desirable, optional) so that developers know what to implement first.

Example: In a hospital system, "Patient record storage" is mandatory, while "Graphical dashboard" may be marked as desirable and implemented only if time and budget permit.

Summary

Requirements engineering moves systematically from feasibility study through elicitation, specification, validation, and ongoing management, and the resulting SRS document only serves its purpose as the contract between developers and stakeholders when it is correct, complete, consistent, unambiguous, verifiable, modifiable, traceable, and properly ranked, since a defect in any one of these characteristics propagates directly into design, implementation, and testing errors later in the project.

Differences Between Functional and Non-Functional Requirements

Definitions

Functional Requirements define what a system or its component should do. They specify the functions, features, and behaviours that the software system must possess.

Non-Functional Requirements define the quality attributes of a software system. They specify how the software system should fulfill the functional requirements (e.g., performance, reliability, usability).

Differences Table

Which is More Critical and Why?

Functional requirements are more critical than non-functional requirements. The reasons are:

1. Mandatory Nature: Functional requirements are mandatory, meaning the system cannot be accepted or delivered without fulfilling them. Non-functional requirements, while important, are not strictly mandatory.

2. Core Purpose: Functional requirements define the very purpose of the system. If a system does not perform its intended functions (e.g., a banking system that cannot process transactions), it is completely useless regardless of how fast or secure it is.

3. Basis for Non-Functional Requirements: Non-functional requirements only make sense in the context of functional requirements. A system must first do something before we can measure how well it does it.

4. User Specification: Functional requirements are specified directly by the user, reflecting the actual needs the system must meet. Satisfying the user's core needs is the primary goal of software development.

Note: However, in safety-critical systems (e.g., nuclear power plants, aviation), non-functional requirements such as reliability and safety can become equally or even more critical, since failure can cost lives.

Legacy System

Definition

A legacy system is an old system that was developed using older technology, methods, and tools, but which is still in use and continues to provide essential business functions. These systems are typically based on outdated hardware and software platforms, programming languages, and development approaches that are no longer in mainstream use. Despite being old, organizations continue to rely on them because they perform critical operations.

Characteristics of Legacy Systems

• Built using older programming languages (e.g., COBOL, FORTRAN)
• Difficult to maintain and modify
• Poorly documented
• Tightly coupled components
• Often lack modern interfaces and integration capabilities

Importance of Legacy Systems

1. Business Continuity

Legacy systems often support critical business processes that have been running for years. Replacing them abruptly can disrupt operations, so they remain in use to ensure continuity.

2. High Replacement Cost

Replacing a legacy system requires significant financial investment in terms of new hardware, software, training, and migration. Organizations prefer to maintain them to avoid such costs.

3. Stored Business Knowledge

Legacy systems contain years of accumulated business logic and data that are deeply embedded. This knowledge is difficult to replicate in a new system without risk of data loss.

4. Reliability and Stability

Despite being old, legacy systems are often highly stable and reliable because they have been tested and refined over many years of operation.

5. Basis for System Evolution

Legacy systems serve as a foundation for understanding existing requirements. New systems are often designed by studying and improving upon legacy systems, making them important for software evolution and re-engineering.

6. Risk Avoidance

Organizations avoid replacing legacy systems because migration carries high risk of failure, data corruption, or loss of functionality. Maintaining them reduces operational risk.

Summary Table

In conclusion, although legacy systems are technologically outdated, their importance to organizations remains high due to their reliability, embedded business knowledge, and the high cost and risk associated with replacing them.

Behavioral Model

Definition

A behavioral model is a type of system model that describes the dynamic behavior of a system as it executes. It shows what happens or what should happen when a system responds to a stimulus from its environment. In other words, it represents how a system changes its state in response to events or data inputs over time.

Behavioral model is one of the four main types of system models (along with Contextual, Interaction, and Structural models) used to represent a system from different perspectives during system modeling.

Purpose

• To show the dynamic aspects of a system
• To describe how a system responds to events or inputs
• To help analysts and designers understand the flow of control and data within a system
• To validate system requirements during requirement engineering

Types of Stimuli in Behavioral Models

Behavioral models can be driven by two types of stimuli:

Common Notations Used

1. State Diagram (State Machine Diagram) - shows states and transitions
2. Activity Diagram - shows flow of activities/actions

Example: ATM Behavioral Model (State Diagram)

Consider a simple ATM machine system. Its behavior can be modeled using states and transitions:

[Idle]
   |
   | Card Inserted
   v
[Card Verification]
   |
   | PIN Entered Correctly
   v
[Menu Display]
   |
   | User selects "Withdraw"
   v
[Processing Withdrawal]
   |
   | Amount Dispensed
   v
[Transaction Complete]
   |
   | Card Ejected
   v
[Idle]

Explanation of States:

• Idle: ATM is waiting for a customer
• Card Verification: ATM reads and verifies the inserted card
• Menu Display: Customer is shown available options after successful PIN entry
• Processing Withdrawal: ATM processes the withdrawal request
• Transaction Complete: Cash is dispensed and receipt is printed
• Idle: ATM returns to waiting state after card is ejected

Key Points

• Behavioral models are primarily used in requirement engineering to validate and communicate system functionality
• They help identify what the system does in response to various inputs or events
• They are especially useful for real-time and event-driven systems such as ATMs, traffic control systems, and embedded systems

Summary: A behavioral model captures the dynamic nature of a system by showing how it transitions between states or performs activities in response to stimuli. It is an essential tool for understanding, validating, and communicating system behavior during software development.