Select Page

Categories

Requirement Management: What Did We Do Wrong?
By Mohd Rizal Abu Bakar and Noor Jehan Mohd Nidzam

At some point of our projects; when our project is delayed, when our project is facing budget overrun, when our project is at the edge of failure; we will be asking this question to our selves, or our boss will be pushing this question to us; What did we do wrong?

META group (META Group, Inc., acquired by Gartner Inc., provides information technology research, advisory services, and strategic consulting services) is indicating that 60%-80% project failures can be attributed to poor requirement management. IAG Consulting, being more precise, indicating that 68% project failures are due to poor requirements. Wieger, 2001 study points that 50% of product defects originate in the requirements and 80% reworks can be traced back to requirement defects. So, high chances that the challenges to our projects are due to the quality of our projects’ requirements and how did we manage the requirements.

Requirements can be defined as our customer’s statement of scope or interest. It should be defining what exactly they have in mind and what exactly they expect by the end of the project. Major issue though, we are human. We always fail to understand each other and our communications are always imprecise.

Before we can understand what we did wrong, let’s see what are the activities involved in eliciting, analyzing, specifying, verifying, validating and managing requirements, which normally called as the Requirement Engineering (RE):

  • Eliciting Requirements – The very first phase in RE where requirements are elicited from various relevant stakeholders including end users, the management, customers and even the system developers. This task is normally done by the business analyst where series of meeting will be conducted together with the stakeholders in soliciting the business requirements and functional requirements. Various tools and techniques are used in elicitation process such as brainstorming session, interview, observation, questionnaires, demonstration of prototype, nominal group technique, Delphi, SCAMPER and many more. The techniques best applied depends on number of factors such as stakeholder availability and location, development team knowledge on the problem domain, customers’ and users’ knowledge on the problem domain and customers’ and users’ knowledge on the development process and method. But above all, knowing who exactly your stakeholders and knowing how to engage them is really important to ensure that you will get the real requirements.
  • Analyzing and Specifying requirements – This phase is to determine whether the requirements that have been solicited from stakeholders are clear, concise, consistent, unambiguous and complete. The requirements must be assessed, unanswered questions or contradictions may require further clarification from the stakeholders. While identifying what ‘is’ the requirement, it is also necessary to identify what ‘is-not’ the requirement. This would establish the consensus on the project scope and what is not part of the project scope.

  • Documenting requirements – Some people call this Requirement Specifications; where both functional and non-functional requirements are documented. This document can serve as a contract between the development team, the project manager and the client or customer.

  • Validating requirements – Are we building the right system or product? At this phase you have to ensure that the developed system meets the users’ needs and the requirement specifications are captured correctly. All functional requirements must be addressed and the final draft of the requirement document must be checked for conflicts, omissions and deviations from standard. Normally the validation of requirement will be done in a group where requirement will be read, then look for problems and agree on the actions to address these problems.

  • Verifying requirements – Making sure that you are delivering the desired quality (non-functional requirements) of a system to the customers. As mentioned by John Parker (2011), verification is the process of confirming that the designed and built product fully addresses documented requirements. Verification consists of performing various inspections, tests, and analyses throughout the product lifecycle to ensure that the design, iterations, and the finished product fully address the requirements.

And the overlaying activities of Managing Requirements – process of administrating the changes to the agreed requirements, its interdependencies to each other and the overall traceability of each requirement.

