Requirements engineering and UML

In short

Requirements engineering (RE) is the disciplined process of discovering, analysing, documenting, validating and managing what a software system must do and how well it must do it, before and while it is built. UML (Unified Modeling Language, OMG standard, current version 2.5.1) is the notation used to model those requirements and the design that follows — 14 diagram types split into structural and behavioural. The pairing matters because most Indian IT service work (TCS, Infosys, Wipro, HCLTech, Cognizant, Accenture, Capgemini, LTIMindtree) is contracted on a BRD/FRD/SRS and reviewed against CMMI or ISO 9001 process audits, and a requirement defect that escapes to production costs orders of magnitude more to fix. Software engineering is no longer in the GATE CSE syllabus, but this topic carries heavy weight in university end-semester papers, UGC-NET Computer Science Paper 2, ISRO/BARC/DRDO scientist exams, NIELIT and PSU papers, and UML diagrams are asked in almost every fresher and business-analyst interview round.

Explained

What a requirement is, and the kinds of requirements

• A requirement is a condition or capability needed by a user to solve a problem, or that a system must meet to satisfy a contract, standard or specification (IEEE definition).
• Functional requirements (FR): what the system does — inputs, processing, outputs, behaviour. "The system shall generate a GST-compliant invoice within 2 s of order confirmation."
• Non-functional requirements (NFR) / quality attributes: how well it does it — performance, availability, security, usability, maintainability, portability, scalability, compliance, localisation, accessibility. NFRs are architecturally significant and are the most commonly under-specified part of an SRS.
• Domain requirements: come from the application domain, not the user — e.g. an NPCI UPI transaction must carry a unique RRN; a bank's interest calculation must follow RBI's daily-product method.
• Classification by audience: *user requirements* (natural language + diagrams, for the customer), *system requirements* (detailed, structured, for developers), *business requirements* (the "why", in a BRD).
• FURPS+ classification: Functionality, Usability, Reliability, Performance, Supportability, plus design/implementation/interface/physical constraints.
• ISO/IEC 25010 gives the standard product-quality model used to name NFRs (functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability); the 2023 revision reworks the characteristics and adds safety, so quote whichever edition your syllabus lists.
• Constraints (technology stack, budget, deadline, regulation) are not requirements but bound the solution space.

The RE process — five activities

1. Feasibility study: is it technically, operationally, economically and legally possible? Output: a short feasibility report that may kill the project.
2. Elicitation (gathering): interviews (structured/unstructured), questionnaires, workshops and JAD (joint application development), brainstorming, FAST (facilitated application specification technique), observation/ethnography, document and interface analysis, prototyping (throwaway vs evolutionary), QFD (quality function deployment — classifies as normal, expected and exciting requirements), scenarios and use cases, viewpoint-oriented elicitation, competitor benchmarking.
3. Analysis and negotiation: classify, check for conflicts, overlaps, ambiguity, infeasibility; resolve stakeholder conflicts; prioritise; build models (use case, class, DFD, state machine); produce a data dictionary.
4. Specification: write the SRS — the baselined contract between customer and developer.
5. Validation and verification: confirm the SRS describes the *right* system — formal reviews and Fagan inspections, walkthroughs, checklists, prototype demonstration, model validation, writing acceptance test cases from each requirement, and (rarely, in safety work) formal methods such as Z or VDM.
6. Requirements management runs across the whole life cycle: baselining, version control, a Change Control Board (CCB), impact analysis, and traceability.
7. Traceability is *forward* (requirement → design → code → test), *backward* (test or code → requirement, to detect gold plating) and *bidirectional*; captured in a Requirements Traceability Matrix (RTM). CMMI and regulated audits insist on it.
8. Classic elicitation problems: stakeholders don't know what they want, tacit knowledge, conflicting views, shifting priorities (requirements volatility), scope creep (uncontrolled growth) and gold plating (developers adding unasked features).

The SRS: standards, quality criteria, prioritisation

