Requirements Management Process: Garbage In Garbage Out

Contributed by: M. Kashif Shahzad

Requirements elicitation, definition and management are crucial steps for on time delivery of software projects, which are in accordance with client’s requirements.  According to famous principle “Garbage In Garbage Out”, any effort on the basis of vague requirements will help you in developing an erroneous product faster. Following are the most common mistakes, project teams make in defining and managing requirements:

1.    Scope Creep: In Weeds

Scope Creep occurs when business requirements are seen as high level requirements and developer gives more attention to the detailed product features. This results in a product, which does not satisfy business requirements of the client.  I will name this syndrome, of emphasis on detailed product features, as “In Weeds”.
This leads to increase in features of the product without increase in time, budget and resources. To get out of the weeds, business objective must be studied in detail and product features should be designed in such a way to satisfy business needs. This will help in delivering product, meeting business needs in scheduled time and budget, leading to increase ROI.

2.    Requirement Elicitation from Customer: What They Want vs. What they need
According to a survey report, conducted by jama software in partnership with Revenflow from more than 203 I.T professionals:
“Some of the biggest overall problems come from pursuing what the customers say they want, without determining what they really need.”

Normally, clients don’t have a clear idea of what they want. They emphasize on product features. As a result, Developers often concentrate on product features with no idea what their client actually wants. This results in a product, which does not really satisfy the purpose for which it is developed.
Teams should identify the right stakeholders (mix of end users, business domain personnel and executive) having clear understanding of the objective and ask them what they want the product to do, only then should the designing begin, which fulfills their intended functionality.
Write clear requirements in order to avoid ambiguity. Just think as if you are writing for a student who has no idea about the product, which is to be developed. This will also help the tester to design test cases and reduce rework and associated cost (missing deadlines, budget overruns etc) which has become a practice these days.

DO’s	Don’ts
Ask open ended questions like a journalist	Think you know best what customers want
Frequent meetings with customer	Assume past experience is representative of current needs
Be open and flexible to change	Assume customer needs are static and will not change
Negotiations with customer to clarify requirements	Elicit requirements & feedback only at the start of a project
Observe the working environment of client (If feasible)	Assume customer is able to communicate his needs efficiently
Sign on requirements freeze document after customer feedback has been incorporated in the product.	Forget to capture and share the evidence you gather with your team

3. Failure to Manage the Rapid change: Architecture of the project should be flexible enough to accommodate outside influences on project requirements in the form of changing business needs, economical factors or regulations. Static variables should be avoided and product design should be prepared keeping in view future enhancements.

4. Communication Gap: Communication between stakeholders and developer plays a vital role in understanding project requirements right. Each group (end users, executives, business personnel) has his own level of understanding. Communicate with each group and present them what you have understood in such a way stakeholders clearly understand what is going to be developed. Developer can use prototype, use case narrations and visual diagrams to make stakeholders understand what will be developed.
Always respond to feedback with clear statements like “We will incorporate this feature in next release”,   “This is not possible to incorporate in the current architecture” etc.  Always keep in touch with key stakeholders during product development to avoid rework and deliver the product what client really wants.

5.    “Lesson Learned” and “Lessons Remembered”.
Management must conduct a session at the end of each product release to assess, evaluate and improve requirements management process. Metrics must be defined to measure effect of change in requirements, test case coverage and cost of the project. There should be   “Lesson Learned” session at the end of each release and “Lessons Remembered” session before the start of new project to incorporate in the requirements management process. This leads to continual process improvement leading to resolving small problems before they become large issues.

6.    Understand the relationship between requirements and deliverables: Mostly developers fail to identify and establish relationship and dependencies between high level requirements and downstream deliverables, which lead to, increased project cost and rework. When any change in requirement is introduced, its effect should be anticipated on related requirements and downstream deliverables.  Requirements traceability will help to lower project risk and align the business requirements with product requirements.

7.    Concentrate on quality not quantity: Avoid unwanted detail of requirements and traceability in analyzing documentation, because performing more work than necessary costs time and money and stakeholders avoid reviewing large documentation and giving feedbacks to developer. Always concentrate on necessary points and concentrate on quality not quantity. In this way stakeholder will be able to review the document and give positive feedback, which will be helpful in indentifying missing requirements and prioritizing tasks focusing on most important areas first.  Use of visual diagrams like use case diagrams, sequence diagrams, Process & Data flow diagrams is a better way to communicate necessary details. Place this documentation with proper versioning at a central repository accessible to all team members.

Conclusion:
Requirements management is the first step of SDLC and forms the foundation of the project. Communication gap with stakeholders, ambiguous and poor requirements and wieldy documentation result in product that fails to satisfy client’s business needs.  It often leads to rework, missed deadlines and cost overrun. It is necessary to evaluate requirements management process and make continuous improvements to deliver the product, meeting the client’s business requirements and increase ROI of the company.

About the Author:

M. Kashif Shahzad is currently working as an SQA engineer in a leading Software House of Pakistan. With 3 years of experience in Analysis, Quality Assurance, Process Engineering and Technical Writing, Kashif completed his BCS(Hons) from BZU (Bahauddin Zakaryaia University) Multan
and is now doing MBA (Management) from Virtual University.

Tagged as: Garbage In Garbage Out, SQA