UNIT 1: SYSTEM REQUIREMENT SPECIFICATION AND ANALYSIS

1. Introduction to System Requirements

Before building or buying any system, we must answer: “What exactly should the system do?”
The answer is captured as system requirements – a complete description of the system’s functions, features, constraints, and quality attributes.

Two key activities:

• Requirement Analysis – The process of discovering, understanding, documenting, and validating the needs of stakeholders.
• System Requirement Specification (SRS) – The formal document that records those requirements in a clear, complete, and unambiguous way.

Analogy: Building a house.

• Requirement analysis = discussing with the family: number of bedrooms, kitchen layout, budget, style.
• SRS = the detailed blueprint and contract that the architect gives to the constructor.

2. Types of System Requirements

Requirements are broadly divided into Functional and Non-Functional.

2.1 Functional Requirements

Describe what the system must do – specific behaviours, inputs, outputs, and data processing.

Examples for a Library Management System:

• The system shall allow a librarian to add a new book (title, author, ISBN, category).
• The system shall allow a member to borrow a maximum of 5 books at a time.
• The system shall send an overdue email notification 3 days after the due date.
• The system shall generate a report of all books borrowed in the last month.

Characteristics:

• Action-oriented (verbs: add, delete, update, search, calculate, generate)
• Directly testable (you can write a test case)

2.2 Non-Functional Requirements (Quality Attributes)

Describe how well the system performs its functions – constraints and quality criteria.

Key insight: Missing non-functional requirements is a common reason for project failure. Users will say “the system is slow” even if all functional requirements are met.

2.3 Other Classifications

• User Requirements – Statements in natural language for customers (e.g., “The customer can view order history”).
• System Requirements – More technical, detailed version for developers.
• Business Requirements – High-level organizational goals (e.g., “Increase online sales by 20%”).
• Transition Requirements – Needed to move from old to new system (e.g., data migration, user training).

3. The Requirement Analysis Process

Requirement analysis is not a single step; it is an iterative process throughout the early stages of SAD.

3.1 Process Overview

Identify Stakeholders → Gather Requirements → Analyze & Model → Validate → Document (SRS) → Manage Changes

3.2 Step 1: Identify Stakeholders

Stakeholders are anyone who has an interest in the system. Missing a key stakeholder leads to missed requirements.

Technique: Create a stakeholder map – list all roles, their power/interest, and how to engage them.

3.3 Step 2: Gather Requirements (Elicitation)

Common techniques – use multiple to cross-check.

Example combination:

• Interview managers for strategic requirements.
• Observe clerks for operational details.
• Run a workshop to resolve conflicts between sales and warehouse.

3.4 Step 3: Analyze and Model Requirements

Raw data from elicitation is messy. Analysis organizes it into models.

Common models used in analysis:

• Use Case Diagrams – Shows actors and system functions (high-level).
• Use Case Descriptions – Step-by-step flow of events for each use case.
• Activity Diagrams – Workflow and decision logic.
• Class Diagrams – Data entities and relationships.
• State Machine Diagrams – Object lifecycle (e.g., Order: new → paid → shipped → delivered).
• User Stories (Agile) – “As a [role], I want [feature] so that [benefit].”

Example User Story:
“As a customer service agent, I want to see the complete order history of a caller within 5 seconds, so that I can resolve issues without placing them on hold.”

3.5 Step 4: Validate Requirements

Validation ensures that the requirements are correct, complete, consistent, and feasible.

Validation techniques:

Common validation questions:

• Can this requirement be implemented with the given budget/time?
• Are there any conflicting requirements? (e.g., one user wants real-time, another wants batch)
• Is the requirement ambiguous? (“fast” → replace with “under 2 seconds”)

3.6 Step 5: Document in SRS (see Section 4)

3.7 Step 6: Manage Changes (Requirements Traceability)

Requirements change over time. Use a change control process:

1. Any change request is logged.
2. Impact analysis (cost, schedule, other requirements).
3. Approval by a change control board.
4. Update the SRS and traceability matrix.

4. System Requirement Specification (SRS) Document

4.1 What is an SRS?

An SRS is a formal, approved document that defines all system requirements. It serves as a contract between the customer and the development team.

4.2 Characteristics of a Good SRS (IEEE 830 Standard)

4.3 Standard SRS Outline (IEEE 830-1998, adapted)

Below is a practical template you can use.

1. Introduction

• 1.1 Purpose – Why this SRS?
• 1.2 Scope – What system does, benefits, objectives.
• 1.3 Definitions, Acronyms, Abbreviations – Glossary.
• 1.4 References – Related documents.
• 1.5 Overview – How rest of SRS is organized.

2. Overall Description

• 2.1 Product Perspective – Is this new, replacement, or enhancement?
• 2.2 User Characteristics – Education level, technical expertise.
• 2.3 Assumptions and Dependencies – e.g., reliable internet.
• 2.4 Constraints – Budget, regulatory, hardware.