• IEEE 830-1998 is the outline universities still examine, though it was withdrawn and replaced by ISO/IEC/IEEE 29148 (current edition 2018), which merges requirements processes for systems and software.
• IEEE 830 outline: 1. Introduction (purpose, scope, definitions, references, overview) · 2. Overall description (product perspective, product functions, user characteristics, constraints, assumptions and dependencies) · 3. Specific requirements (external interfaces, functional requirements, performance, logical database, design constraints, software system attributes) · appendices and index.
• Characteristics of a good SRS (IEEE 830): correct, unambiguous, complete, consistent, ranked for importance and stability, verifiable, modifiable, traceable.
• 29148 adds per-requirement characteristics: necessary, appropriate, unambiguous, complete, singular (one requirement per statement), feasible, verifiable, correct, conforming (the 2011 edition also listed implementation-free — says *what*, not *how*); and set-level: complete, consistent, feasible, comprehensible, able to be validated (2011 edition: complete, consistent, affordable, bounded).
• Write it testable. "The system shall be fast" is unverifiable; "95th-percentile response time ≤ 1.5 s at 500 concurrent users" is verifiable. Use "shall" for mandatory, "should" for desirable, "may" for optional.
• Prioritisation techniques: MoSCoW (Must / Should / Could / Won't-this-time), Kano model (must-be, one-dimensional, attractive/delighter, indifferent, reverse), 100-dollar (cumulative voting), AHP pairwise comparison, and simple value-vs-cost ranking.

UML: what it is and the 14 diagrams

• UML is a *notation*, not a method — standardised by the Object Management Group (OMG); UML 2.5.1 (2017) is the current specification. It is language-independent and is used with any process (RUP, Agile, waterfall).
• Structural (7): class, object, component, deployment, package, composite structure, profile.
• Behavioural (7): use case, activity, state machine, and four interaction diagrams — sequence, communication, interaction overview, timing.
• Extension mechanisms: stereotypes («interface», «entity», «boundary», «control»), tagged values, constraints and OCL (Object Constraint Language) for invariants, pre- and post-conditions.
• 4+1 view model (Kruchten) maps them: logical (class), process (activity, sequence), development (component, package), physical (deployment), scenarios (use case) — the "+1" view ties the other four together.
• In the 4+1 / RUP flow, use cases drive analysis classes (boundary–control–entity), then design classes, then code.

Structural diagrams in detail

• Class diagram — the most examined diagram. A class box has three compartments: name / attributes / operations. Visibility: + public, - private, # protected, ~ package. Attribute syntax - balance : Decimal = 0; static members underlined; abstract class and abstract operation names in *italics*.
• Multiplicity: 1, 0..1, * or 0..*, 1..*, 2..5. Always put it on both ends of an association.
• Relationships: *association* (plain line, optional role names and navigability arrow) · *aggregation* (hollow diamond, "has-a", shared, parts survive the whole) · *composition* (filled diamond, strong ownership, parts die with the whole) · *generalisation* (solid line, hollow triangle, "is-a") · *realisation* (dashed line, hollow triangle, class implements interface) · *dependency* (dashed arrow, "uses") · *association class* (attributes belonging to the link itself, e.g. Enrolment between Student and Course).
• Object diagram: a snapshot of instances (b1 : Book) with actual attribute values at one moment — used to validate a class diagram.
• Package diagram: groups classes into namespaces; shows «import» and «access» dependencies; used to show layering.
• Component diagram: replaceable parts with provided interfaces (ball) and required interfaces (socket), joined through ports — logical build-time structure.
• Deployment diagram: physical nodes (devices, execution environments) with artifacts (.war, .jar, container images) deployed on them, joined by communication paths (HTTPS, TCP) — the diagram to draw when asked "how will it be hosted?"
• Composite structure: internals of a class as parts, ports and connectors. Profile: defines domain-specific stereotype sets.

Behavioural diagrams in detail

• Use case diagram: actors (stick figures — primary initiate, secondary support, and non-human actors like a payment gateway), use cases (ellipses), the system boundary rectangle, and relationships: *association* (actor–use case), «include» (mandatory, always-executed common behaviour, e.g. Place Order includes Validate OTP), «extend» (optional/conditional behaviour at a named *extension point*, e.g. Apply Coupon extends Place Order), and *generalisation* of actors or use cases. Arrow direction: «include» points from base to included; «extend» points from the extending use case to the base.
• A use case diagram shows *scope*, not logic. The logic lives in the use case specification: name, actors, preconditions, postconditions, main success scenario (numbered steps), alternate flows, exception flows, business rules, frequency.
• Sequence diagram: time flows downward. Lifelines (dashed), execution/activation bars, messages — synchronous (solid line, filled arrowhead), asynchronous (solid line, open arrowhead), reply (dashed arrow), self-message (loop back), object creation (arrow to the box) and destruction (X). Combined fragments: alt (if-else), opt (if), loop, par (parallel), break, critical, neg, ref (reference to another diagram); guards in [ ].
• Communication (collaboration) diagram: same information as a sequence diagram but organised around object links with numbered messages (1, 1.1, 1.2) — better for showing structure, worse for showing time ordering. The two are semantically equivalent and inter-convertible.
• Activity diagram: workflow — initial node (filled circle), actions (rounded rectangles), decision and merge (diamonds, guarded branches), fork and join (thick bars, concurrency), object nodes, signals, swimlanes/partitions (who does what), activity final (bull's-eye) and flow final. Use it for business processes and complex algorithms.
• State machine (statechart) diagram: states of ONE object over its lifetime. State box can hold entry / action, do / activity, exit / action. Transition label: event [guard] / action. Supports composite (nested) states, orthogonal regions for concurrency, and history pseudostates (H shallow, H* deep). Example: an Order moving Created → Paid → Packed → Shipped → Delivered / Cancelled.
• Interaction overview (activity diagram whose nodes are interactions) and timing (state against an explicit time axis — real-time and embedded work).

Requirements in current Indian practice

• Agile form: a user story — "As a <role>, I want <goal>, so that <benefit>" — with acceptance criteria, often in Gherkin (Given / When / Then). Judge stories by INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. Epics decompose into features, then stories, then tasks; the product backlog replaces a frozen SRS, but the Definition of Ready / Definition of Done and the NFRs still have to be written down.
• Fixed-bid Indian service contracts still need a signed, baselined SRS/FRD because the change request and billing mechanism hangs off it; T&M and Agile engagements use a backlog plus a lightweight NFR document.
• Regulatory sources of NFRs in India (these turn up directly as requirements): the Digital Personal Data Protection Act, 2023 (consent, purpose limitation, data-principal rights, breach notification — the implementing Rules are being phased in, so confirm the current status before quoting dates); CERT-In directions of April 2022 (report specified cyber incidents within 6 hours, retain logs 180 days within India); RBI's 2018 payment-data localisation circular; RBI/SEBI/IRDAI sectoral circulars; GST and e-invoicing rules; UIDAI/Aadhaar authentication and masking norms; accessibility under the RPwD Act, 2016 with GIGW 3.0 and WCAG 2.1 for government-facing sites; multilingual support across the 22 scheduled languages.
• Tools: Jira and Confluence, Azure DevOps, IBM Engineering Requirements Management DOORS (aerospace and defence — HAL, DRDO, ISRO suppliers), Polarion, Jama, HP ALM; modelling in Enterprise Architect, StarUML, Visual Paradigm, Lucidchart, draw.io and PlantUML (text-based, diffable in Git).
• Roles that live on this topic: business analyst, systems analyst, product owner, presales/solution consultant, QA lead (writes tests from requirements), architect.

Key points

• Requirements engineering - eliciting, analysing, specifying, validating and managing what the system must do; the cheapest place to fix a defect.
• Functional vs non-functional - what the system does vs how well; NFRs drive architecture and are most often missed.
• Domain requirement - imposed by the application domain, not asked for by any user.
• SRS - the baselined agreement; IEEE 830 outline, now formally superseded by ISO/IEC/IEEE 29148:2018.
• Good requirement - correct, unambiguous, complete, consistent, ranked, verifiable, modifiable, traceable, singular, implementation-free.
• Elicitation techniques - interviews, questionnaires, JAD/FAST workshops, prototyping, observation, document analysis, QFD, scenarios.
• Validation vs verification - "are we building the right product?" vs "are we building the product right?"
• Traceability matrix (RTM) - bidirectional links requirement ↔ design ↔ code ↔ test; detects both gaps and gold plating.
• Scope creep vs gold plating - uncontrolled customer-side growth vs unrequested developer-side extras.
• MoSCoW / Kano / 100-point / AHP - the four prioritisation methods examined.
• UML 2.5.1 - 14 diagrams, 7 structural + 7 behavioural, an OMG notation independent of any process.
• Aggregation vs composition - hollow diamond, shared, parts survive; filled diamond, owned, parts destroyed with the whole.
• Generalisation vs realisation - solid line + hollow triangle (inheritance) vs dashed line + hollow triangle (implements an interface).
• «include» vs «extend» - always-executed mandatory sub-behaviour vs optional behaviour triggered at an extension point.
• Sequence vs communication diagram - same content; time-ordered vertical layout vs structure with numbered messages.
• Activity vs state machine - flow of work across objects vs lifecycle of a single object driven by events.
• Deployment diagram - nodes, artifacts and communication paths; the "how is it hosted" answer.
• User story + INVEST + acceptance criteria - the Agile unit of requirement; it supplements, not abolishes, written NFRs.

Formulas and examples

Example 1 — sizing a campus placement portal with Use Case Points. Actors: 2 simple (payment API, SMS gateway) → 2×1 = 2; 3 average (bulk-upload text interface, college ERP feed, email service) → 3×2 = 6; 1 complex (student GUI) → 1×3 = 3. UAW = 11. Use cases: 6 simple → 6×5 = 30; 4 average → 4×10 = 40; 2 complex → 2×15 = 30. UUCW = 100. So UUCP = 111. Technical factors sum to 30 → TCF = 0.6 + 0.01×30 = 0.90. Environmental factors sum to 20 → ECF = 1.4 − 0.03×20 = 0.80. UCP = 111 × 0.90 × 0.80 = 79.9. Effort = 79.9 × 20 ≈ 1,598 person-hours ≈ 10 person-months at 160 h/month. At an internal cost of ₹900/hour, ≈ ₹14.4 lakh.

Example 2 — MoSCoW budget split on the same project. The common DSDM guideline caps Must-haves at about 60% of effort, Should at 20%, Could at 20% (the contingency that gets dropped first). Must ≤ 0.60 × 1,598 ≈ 959 h · Should ≈ 320 h · Could ≈ 320 h. If elicitation produced 1,150 h of Must-have work, the project is already over-committed at baseline and scope must be renegotiated before coding starts.

Example 3 — volatility and stability. Baseline: 240 requirements. Over three sprints: 18 added, 6 deleted, 24 modified → changes = 48. RV = 48/240 × 100 = 20% → RSI = 80%. A 20% volatility in one quarter on a fixed-bid contract is high; each change should have a costed CR. If 222 of the 240 requirements trace to at least one test case, traceability coverage = 222/240 = 92.5%, leaving 18 untested requirements to close.

Example 4 — why requirement reviews pay. A review of those 240 requirements finds 36 defects; 9 more escape and surface in UAT. Requirement defect density = 36 / (240/100) = 15 defects per 100 requirements. Phase DRE = 36/(36+9) × 100 = 80%. Cost: fixing at review ₹2,500 each → 36 × 2,500 = ₹90,000. Had all 36 escaped to UAT at a 20× multiplier (₹50,000 each) → ₹18,00,000. Net saving ≈ ₹17.1 lakh, against a review that cost roughly 40 person-hours.

Example 5 — 100-point prioritisation. Three stakeholders each distribute 100 points over five features:

Total points = 300, and the ranking is reproducible and defensible in a steering meeting.

# PlantUML - minimal use case and class fragments
@startuml
left to right direction
actor Student
actor "Payment Gateway" as PG
rectangle "Placement Portal" {
  Student -- (Apply to Drive)
  (Apply to Drive) ..> (Validate OTP) : <<include>>
  (Apply to Drive) <.. (Pay Registration Fee) : <<extend>>
  (Pay Registration Fee) -- PG
}
@enduml

@startuml
class Student {
  - rollNo : String
  - cgpa : Decimal
  + isEligible(d : Drive) : Boolean
}
class Drive
class Application
Student "1" -- "0..*" Application
Drive   "1" -- "0..*" Application
' composition
Drive   *-- "1..*" Round
@enduml

Where it is used

• IT services and GCCs: business analysts at TCS, Infosys, Wipro, Cognizant, Accenture India and Capgemini write BRD/FRD/SRS, RTMs and UML models as contractual deliverables, audited under CMMI and ISO 9001.
• Product companies: Zoho, Freshworks, Razorpay, Zerodha, Flipkart and PhonePe run story-and-backlog RE with written NFRs for latency, uptime and PCI-DSS/RBI compliance; sequence and deployment diagrams appear in every design review document.
• Banking, insurance and fintech: regulatory requirements from RBI, SEBI, IRDAI and NPCI are elicited directly from circulars; traceability from circular clause → requirement → test evidence is what auditors ask for.
• Government and e-governance: NIC, UIDAI, GSTN and state projects specify SRS and acceptance criteria in the RFP itself, with GIGW and RPwD accessibility obligations as named requirements.
• Defence, space and automotive: HAL, DRDO, ISRO suppliers and automotive Tier-1s use DOORS-based requirements with full bidirectional traceability, plus state machine and timing diagrams for real-time behaviour.
• Exams and interviews: SRS contents, elicitation techniques, use case and class diagram drawing are standard university and UGC-NET/ISRO questions; "draw the class diagram for an ATM / library / railway reservation" is a routine fresher interview task.

Interview questions

• Q: What is the difference between functional and non-functional requirements? A: Functional requirements state what the system does (generate an invoice); non-functional requirements state how well it does it (within 2 seconds, at 99.9% availability). NFRs usually dictate the architecture.
• Q: Difference between validation and verification in requirements? A: Validation asks whether the documented requirements describe the system the stakeholders actually need; verification asks whether the built product conforms to those documented requirements.
• Q: Name the characteristics of a good SRS. A: Correct, unambiguous, complete, consistent, ranked for importance and stability, verifiable, modifiable and traceable — IEEE 830; ISO/IEC/IEEE 29148 adds singular, feasible, necessary and appropriate (implementation-free in the 2011 edition).
• Q: What is a requirements traceability matrix and why keep one? A: A table linking each requirement forward to design, code and test cases and backward from artefacts to requirements; it proves coverage, supports impact analysis for changes, and exposes gold-plated code that no requirement asked for.
• Q: Difference between «include» and «extend» in a use case diagram? A: «include» is mandatory common behaviour the base use case always invokes; «extend» is optional behaviour inserted at a defined extension point only when its condition holds. The arrow points from base to included, but from the extending use case to the base.
• Q: Aggregation or composition — how do you choose? A: Ask whether the part can exist independently of the whole. A Player survives the Team being deleted, so that is aggregation (hollow diamond); an OrderLine is meaningless without its Order, so that is composition (filled diamond).
• Q: When would you draw an activity diagram rather than a state machine diagram? A: An activity diagram when modelling a workflow or algorithm with concurrency across several participants; a state machine when modelling the event-driven lifecycle of one object, such as an order or a bank account.
• Q: Sequence diagram versus communication diagram? A: They carry the same information. A sequence diagram shows time explicitly down the page and is better for ordering and combined fragments; a communication diagram shows object links with numbered messages and is better for seeing structure.
• Q: How do you handle a stakeholder who keeps adding requirements mid-project? A: Baseline the agreed scope, route every new item through a change request with impact analysis on cost, schedule and risk, let the CCB or product owner decide, and track requirements volatility so the trend is visible — not refuse the change, but price it.
• Q: Scope creep versus gold plating? A: Scope creep is uncontrolled expansion driven by stakeholders slipping in work outside the baseline; gold plating is the team adding features nobody asked for. Both add untested, unbilled risk, and backward traceability catches the second.
• Q: How do requirements work in Agile if there is no SRS? A: The product backlog of user stories with acceptance criteria replaces the frozen document; the stories are elaborated just in time, but NFRs, compliance constraints and the Definition of Done are still written down and still reviewed.
• Q: Why is fixing a requirement defect in production so much more expensive? A: The error has propagated into design, code, test cases, documentation and live data, so the fix means rework across every downstream artefact plus regression testing and possibly data correction — commonly quoted as one to two orders of magnitude costlier than fixing it at review.

Common mistakes

• Writing unverifiable requirements — "user-friendly", "fast", "secure" — instead of measurable ones with a number, a unit and a condition.
• Specifying the solution instead of the need ("use a dropdown populated from Redis") and thereby fixing the design inside the SRS.
• Putting logic into a use case diagram: numbering use cases as steps, chaining them with arrows, or drawing data flows — the diagram shows scope only, the flow belongs in the specification.
• Confusing aggregation with composition, or using a dependency arrow where a realisation is meant; omitting multiplicities on associations altogether.
• Reversing the «extend» arrow, or using «include» for behaviour that is actually conditional.
• Treating a single stakeholder's view as complete — missing operations, support, audit, security and regulatory viewpoints, which is where most NFR gaps come from.
• Baselining an SRS with no prioritisation and no traceability, so every change becomes a negotiation from scratch and test coverage cannot be proved.

Related topics

SDLC and Agile · Software architecture: monoliths and microservices · Low-level design (object-oriented design) interviews · Software testing basics · Software project management and estimation · Database design and ER modelling