Duties of requirement management
Depending on how a project is structured and which work-cooperation model has been agreed on with the customer, the requirement management needs to be adapted to the circumstances. What worked well in one project can already work less well in the project that directly follows. This can be due, among other things, to the availability of the customer, the cooperation model or the previous knowledge. In order to not have to re-invent the wheel for each new project, it is important to have an adaptable requirement management. It is for this reason a possible requirement management with the web application Redmine will be presented here. The approach can be used for different projects and offers the advantage that the requirement management can be connected with the other phases of the product development.
But first a few general words on the topic of requirement management: A requirement reflects the wishes and expectations of stakeholders that have to be implemented in the product. It therefore needs to be ensured that all requirements are correspondingly implemented and tested. The most beautiful and most detailed description of a requirement has no worth if it is not examined whether the product actually fulfils it. That means that the requirement management is not a discipline in and upon itself, but has interactions with the entire product development process.
In order that the requirements contain all the information necessary for the implementation and in order to conduct testing, they need to contain answers to these questions:
- What should the function be able to do? – As detailed and “lively” a description as possible
- How well should the application be able to do something? – Measurable criteria
- How can the function be tested? – Acceptance criteria and test cases
- Who is responsible for the function? – Contact partner
- How important is the function? – Prioritisation
In our partner blog you will find a detailed description of how requirements can be included and what information is necessary: How to keep track of requirements
Over the course of the project, the requirement management goes through several phases. The initial requirements are included first. After this the development is begun and this provides new insights on a regular basis. Desired alterations are included and evaluated. This entails decisions being made on whether the requirements are immediately adapted or if they will only be taken into consideration in later versions. At the end of the development, test cases and acceptance criteria need to be examined in order to ascertain whether the developed product fulfils the described requirements.
If it only becomes apparent, for example, during the final test that a requirement has not been properly implemented, it can be quickly recognised which requirement is in question, and with that, which affected features and tasks need to be adapted.
This means that the requirement management is not a one-time activity at the outset of a project, but it is a continuous procedure that takes place throughout all phases of the project. This makes it necessary to find ways to connect all the different phases with each other. We use the aforementioned Redmine for this.
Taking down requirements
The first step in order to administer requirements in Redmine is to set up a “tracker” for the requirements. This serves the differentiation from other tickets, such as, features or bugs, for example.
When this tracker is set-up, the known requirements can be created. By allocating a priority to the requirements and, where applicable, the assignment to a target version, the product planning can be carried out. In an agile project, that would be the initial product backlog.
The image shows a number of requirements made of a fictive application. In relation to the current status, all requirements with a very high or high priority are to be implemented in version 0.1. All with normal priority in version 0.2 and those with low or very low priority in version 0.3. The prioritisation is naturally only a snapshot of the situation. It always needs to be examined when changes occur in a project, whether these then have consequences for the planning.
Assignment to product development and planning
In order to derive tasks from requirements, it makes sense to divide the requirements in accordance with features. A feature can, for example, be a single function or a process step of a requirement. In agile projects the features would be described as user stories and these then planned as sprints.
The requirement that users should be able to register on the product can, for example, be divided up into 4 features:
- Users must be able to register –> registration of new users
- A log-in screen must subsequently exist –> log-in
- In the event that users forget their password, they need to be able to request a new one somehow –> forgotten your password
- In order to verify the e-mail provided during registration, a confirmation mail should be sent –> confirmation e-mail following registration
The last two points are not as important for the customer because they are additional functions that do not need to be available immediately. They were assigned a lower priority as a result.
Through the assignment of predecessor/follow-up relationships between features and their prioritisation the implementation sequence can be planned.
When processing periods are planned for the features in traditional projects, a project planning can be visualised in the Gantt chart from Redmine.
Features are subsequently broken down into tasks for the product development. In Redmine the connection between the tasks and the superordinate features can be created via subtasks or the “associated tickets” field.
Besides the administration of requirements, implementation tasks and bugs, Redmine can also be used for test management, e.g. using the Redcase plug-in. This allows for the possibility of connecting requirements directly with test cases. This then makes it possible to illustrate the entire software development process, from the interview with stakeholders though to the final test, in a single tool.
In summary it can be said that requirement management with Redmine is a good option because other phases of the product development process can be managed as well and, as a result, all information can be provided in a single application. This allows interactions between the phases to be quickly and easily understood. Going beyond this, Redmine offers a variety of helpful filter possibilities, so that users are not confused by a flood of information. Depending on the role within the team, the information can be limited to requirements, features, tasks or test cases.
The unification of all phases in a single application does have disadvantages, however, and these can certainly not be kept secret. Redmine is an issue tracking application, it is not a professional test or project management solution or a document management system. One needs to be aware that the formatting possibilities for the requirement description are somewhat limited and that the project planning and its visualization in the Gantt chart are only possible to a limited extent.
Many customers also demand a text document as a result of a requirement analysis. In order to avoid a doubled documentation, the requirement tickets can contain references to sections of the result document.
For successful requirement management is important to become completely aware that it is not just a phase at the beginning of each project that needs to be concluded as quickly as possible. It is the link to the customer, who would like to see their expectations and wishes implemented in the final product. This means that the requirement management is connected with all phases of the product development.
Redmine fundamentally offers all the necessary functions in order to document requirements. If someone decides to do this, they have the advantage of having all information from all phases of the product creation process in a single application, through which the dependencies become clear and the effects of changes can be better evaluated.