1.6 SRS Document & System Modeling

Software Requirements Specification (SRS)

The SRS is the formal, written document that captures all requirements after elicitation, analysis and validation. It is the contract between the customer and the developer.

The most widely used standard is IEEE 830-1998 (Recommended Practice for Software Requirements Specifications).

IEEE 830 Standard SRS Structure

1. Introduction
   1.1 Purpose
   1.2 Document Conventions
   1.3 Intended Audience and Reading Suggestions
   1.4 Project Scope
   1.5 References

2. Overall Description
   2.1 Product Perspective
   2.2 Product Features (high-level)
   2.3 User Classes and Characteristics
   2.4 Operating Environment
   2.5 Design and Implementation Constraints
   2.6 User Documentation
   2.7 Assumptions and Dependencies

3. System Features (Functional Requirements)
   3.1 Feature 1
       3.1.1 Description and Priority
       3.1.2 Stimulus / Response Sequences
       3.1.3 Functional Requirements
   3.2 Feature 2 ... etc.

4. External Interface Requirements
   4.1 User Interfaces
   4.2 Hardware Interfaces
   4.3 Software Interfaces
   4.4 Communications Interfaces

5. Non-Functional Requirements
   5.1 Performance
   5.2 Safety
   5.3 Security
   5.4 Software Quality Attributes

6. Other Requirements
   Appendix A: Glossary
   Appendix B: Analysis Models (DFD, ER, UML)
   Appendix C: Issues List

Characteristics of a good SRS (IEEE 830)

A high-quality SRS must be:

Exam tip: Memorise this 8-point list. "List the characteristics of a good SRS" is a 7.5-mark short-answer staple.

---

Who reads the SRS?

The SRS is the single source of truth for the entire development team.

---

System Modeling — Overview

A model is a simplified, abstract representation of the system. SE uses three classical model families:

---

1. Data Flow Diagrams (DFD)

A DFD shows how data moves through a system. It has four notations:

Levels of DFD

• Level 0 (Context diagram) — the system as a single process, external entities, top-level data flows
• Level 1 — main sub-processes of the system
• Level 2 and below — decomposition of each Level 1 process

Example: Library System

Level 0 (Context):

   ┌──────────┐               ┌────────────────┐               ┌───────────┐
   │ Member   │ ── request ─→ │ Library System │ ── notice ──→ │ Member    │
   └──────────┘ ←─ receipt ── │                │               └───────────┘
                              └────────────────┘
                                      ↑↓
                              ┌──────────────┐
                              │  Librarian   │
                              └──────────────┘

Level 1:

   ┌──────────┐
   │ Member   │ ──→ [1. Search] ──→ [Book DB]
   │          │ ──→ [2. Issue]  ──→ [Loan DB]
   │          │ ←── [3. Return] ──── [Loan DB]
   └──────────┘
   ┌──────────┐
   │Librarian │ ──→ [4. Add Book] ──→ [Book DB]
   │          │ ──→ [5. Add Member]→ [Member DB]
   └──────────┘

DFD rules (often examined)

1. Every process must have at least one input AND one output (no "miracles", no "black holes")
2. Data flow must always be labelled (the data, not the process)
3. Conservation: input and output of a process must balance (with named transformations)
4. Levels are decomposed only when meaningful (avoid >3 sub-levels normally)
5. The Level-0 diagram is exactly one process — the system itself

---

2. Entity-Relationship (ER) Diagrams

The ER model (Peter Chen, 1976) captures the data the system stores. The three core elements:

Cardinality

Example (Library)

[Member]──(borrows: M:N)──[Book]
   │                          │
   ├─name                     ├─ISBN
   ├─member_id (PK)           ├─title
   ├─join_date                ├─author
   └─address                  └─copies_available

ER diagrams are the natural precursor to relational schema design (Unit III of DBMS).

---

3. UML — Unified Modeling Language

UML (Booch, Rumbaugh, Jacobson — the "Three Amigos" — OMG standard from 1997) is the de-facto standard for modeling object-oriented software. UML 2.x defines 14 diagram types in two groups:

Structural diagrams (the system is)

Behavioural diagrams (the system does)

The 5 most commonly examined in BCA: Use case, Class, Sequence, Activity, State machine. The others are advanced/professional usage.

Use case diagram — example

       Library System
   ┌──────────────────────┐
   │   ( Search Book )    │ ←── Member
   │   ( Issue Book  )    │ ←── Member
   │                      │
   │   ( Return Book )    │ ←── Member
   │                      │
   │   ( Add Book    )    │ ←── Librarian
   │   ( Add Member  )    │ ←── Librarian
   │                      │
   │   ( Generate    )    │ ←── Admin
   │   ( Report      )    │
   └──────────────────────┘

