The ₹52 Lakh Lesson
A logistics company in Mumbai commissioned a custom transport management system. Budget: ₹52 lakhs. Timeline: 8 months. The development team was competent. The project manager was experienced. The technology choices were sound.
At month 6, the client reviewed the system for the first time. The reaction was immediate: "This isn't what we asked for." The dispatch module worked differently from how dispatchers actually worked. The driver app didn't support the offline scenarios that were common on highway routes. The reporting module showed the metrics the client had mentioned in the initial meeting - not the metrics they actually needed to run the business.
The development team had built exactly what was specified. The specification was wrong.
The project required 4 months of rework. Final cost: ₹78 lakhs. Final timeline: 14 months. The client relationship was damaged. The development team was demoralised.
This story repeats itself constantly in the Indian software industry. The cause is almost always the same: requirements were captured too quickly, validated too superficially, and managed too loosely.
The Requirements Problem Is an Engineering Problem
Most people treat requirements gathering as a soft skill - a matter of asking the right questions and listening carefully. It is that, but it's also an engineering discipline with specific techniques, tools, and quality criteria.
Requirements engineering is the systematic process of:
- 1Eliciting requirements from stakeholders
- 2Analysing requirements for completeness, consistency, and feasibility
- 3Specifying requirements in a form that can be validated and implemented
- 4Validating requirements with stakeholders before development begins
- 5Managing requirements as they change during development
Most projects do step 1 (imperfectly) and skip steps 2–5. The result is the ₹52 lakh lesson.
Step 1: Elicitation - Going Beyond What Stakeholders Say
The fundamental challenge of requirements elicitation is that stakeholders often don't know what they want until they see what they don't want. They describe their current process (which may be broken) rather than the outcome they need. They focus on features rather than problems.
The five elicitation techniques that work:
1. Process observation: Don't just interview stakeholders - watch them work. Spend a day with the dispatcher, the warehouse manager, the accounts team. You'll discover requirements that nobody would have thought to mention in an interview. The dispatcher who has 3 browser tabs open simultaneously because the current system doesn't show all the information on one screen - that's a requirement. The accounts manager who exports data to Excel every morning to do calculations the system can't do - that's a requirement.
2. User story mapping: Map the user's journey through the system from left to right (the sequence of activities) and top to bottom (the priority of features within each activity). This creates a visual representation of the entire system that stakeholders can review and correct. It makes gaps and inconsistencies visible.
3. Scenario walkthroughs: Walk through specific scenarios with stakeholders. "It's Monday morning. A customer calls to change a delivery address for an order that's already been dispatched. Walk me through exactly what you would do in the new system." Scenarios reveal edge cases and exception handling requirements that abstract descriptions miss.
4. Prototype review: Build a low-fidelity prototype (wireframes, not working software) of the key screens and workflows. Show it to stakeholders. Their reactions to the prototype will reveal requirements that no amount of interviewing would have uncovered. "That's not how we think about it" is a requirement.
5. Competitive analysis: If the client has used other software for similar purposes, understand what they liked and disliked. If competitors use specific software, understand why. This provides a baseline of expected functionality.
Step 2: Analysis - Finding the Problems Before Development Does
Once requirements are elicited, they need to be analysed for quality. A requirement that passes analysis is:
Complete: It specifies all the conditions under which the system must behave in a certain way. "The system shall send a notification when an order is delayed" is incomplete. "The system shall send an email notification to the customer and an in-app notification to the assigned agent when an order's estimated delivery time exceeds the committed delivery time by more than 2 hours" is complete.
Consistent: It doesn't contradict other requirements. "The system shall allow any user to view all orders" contradicts "The system shall restrict order visibility to the assigned agent's territory." Contradictions must be resolved before development.
Unambiguous: It has only one possible interpretation. "The system shall be fast" is ambiguous. "The system shall load the order list page in under 2 seconds for up to 10,000 orders" is unambiguous.
Testable: It can be verified by a specific test. "The system shall be user-friendly" is not testable. "A new user with no training shall be able to create and submit an order within 5 minutes" is testable.
Feasible: It can be implemented within the project's technical and budget constraints. Requirements that require real-time data from a government system that doesn't have an API are not feasible.
The requirements review checklist: For every requirement, check:
- •[ ] Is it complete? (All conditions specified)
- •[ ] Is it consistent with other requirements?
- •[ ] Is it unambiguous? (One interpretation only)
- •[ ] Is it testable? (Can be verified by a specific test)
- •[ ] Is it feasible? (Can be implemented within constraints)
- •[ ] Is it necessary? (Would the system fail without it?)
Requirements that fail this checklist must be revised before development begins.
Step 3: Specification - Writing Requirements That Developers Can Build
The format of requirements matters. Requirements written as prose paragraphs are hard to track, hard to test, and easy to misinterpret. The industry standard is user stories with acceptance criteria.
User story format:
As a [role], I want to [action] so that [benefit].Example: "As a dispatcher, I want to reassign a delivery to a different driver after dispatch so that I can respond to driver unavailability without cancelling the delivery."
Acceptance criteria format (Given-When-Then):
Given [precondition]
When [action]
Then [expected outcome]Example:
Given a delivery has been dispatched to Driver A
And Driver A has reported unavailability
When the dispatcher selects "Reassign" and chooses Driver B
Then the delivery is assigned to Driver B
And Driver A receives a notification that the delivery has been reassigned
And Driver B receives a notification with the delivery details
And the delivery status remains "Dispatched" (not reset to "Pending")
And the reassignment is logged in the delivery audit trailAcceptance criteria written in this format are:
- •Unambiguous (the developer knows exactly what to build)
- •Testable (the QA engineer knows exactly what to test)
- •Complete (edge cases are specified)
Step 4: Validation - Getting Stakeholder Sign-Off That Actually Means Something
Most projects get stakeholder sign-off on a requirements document that stakeholders haven't actually read. The sign-off is a formality, not a validation.
Real validation requires stakeholders to engage with the requirements in a way that reveals misunderstandings:
Prototype walkthrough: Walk stakeholders through a clickable prototype of the system. For each screen, ask: "Is this what you expected? What's missing? What's wrong?" Document every piece of feedback.
Acceptance criteria review: Walk through the acceptance criteria for the 10 most critical user stories with the stakeholders who will use those features. Ask them to confirm that the acceptance criteria correctly describe what they need. This is tedious but essential.
Edge case workshop: Gather stakeholders and walk through edge cases. "What happens if a customer places an order but the payment fails? What happens if a driver marks a delivery as complete but the customer says they didn't receive it? What happens if the system is offline when a driver tries to update a delivery status?" Edge cases reveal requirements that normal-path thinking misses.
Sign-off with understanding: Before sign-off, ask each stakeholder to summarise in their own words what the system will do. If their summary doesn't match the requirements, there's a misunderstanding that needs to be resolved.
Step 5: Managing Requirements Change
Requirements will change during development. This is not a failure - it's inevitable. The question is whether changes are managed or unmanaged.
Unmanaged change (scope creep): The client mentions a new feature in a meeting. The developer adds it without a formal change request. The project timeline slips. The budget is exceeded. Nobody knows why.
Managed change: Every change request goes through a formal process:
- 1Change is documented (what is being changed, why, who requested it)
- 2Impact is assessed (how many days of development, what is the cost, what is the risk)
- 3Change is approved or rejected by the project sponsor
- 4If approved, the requirements document is updated and the timeline/budget is adjusted
The change request template:
Change Request #[number]
Requested by: [name]
Date: [date]
Description: [what is being changed]
Reason: [why the change is needed]
Impact assessment:
- Development effort: [days]
- Cost: [₹]
- Timeline impact: [days]
- Risk: [low/medium/high]
Decision: [approved/rejected]
Approved by: [name]
Date approved: [date]A project with 20 change requests that are all formally managed is healthier than a project with 5 change requests that are informally absorbed into the scope.
The Requirements Quality Metrics
Track these metrics throughout the project:
- •Requirements stability: Percentage of requirements that haven't changed since baseline. Target: 80%+ at development start.
- •Defect origin: Percentage of defects traced back to requirements issues vs. development issues. Target: < 20% requirements-origin defects.
- •Acceptance criteria coverage: Percentage of user stories with complete acceptance criteria. Target: 100% before development starts.
- •Change request volume: Number of formal change requests per sprint. Rising volume indicates requirements were not well-captured initially.
- •Rework rate: Percentage of development work that had to be redone due to requirements changes. Target: < 10%.
The Investment That Pays for Itself
Proper requirements engineering adds 15–20% to the upfront project cost. It typically saves 30–50% of the total project cost by preventing rework.
For a ₹50 lakh project:
- •Requirements engineering investment: ₹7–10 lakhs
- •Rework prevented: ₹15–25 lakhs
- •Net saving: ₹8–15 lakhs
The ₹52 lakh project that became a ₹78 lakh project could have been a ₹60 lakh project with proper requirements engineering. The extra ₹8 lakhs spent on requirements would have saved ₹26 lakhs in rework.
See how IdeaSprout approaches requirements engineering for custom software →