4. Requirement Engineering Process

CSS Optional — Paper-II, Section-B · P-II.VI.4 · Syllabus: Elicitation and negotiation, Documentation, Validation and verification, Management. CSS 2019 (role of validation) and CSS 2020 (role of V&V in RE, 6 marks) — model answer in section 5.

1. The Process at a Glance

graph LR
    E["Elicitation and negotiation"] --> D["Documentation (SRS)"]
    D --> V["Validation and verification"]
    V -->|"issues found"| E
    V --> S["Sign-off / baseline"]
    S --> M["Management: change control, traceability"]
    M -->|"change request"| E

RE is iterative, especially for web projects — requirements are refined across releases.

2. Elicitation and Negotiation

Elicitation = discovering requirements from stakeholders and other sources.

Negotiation = resolving conflicts and prioritizing.

• Conflict example: marketing wants auto-playing video banners; the performance requirement says ≤ 2 s load — negotiate (e.g. lazy-loaded video, click-to-play).
• EasyWinWin / WinWin (Boehm): stakeholders state win conditions; conflicts are raised as issues; options are proposed; agreements are reached so every party wins something.
• Prioritization: MoSCoW (Must, Should, Could, Won't-this-time), cost-value analysis, AHP (pairwise comparison).

3. Documentation

• Output: the Software Requirements Specification (SRS) — IEEE 830 / ISO/IEC/IEEE 29148.
• Typical SRS outline: 1. Introduction (purpose, scope, definitions, references, overview) · 2. Overall description (product perspective, functions, user classes, constraints, assumptions) · 3. Specific requirements (functional, external interfaces, performance, security, other NFRs) · Appendices.
• Levels of formality: stories/natural language → itemized requirements → formatted templates (use-case templates) → formal specifications (e.g. Z). Web projects mostly use itemized requirements, use cases and user stories.

Use-case template example — "Place Order"

User story format: "As a returning customer, I want to save my address so that checkout is faster." Acceptance criteria: Given I am logged in, when I tick "save address", then it pre-fills on my next order.

4. Validation and Verification (definitions)

5. Model Answer — Role of V&V in Requirement Engineering (CSS 2019, 2020)

1. Catches errors at the cheapest point — a requirement defect found during RE costs far less than one found after deployment.
2. Ensures completeness — reviews expose missing requirements (e.g. no "forgot password" flow).
3. Ensures consistency — detects conflicts (e.g. "guest checkout allowed" vs "all orders require login").
4. Ensures verifiability — vague NFRs ("fast") are rewritten as measurable targets so they can be tested.
5. Confirms real needs (validation) — prototypes and walkthroughs show users what they will get before it is built.
6. Checks feasibility and realism within budget, technology and deadline.
7. Produces a signed-off baseline — the agreed SRS against which design, testing and acceptance are measured.

Techniques to name: requirements reviews/inspections, prototyping, test-case generation (writing a test for each requirement exposes vague ones), checklists, model validation, traceability checks.

6. Requirements Management

• Change management: change request → impact analysis (cost, schedule, affected components) → change control board decision → update SRS and baseline version.
• Traceability: link each requirement backwards to its source and forwards to design, code and test cases.
• Versioning and baselines: numbered SRS versions; signed-off baseline.
• Status tracking: proposed → approved → implemented → verified.
• Tools: Jira, Azure DevOps, IBM DOORS, spreadsheets for small projects.

Traceability matrix example

---

🎯 CSS Exam Angle

Draw the process cycle first. For "role of V&V", give the definition table then the 7 numbered roles. For elicitation, pick 4–5 techniques with pros/cons and point out web-specific ones (online surveys, analytics, card sorting). Mention sign-off and traceability — they show depth.

📌 Past CSS Paper Frequency

⚠️ MCQ Traps

• Verification = product right; validation = right product.
• A correct-looking requirement that the client never wanted is a validation failure.
• MoSCoW's "W" is Won't have this time, not "Wish".
• Traceability runs both backward (to source) and forward (to design/tests).
• Sign-off comes after validation and before design.

---

✅ Self-Check (with Answers)

Q1. List the four RE process activities named in the syllabus.

Ans: Elicitation and negotiation; documentation; validation and verification; management.

Q2. Which elicitation technique would you choose for a new mobile-banking web app with 2 million existing customers, and why?

Ans: Online questionnaires/surveys (reach many remote users cheaply), backed by analytics of the existing site and prototyping for the new interface; plus interviews with key bank stakeholders.

Q3. Marketing wants every page to show a large autoplay video; IT requires 2-second load time. How is this resolved?

Ans: Through negotiation: both are recorded as win conditions; options such as a compressed poster image with click-to-play or lazy-loaded video are evaluated; the agreed option is documented and prioritized (e.g. MoSCoW).

Q4. Give two verification and two validation techniques for requirements.

Ans: Verification — inspections/reviews against a checklist; consistency and completeness analysis. Validation — prototyping with users; acceptance-test walkthroughs/demos with the client.

Q5. What is a requirements traceability matrix and why is it useful?

Ans: A table linking each requirement to its source, design elements and test cases. It shows the impact of a change, proves every requirement is tested, and reveals untraced (gold-plated) features.

Q6. Write a user story with acceptance criteria for password reset.

Ans: "As a registered user, I want to reset my password by email so that I can regain access if I forget it." Acceptance: given a registered email, when I request a reset, then a single-use link valid for 30 minutes is emailed; the old password stops working after reset.

📜 Past-Paper Questions & MCQs (CSS 2016–2026)

2019 · Paper-II · Q7(b) and 2020 · Paper-II · Q8(b) · 6 marks each

Q. Describe briefly the role of validation and verification in the requirements engineering process.

Ans.

• Validation: checks that the requirements describe what the stakeholders really need ("are we specifying the right system?"). Techniques: stakeholder reviews and walkthroughs, prototypes and mock-ups, scenario checks, and writing acceptance test cases from the requirements.
• Verification: checks that the requirements document is correct, complete, consistent, unambiguous and testable, and follows standards ("is the specification built right?"). Techniques: inspections, checklists, consistency analysis and traceability matrices.
• Role in the RE process:
  • finds errors early, when fixing costs the least (a requirements error costs many times more to fix after release)
  • builds a shared understanding between users and developers
  • gives an approved, baselined requirements document (sign-off) as the basis for design and testing
  • reduces rework and project risk
• For web applications: also validate usability, content and navigation with prototypes, and check performance and security requirements for measurability.