Each ellipse is a use case; stick figures are actors.

Class diagram — example

  ┌─────────────┐         ┌──────────────┐
  │   Member    │  1..*   │    Loan      │  *..1   ┌─────────┐
  │─────────────│ ─────── │──────────────│ ─────── │  Book   │
  │ id          │ borrows │ loan_id      │  has    │─────────│
  │ name        │         │ issue_date   │         │ isbn    │
  │ email       │         │ due_date     │         │ title   │
  │─────────────│         │ status       │         │─────────│
  │ +login()    │         │──────────────│         │ +view() │
  │ +renew()    │         │ +renew()     │         └─────────┘
  └─────────────┘         │ +return()    │
                          └──────────────┘

Sequence diagram — example (Issue Book)

 Member        UI         Library          BookDB         LoanDB
   │           │             │                │              │
   │── search ─→             │                │              │
   │           │── lookup ──→│── query ──────→│              │
   │           │             │←── books ──────│              │
   │           │←─ list ─────│                │              │
   │← display ─│             │                │              │
   │           │             │                │              │
   │── issue ──→             │                │              │
   │           │── issue ──→ │── check ──────→│              │
   │           │             │←─ ok ──────────│              │
   │           │             │── save loan ──────────────────→│
   │           │             │                │←── id ───────│
   │           │←─ receipt ──│                │              │
   │← receipt ─│             │                │              │

---

Comparison: DFD vs ER vs UML

---

Key Terms — Lesson 1.6

The terms below cover the SRS standard, the three modelling families, and the specific UML and DFD vocabulary that appears in every Unit-I modelling PYQ.

SRS (Software Requirements Specification) — The formal documented output of requirements engineering, capturing functional requirements, non-functional requirements, interface requirements, constraints, assumptions, and acceptance criteria for a system. Acts as the contract between customer and developer. IEEE 830-1998 is the standard template.

IEEE 830-1998 — The IEEE Recommended Practice for Software Requirements Specifications — the template most academic courses (including IPU) treat as canonical. Defines the eight-property quality model (correct, unambiguous, complete, consistent, ranked, verifiable, modifiable, traceable) and a numbered six-section structure.

Baseline SRS — A version of the SRS that has been reviewed, signed off, and frozen. Subsequent changes go through a Change Control Board. A baselined SRS is the reference document that design, code, and tests must conform to.

Single Source of Truth — A principle that there should be exactly one authoritative document for any given category of information — for requirements, the SRS; for design, the SDD; for test plans, the TP. Multiple "sources" for the same information always drift apart and produce inconsistency.

Functional Decomposition — The technique of breaking a complex function into smaller, more manageable sub-functions, recursively, until each leaf is small enough to specify directly. DFD levels (0, 1, 2, …) are an exercise in functional decomposition; the same principle drives high-level → low-level design.

Data Flow Diagram (DFD) — A graphical model from the Structured Systems Analysis & Design (SSAD) tradition (DeMarco, Yourdon, late 1970s) showing how data moves through a system — what processes transform it, what data stores hold it, and what external entities exchange it with the system. The four notations are process (circle), data store (open rectangle), external entity (rectangle), and data flow (arrow).

Context Diagram (DFD Level 0) — The top-level DFD representing the entire system as a single process, with all external entities and the major data flows in and out. The context diagram defines the system boundary — what is inside the system and what is outside.

DFD Level 1, Level 2, … — Successive decompositions of the Level-0 process into its main sub-processes (Level 1) and then their sub-sub-processes (Level 2). Each level must balance — the inputs and outputs at the lower level must aggregate to those of the parent process at the level above.

Process Conservation Rule — A DFD rule: a process cannot create data out of nothing (no inputs but outputs — a "miracle") and cannot consume data without producing anything (inputs but no outputs — a "black hole"). Every process must have at least one labelled input and one labelled output.

ER (Entity-Relationship) Model — A data-modelling notation introduced by Peter Chen in 1976 that captures the data the system stores. Three core elements: entity (a thing the system tracks — Member, Book), relationship (an association between entities — Member-borrows-Book), and attribute (a property of an entity — name, ISBN).

Cardinality — In an ER model, the number constraint on how many instances of one entity can be associated with how many of another. The three classical cardinalities are 1:1 (one-to-one — a Member has one Membership Card), 1:N (one-to-many — a Branch has many Members), and M:N (many-to-many — Members borrow Books over time).

Primary Key (PK) — In an ER model and the relational schema that follows, the attribute (or set of attributes) that uniquely identifies each instance of an entity — Member ID, ISBN, Loan ID. The PK becomes the unique identifier in the corresponding database table.