3. Specific Requirements

• 3.1 Functional Requirements (numbered FR-1, FR-2, …)
• 3.2 Non-Functional Requirements (NFR-1, NFR-2, …)
• 3.3 External Interface Requirements (UI, Hardware, Software, Communication)

4. Appendices

• Use case diagrams, data dictionary, screen mock-ups, etc.

5. Index / Traceability Matrix

• Map each requirement to its source.

4.4 Example SRS Excerpt

System: Online Bookstore (simplified)

FR-1: User Registration

• FR-1.1: The system shall allow a new user to create an account by providing name, email, password, and shipping address.
• FR-1.2: The system shall send a verification email to the provided email address.
• FR-1.3: The account shall be activated only after the user clicks the verification link.

FR-2: Search Books

• FR-2.1: The system shall allow a user to search books by title, author, or ISBN.
• FR-2.2: The system shall display search results sorted by relevance (default) or price (optional).
• FR-2.3: The system shall show no more than 20 results per page.

NFR-1: Performance

• NFR-1.1: Search results shall appear within 3 seconds for 95% of requests.
• NFR-1.2: The system shall support 500 concurrent users without response time exceeding 5 seconds.

NFR-2: Security

• NFR-2.1: Passwords shall be stored using bcrypt hashing (salt factor 10).
• NFR-2.2: All pages except login shall require HTTPS.

Interface Requirement: Payment Gateway

• IR-1: The system shall integrate with Stripe API version 2023-08-16 for credit card processing.

4.5 Common SRS Pitfalls and Solutions

5. Requirement Analysis Techniques in Detail

5.1 Use Case Modeling

A use case describes a sequence of actions that an actor (user or external system) performs to achieve a goal.

Components:

• Actor – Someone or something outside the system.
• Use case – A specific goal (verb-noun: “Place Order”, “Cancel Booking”).
• System boundary – Box around use cases.

Example: Library Management System

[Actor: Librarian] ---> (Add Book)
[Actor: Member] ---> (Borrow Book)
[Actor: Member] ---> (Return Book)
[Actor: System Clock] ---> (Send Overdue Notices)

Use case description template (for “Borrow Book”):

5.2 Data Flow Diagram (DFD) for Analysis

DFDs show how data moves through the system. Useful for identifying missing inputs/outputs.

• Level 0 (Context diagram) – System as one process, external entities.
• Level 1 – Major processes.

Example for Order System (Level 1):

Customer → [Process 1: Validate Order] → Order data → [Process 2: Update Inventory] → Inventory file
              ↑                                           ↓
           (Rejection)                              (Confirmation)

5.3 User Stories (Agile approach)

In Agile, requirements are written as user stories on cards. The 3 C’s:

• Card – short description.
• Conversation – details discussed with product owner.
• Confirmation – acceptance criteria.

Example:
Card: “As a traveler, I want to filter hotels by price range, so that I stay within my budget.”
Acceptance criteria:

• Price slider from $0 to $500.
• Results update without page reload.
• Default shows all hotels.

5.4 Prototyping for Analysis

Types of prototypes:

• Throwaway (Rapid) – Build quickly, get feedback, discard. Good for UI requirements.
• Evolutionary – Build a minimal system, then add features iteratively.
• Tools: Figma, Balsamiq, Axure, or paper sketches.

6. Requirement Traceability

Traceability Matrix links requirements from source to implementation and testing.

Example Simple Traceability Matrix:

Why important?

• When a requirement changes, you know which design and tests are affected.
• You can prove that all requirements have been implemented (no “rogue” features).

7. Real-World Example: Complete Requirement Analysis for a Small Project

Project: Restaurant Table Reservation System (web + mobile)

Step 1 – Stakeholders

• Restaurant owner (reduce no-shows)
• Receptionist (easy drag-drop management)
• Customers (book online + reminders)
• Kitchen manager (see expected covers)

Step 2 – Elicitation

• Interview owner: “We lose $500 per night because of no-shows. We need prepayment or confirmation.”
• Observe receptionist: Currently uses paper diary – often double-books.
• Survey 50 customers: 80% want SMS reminders.

Step 3 – Analysis (Key findings)

• Conflicting requirement: Owner wants prepayment; customers want free cancellation.
• Resolution: Prepayment only for large groups (8+) or peak hours.

Step 4 – Write SRS (excerpts)

• FR-1: Customer selects date/time/party size and sees availability (real-time).
• FR-2.1: Receptionist sees a floor plan showing booked/available tables.
• NFR-1.1: Availability check returns results in <1 second.

Step 5 – Validation

• Walkthrough with owner/receptionist. They spot missing requirement: “What if a walk-in customer arrives? Receptionist needs to add offline booking.”
• Fix: Add FR-2.3: “Receptionist can manually add a walk-in reservation.”

Step 6 – Baseline SRS and traceability
All requirements numbered and signed off.

8. Summary Table – Key Concepts