Now let’s look at the areas that we probably did wrongly.

  • Poor Requirement Quality – More often than not, the requirement engineers (those who are responsible to gather, analyze and manage these requirements) were not properly trained to do his/her job. They failed to perform adequate business analysis and requirements analysis. This would mean that the outputs (requirement specifications) are vague, ambiguous, unattainable, open to interpretation, arguable, irrelevant; making them impossible to build and to deliver. The project is doomed for failure from the start. Experience Requirement Engineers would be able to verify and ensure if the requirement is complete, attainable and have the appropriate characteristics of good requirements. This problem is usually compounded by inadequate access to sources of requirements and access to the right stakeholders. It would be best if all these requirements are verified with the stakeholders through inspections, in addition to the normal document review or walkthrough. During documents review, customer tends to agree to a set of requirements but only to dismiss them later during acceptance period by claiming that they were expecting or imagining different thing at the earlier phase of requirement. This will always result in nobody-win situation. A re-work would normally be required in order to move forward and this will constitute 25%-40% of the total cost of building the system (Carnegie Mellon). In some cases, the projects just got terminated as the re-work cost is just not viable.
  • Missing Market and Business Driver – What is the real problem that we are trying to resolve? If this is not clear throughout the development life-cycle, then even if a system is developed to the specifications, the real requirements or need for the systems might not be achieved. Without market and business driver, software development might be skewed more toward features and solution but not about resolving the problem. Clear visions and objectives are needed to ensure people are aligned in the same direction, toward the same destination.

  • Over used Use Case Modeling – use case modeling is a powerful technique for identifying and analyzing requirement and it has been used excessively by most of requirement engineers because it is easy to understand and provide an excellent way for communicating with customers and users. Unfortunately, use cases are best suited for analyzing functional requirement only. The non-functional requirement such as interface requirement, quality requirement, architectural, design and implementation may require other suitable techniques. This makes the non-functional requirements ambiguous, incomplete, unfeasible and misleading which definitely making it impossible for the project team to deliver. Furthermore, use cases does not state the normal and exceptional path, pre-condition, triggers, steps and post condition in which swim lane diagram will normally do. As mentioned by Donald G.F, ignoring most, if not all, of the exceptional paths leaves much of the required behavior unspecified. Finally, if the requirements do not specify what the system should do under all credible combinations of inputs and states, then the developers will end up either making incorrect assumptions or ignore possible cases, leading to systems that are unreliable, unstable, and unsafe (Donald G.F, 2007).

  • Requirement Volatility – It is expected that changes in requirement will happen in a project life-cycle. This cannot be resisted, and in a long development project, change is a must for the developed solution or product to stay current and desirable. You might want to start looking at fast iterations of requirement-development-validation. Agile approach, while not the flavor of many senior developers, might be the answer that you are looking for.
    Not enough Validation – Your customers must validate their requirement that you have put down in requirement specifications document to make sure that all requirement have been captured completely and all requirement have been specified correctly. This unfortunately have not been done adequately due probably to unavailability of the stakeholders, inadequate access to stakeholders or perhaps simply because it is not included in the plan. This will open up to a lot of assumptions and we all know where “assumptions” will lead us to… Failure! Lack of proper requirement validation with stakeholders will result in incomplete or incorrect requirements which may provide difficulties in getting acceptance from the stakeholder even if the system has been verified by the test team. Moreover, additional cost will be incurred in fixing the problem at later stage and will definitely impact the schedule.
    There are many more possible reasons or things that we did wrong in requirement management. Systems, tools, and techniques would help a lot if implemented correctly, but this must be done and managed by strong requirement engineers.

It is unfathomable that most of us did not put the rightful amount of effort and seriousness in having the right requirements. If only we manage requirement correctly and strongly, we are in the clear to be one of the 30% successful projects.

References:

[Wiegers 2001] Karl E. Wiegers, “Inspecting Requirements,” StickyMinds.com Weekly Column, 30 July 2001, http://www.stickyminds.com
[John.P, 2011] “Requirement Verification and Validation,” Business Analysis & Requirement Blog23 December 2011, http://blog.enfocussolutions.com/Powering_Requirements_Success/bid/113611/Requirements-Verification-and-Validation
[Ellis, Keith, 2008] “Business Analysis Benchmark – The Impact of Business Requirements on Success of Technology Projects”, IAG Consulting.
[Donald,G.F] “Common Requirement Problems, Their Negative Consequences and Industry Best Practices to Help Solve Them” in Journal of Object Technology, vol. 6, no. 1, January-February 2007, pp. 17-33 http://www.jot.fm/issues/issue_2007_01/column2
[Bashar, Steve] “Requirements Engineering: A Roadmap”, http://mcs.open.ac.uk/ban25/papers/sotar.re.pdf

Disclaimer:

The views and conclusions contained in this publication are solely those of the authors and not representing official policies, either expressed or implied, of MIMOS Berhad.

Mohd Rizal Abu Bakar is a Senior Manager at MIMOS Berhad. Noor Jehan Mohd Nidzam, PMP, is a Project Manager at MIMOS Berhad.

Recommended PM App

Recommended PM App

Categories