Updated: Jan 3
Today, we will talk about the subject of how to analyze the requirements of the customer and what are the rules for requirement analysis.
Nowadays many project managers do not take requirement management very seriously. Because most of them think project management should just focus on delivering the product rather than figuring out why they do all those functions of the product.
In reality, the project team that does not value requirement management will probably take its own consequences. Lack of requirement analysis at the early phase of the project would lead to huge risks. The success of a project means the deliverables achieved by the project can satisfy the user’s need in the aspects of both function and quality, at a reasonable price.
In the following, we will discuss the problems caused by a lack of requirement analysis.
1. Lack of customer’s engagement
Sometimes the customer does not understand why it would take the project team so long to collect all the requirements, meanwhile, the project developers may not value the customer’s engagement in the project. These are the most possible reasons: the developers feel that collaboration with customers is not as interesting as writing code, and the developers feel like they already fully understood all the customer’s requirements. But the reality is: in some scenarios, contacting the customers who actually use the product is very challenging; in some other scenarios, the customers themselves do not fully know what they really need. Nevertheless, it would still be very necessary for the development team to engage with representative customers at the beginning of the project, as well as through the entire development process.
Some senior developers or project managers have such experience: when conducting a project, if the engagement of customers is not sufficient, the requirements which project team has collected may be unilateral and incomplete, which would certainly lead to high risk for the project.
2. The continuous increase in customer’s requirements
If the requirements of customers continuously increase during the development, the project would become bigger and bigger, and eventually would exceed the planned schedule and budget. On the other hand, the original plan is not always consistent with the original requirements’ scale, complexity, risks, development’s production rate, which makes the problem more challenging. In fact, the root of the problem is the change of the customer’s requirements and developers’ modifications to the new requirements.
If we want to minimize the change range of the requirements, we must reach a consensus with the customers regarding detailed project objectives, scope, and success criteria at the very beginning, and based on that we have to develop a change management procedure of evaluating and controlling all required changes. This procedure must include an analysis of every factor affected by the requirement changes, which would make the risk owners fully understand the rationality behind every business decision. The decision basis includes why we need the changes, how long the implementation of the changes would take, and how to balance the human resources and the additional work.
If the requirement changes continuously happen during product development, the overall structure of the product would possibly become more and more disordered. In this situation, the additional defect repair would make the entire product/software difficult to be understood and maintained. Additionally, if the work of project configuration management is not thorough, the recall of some changes or removing certain requirements would cause new problems.
The solution to the problems may be for us to distinguish and separate the functions which would probably cause requirement changes during the development so that we can develop a much more robust structure for the product, and better adapt to it. In this way, the requirement changes in the design phase would not directly cause additional structural repair, meanwhile, the diminution of the product’s quality caused by requirement changes would be less.
3. Ambiguous requirements
Ambiguity can be the most horrible problem in the required documents. The ambiguity of the requirements means two things: one is that different readers have different understands when reading the requirement statements, the second is that one single reader has more than one way to interpret or decode the requirement statement.
Ambiguous requirements, on one hand, can make different risk owners have different expectations, on the other hand, can make the developers wasting time fixing the wrong problem. Furthermore, they also can make the tester’s expectations inconsistent with the developer’s expectation. A system tester once told me that the test team which she was in constantly have wrong understood the requirements, which made them have to rewrite all the test cases and redo all the tests.
The best way to deal with ambiguous requirements is to assemble different teams to review the requirements from different perspectives. Merely browsing or reading the requirement documentation would not solve the problem of ambiguity. If different reviewers can give different explanations of the requirement statements from different perspectives, and eventually every reviewer would truly understand the ambiguity of the requirement documentations. On the contrary, if this kind of review meeting was not held at the early phase of the project, the ambiguity of requirements could not be found until the late phase of the project, or even worse, never be found, then the cost of changing the requirements would be huge at that point.
4 Unnecessary functions
The phrase “gild the lily” means the developers try to add new functions that they think the customer would probably appreciate but are not really in the requirement documentations. The most possible result of this action is that the developers wasted their valuable time because the customers do not think the newly added function very useful. In conclusion, developers should not add new functions to the product without the customer’s agreement.
On the other hand, sometimes the customer may ask the developers to add some “cool” function that really lacks practical use. This kind of requirement change would bring nothing useful to the project but additional schedule and cost. Therefore, in order to minimize the harms brought by these unnecessary functions, we should make sure we all understand why the customer wants the requirements and the use method of the function.
In summary, this article introduces the importance of requirement management and requirement analysis and discusses four typical problems that may cause by the lack of requirement analysis in the project.