Requirements management is a very important part of development process. Requirements management includes a set of measures intended to collect requirements from the customer, development plan, ranging according to the importance degree, time and cost estimation.
Requirements management process is meant to solve the following tasks:
1. Document customer’s requirements.
There is no need to repeat that all the customer’s requirements should be documented. Depending on the project size specification degree may change. The only fact remains that everything should be documented, discussed in details with the customer and confirmed by him.
2. Achieve requirements comprehension before the realization start.
This will allow reducing risks for the customer to receive something different from what he is expecting.
3. Help to define discrepancies between the requirements and results.
The better the requirements are documented the easier are the results to test. This also reduced the risk of the customer to be disappointed with the result.
4. Define the developers’ obligations.Requirements realization is connected with time and money expenses. The process of the requirements management allows controlling these parameters.
5. Set a two-way requirements tracking control.Within the development process these requirements may vary: some requirements will become more detailed, some requirements will be added, some will be excluded. These changes may influence the project deadline and the budget. That is why it is necessary for both sides to have a real image of the current requirements. Only in this case it is possible to accomplish the project successfully.
6. Manage the changes.The requirements change within the development process. We cannot resist this fact; we just have to manage this process effectively.
In this article we are going to describe the way of requirements management with the help of xPlanner (www.xplanner.org), which is to solve all the tasks mentioned above.
xPlanner is a task tracking system. In our previous articles we described in details main entities that xPlanner maintains, that is why we will only revise some main points that are necessary for the general understanding of this article. xPlanner maintains project division into iterations. Customer’s requirements placed in the xPlanner are called User Story. The task necessary for some User Story realization is called Task. Tasks set is defined by the developer. Every task has its estimation, which means the time planned for its implementation. Summary estimation on all the tasks necessary for User Story realization make estimation for this User Story.
At each particular moment there is only one iteration on which there is development in the process. This iteration is called a current iteration. In each project a fictitious Backlog iteration is created for storing all the User Stories which had not been implemented by the moment of the current iteration implementation. Actually, xPlanner was specially created for the development process based on extreme programming (XP) methodology, but it is also useful if your development process is based on any other Agile methodology, for example SCRUM methodology.
Every User Story has the attributes given below, each influencing the requirements management process:
* Priority is a number varying from 1 to 8 defining the importance degree of this requirement for the customer. 4 is a default value. This value can be understood as “normal” or “neutral”, 1 is the highest priority, 8 is the lowest priority.
* Status is the current state.
* Disposition is a means by which this User Story was added to the current iteration.
Any customer’s requirement is documented as User Story and is always stored in Backlog. You can place new requirements only in Backlog, because the current iteration is already planned and the requirements within the iteration are fixed, so any new requirements can be realized only when the current iteration is accomplished. In the Disposition field the value is set as Planned, which means that the requirement arose in the normal working conditions and is regulated by standard rules of requirements management. Standard rules here mean the rules that are described in this article.
There are two more possible values of this field, they are going to be explained at the end of this article. The Priority field shows the importance degree of a new requirement. Let’s remind that priority field equals 4 by default. The customer can change any requirement priority at any moment. It is important to note that priority change will by no means affect the current iteration and will count only while next iteration planning. There are some practical recommendations as to the User Story size, it should be such that it could be implemented within one iteration. It means that in case during estimation process we realize that the user story is too long we should divide it into smaller parts, fitting one iteration.
It is important to document any ideas that arise during the project since some of them may advantageously differ from similar products. Such ideas usually begin as follows: “it would be good for our program (website) to be able to …“, and they finish like this: “But I am not sure we really need this”. If you do not note them anywhere you will forget some useful ideas, and realize the things you could leave out while excluding useful functionality. Ideas are often forgotten to be included into xPlanner as a User Story because of the only reason – the customers are not sure that they need these requirements to be implemented and are afraid of spending extra time on the estimation and realization in vain. The customers should not worry about these things. xPlanner allows two values in the Status field letting to distinguish requirements that can be estimated and later realized and draft ideas that might later be accepted or rejected. These values are Defined – for the ready for estimation User Stories and Drafted – for draft ideas. So, while next iteration planning the developers will estimate only User Story with “Defined” status. That is why the requirements that are not finally defined in xPlanner do not cause extra expenses.
So, within the next iteration planning developers do only User Stories estimation marked as “Defined” choosing those with the highest priority. On estimation completion User Story is marked as “Estimated”. It is the customer who makes the next step: he will confirm that he agrees to realize the User Story at the done estimation and at the certain cost. It often happens that the customer agrees to realize something provided it will take not more than two hours, but the estimation shows that this functionality can be performed only within 16 hours. That is why the process of estimation confirmation allows the customer to manage the cost and product features within each iteration. For example some small useful features can be implemented within these 16 hours that otherwise would not be realized because of the tight budget. The customer shows his confirmation changing User Story status into “Planned”. Only those User Stories that have “Planned” status count while planning the next iteration. The User Stories which were planned to be implemented in the previous iteration will be transferred from the Backlog into this iteration.
So, within the next iteration planning developers do only User Stories estimation marked as “Defined” choosing those with the highest priority. On estimation completion User Story is marked as “Estimated”. It is the customer who does the next step: he will confirm that he agrees to realize the User Story at the done estimation and at the certain cost. It often happens that the customer agrees to realize something on condition that it will take not more than two hours, but the estimation shows that this functionality can be performed only within 16 hours. That is why the process of estimation confirmation allows the customer to manage the cost and product features within each iteration. For example some very useful small features can be done within these 16 hours that otherwise would not be realized because of the tight budget. The customer shows his confirmation changer User Story status into “Planned”. Only those User Stories having “Planned” status count while planning the next iteration. The User Stories which were planned to implement in the previous iteration will be transferred from the Backlog into this iteration.
Further when the developer takes up the User Story implementation in the current iteration, it has the “Planned” status. Having implemented all the tasks in the User Story, he marks it as “Implemented”. This means that the task is ready to be tested by a tester or the customer’s representative (the Product Owner). Having implemented the testing, if all the tests are passed, the tester and the Product Owner change the status to “Verified”. This is not enough to be sure that the customer’s requirements are implemented. In case the customer’s requirement was not understood correctly, we might get the product perfectly functioning, (that has been realized and tested), but is not what the customer needs. That is why only the customer himself can confirm that his requirement was realized. In case of confirmation by the customer the User Story receives the “Accepted” status, and it means that the requirements within the current iteration have been implemented. It is recommended to organize a team meeting with the customer at the end of every iteration to show the implemented functionality to him, otherwise you can simply send the latest project version to him and ask him to confirm the status. If the customer does the testing himself he can change the status into “Accepted” or “Verified” by himself.
We have described the case when every stage is successfully accomplished. Now let’s consider the situation when for some reason the current stage cannot be implemented, for example tests showed some errors (it is impossible to change the status to “Verified”) or the customer does not approve of the estimation (it is impossible to change the status to “Planned”). In this case the team member (the customer is also considered to be a team member) who found the error should change the status of the User Story to the status that corresponds to the last successful stage of the User Story implementation. Let’s consider some examples illustrating this rule. If the User Story with “Implemented” status does not pass the set of tests, then the tester who found this error changes the status from “Implemented” to “Planned”.
In case the Customer does not agree with the estimation he changes the status of the User Story to “Defined”. If User Story re-estimation shows that it is impossible to implement it during a shorter period, then such User Story changes its status to “Drafted”. It means that the task cannot currently be implemented as it is within the desirable hours’ number; that is why the requirements have to be specified. We should note that the desirable hours’ number and development cost are a part of non-functional requirements. It sometimes happens that some requirement was implemented, tested, but the customer is not satisfied with the result. In this case the status of the particular User Story should be changed to “Drafted”, since the error happened while specifying the requirements.
The examples given above show that the development process of one User Story can be compared with the waterfall model when in case of an error found we have to return to the stage when the error was made. The main difference from the waterfall model is that the User Story is one small requirement implementation of which cannot be compared with the whole project size. That is why in iterative processes risks to receive the wrong result are mush lower than in the case of the waterfall model.
Let us return to the two values of Disposition Field for the User Story, “Added” and “Carried Over”. It should be reminded that at the beginning of the article we mentioned that for almost all the User Stories the value of the field is “Planned”. In some exceptional cases the customer can ask us to change requirements for the current iteration. Then new requirements are added as User Story marked as “Added” in the Disposition field. It is to be understood that if we add new requirements and at the same time the iteration length is fixed then we can do this only excluding some requirements from the current iteration and the development is transferred to the next one. It is for such requirements that we use the value “Carried Over”. We need to take into account that iteration rescheduling causes extra expenses on new User Stories estimation and estimation confirmation by the customer, which influences the total cost of the project.
This article was devoted to such an important constituent part of the development process as requirements management, besides we showed this activity procedure based on xPlanner. The approach described above has been successfully applied by ISS Art ltd for a long period of time. It has had good results and allowed improving the quality of the services provided for our customers.