Foreign Key (FK) — In the relational schema generated from an ER model, an attribute in one table that references the primary key of another — implementing the relationship. E.g., a Loan record carries the Member ID and the Book ISBN as FKs.

UML (Unified Modeling Language) — A standardised graphical modelling language for object-oriented software, defined by Grady Booch, James Rumbaugh, and Ivar Jacobson (the "Three Amigos") at Rational Software in the mid-1990s and standardised by the OMG in 1997. UML 2.x defines 14 diagram types divided into structural and behavioural families.

Structural UML Diagrams — The seven UML diagrams that capture what the system is: Class diagram (classes, attributes, operations, relationships — the most-used), Object diagram (an instance snapshot), Component diagram (software components and their interfaces), Composite Structure, Deployment diagram (hardware nodes), Package diagram (grouping), and Profile diagram (custom extensions).

Behavioural UML Diagrams — The seven UML diagrams that capture what the system does: Use Case diagram (actor-level functionality), Activity diagram (workflows), State Machine diagram (object states and transitions), Sequence diagram (time-ordered messages between objects — the most-used after Class), Communication diagram (object interactions, network-style), Timing diagram, and Interaction Overview diagram.

Use Case Diagram — A UML diagram showing actors (users or external systems) and the use cases (units of system functionality) they participate in, with the system boundary drawn as a rectangle enclosing the use cases. Use case diagrams sit at the boundary between requirements and design.

Class Diagram — The most-used UML diagram, showing classes (rectangles split into name, attributes, operations) and the relationships between them — association, aggregation, composition, inheritance, dependency. The class diagram is the design's structural backbone.

Sequence Diagram — A UML diagram showing objects on a horizontal axis and time on a vertical axis, with arrows representing messages between objects. Sequence diagrams visualise the time-ordered interaction for a specific scenario — they make race conditions, ordering bugs, and missing message paths obvious.

Activity Diagram — A UML diagram showing the flow of activities through a process, with branches, parallel flows, and synchronisation. Similar in spirit to a flowchart but with first-class support for swimlanes (who does what) and parallel forks/joins.

State Machine Diagram — A UML diagram showing the states of an object and the events that trigger transitions between them. Essential for objects with complex lifecycles — an Order goes through Created → Paid → Packed → Shipped → Delivered, each transition guarded by an event.

Association vs Aggregation vs Composition — Three UML relationship types of increasing strength. Association is a generic "knows-about" link (Customer ↔ Address). Aggregation is a "has-a, but can exist independently" relationship (Department aggregates Employees — the employee survives the department). Composition is "has-a, life-tied" (Book composes Chapters — chapters do not exist without the book).

Multiplicity (UML) — The UML notation for cardinality on an association — 1, 0..1, (zero or more), 1.. (one or more), m..n. Mirrors ER cardinality with sharper notation.

Stereotype (<<...>>) — A UML extension mechanism that lets the modeller add custom classification to standard elements — e.g., <<interface>>, <<entity>>, <<service>>. Stereotypes let UML adapt to domain-specific vocabulary without inventing new symbols.

PlantUML / Enterprise Architect / StarUML — Modern UML tooling. PlantUML is text-based, generates diagrams from a tiny language, and integrates well with Markdown documentation. Enterprise Architect (Sparx Systems) is the dominant commercial heavyweight. StarUML is the most widely used open-source GUI modeller.

---

Study deep

1. Why three model families? Each captures a different aspect of the same system. DFD shows the functions; ER shows the data; UML class/sequence shows the objects and behaviour. A complete design usually has at least one model from each family.

1. The SRS is a living document. Even though IEEE 830 calls it a "specification," it must evolve. Each revision is version-controlled (SRS v1.0, v1.1, etc.) and changes go through a Change Control Board.

1. DFD has fallen out of fashion in OO projects. Most modern projects skip DFD and go straight to UML use case + sequence diagrams. DFD remains popular in business analysis (where the business analyst is not a programmer) and in regulated environments where it is mandated.

1. UML can be overkill. Many Agile teams use only use case and class diagrams — and even those are often informal sketches on a whiteboard. The IPU syllabus expects formal UML; industry uses it pragmatically.

1. The "model and code" duality. Tools like Enterprise Architect, StarUML and PlantUML can generate code skeletons from UML class diagrams. The reverse — reverse engineer code into UML — is also possible and is a Unit III topic (reverse engineering).

PYQ pattern (very common): "Draw a Level-1 DFD for a hospital management system / college admission system / online shopping site." — Identify external entities (Patient, Doctor, Receptionist), 4–6 main processes, and data stores. Show clearly labelled data flows.

PYQ pattern: "Write the structure of an SRS as per IEEE 830." — Use the section list above; mark Section 3 (Functional Requirements) and Section 5 (Non-Functional Requirements) as the most important sections.