Almost every software project begins with an assessment of the requirements for the software solution and their prioritization. This involves not only defining the scope of services for the software solution, but also estimating the effort required to implement it. Prioritization is particularly important for agile projects in order to plan the sprints and milestones. The client also benefits from prioritization, as they can be legally certain of when which functions must be delivered.
In practice, however, it is very often the case that stakeholders consider their own requirements for a software solution to be the most important. This makes prioritization very subjective and the scope of mandatory requirements far too large to fit into the timeline. The challenge for project planning is to choose a reasonable scope for the project in order to stay on time and within budget. In order to achieve the desired project result in a targeted manner, a finer gradation of requirements is necessary. But how can good prioritization be achieved?
Using the right method to prioritize requirements for software solutions
Statements such as "We need this function, so of course it's priority 1" are often made during requirements gathering. As consultants, we need to question exactly what "need" means at this point. It has proven to be a good idea when prioritizing the Focus on the respective business impacti.e. the impact on the business. A simple method for this is the MoSCoW-method. It gives a four-level prioritization scale for the evaluation of requirements:
The implementation of the must requirements is Minimum requirement for acceptance of the project. These can therefore be used as Legally binding requirements to a software solution. Without their implementation, the project cannot be successfully completed. To allocate the requirements, the following must be defined in advance Decision criteria be defined. The following have proven themselves:
- Can the software run without this function?
- Can the business processes be implemented without the requirement?
- Can the quality guidelines be complied with without this requirement?
- Is user satisfaction guaranteed even without this function?
If most of the questions here are answered with "No", it is highly likely to be a must requirement. It is particularly important to also consider the consequences and the possible Damage in the event of non-compliance with the requirements to think about it. In this way, functions can also be deliberately postponed and consequences or damage accepted as long as these calculable and justifiable are. This does not mean that this will not be implemented in a later project cycle.
In the event of a system replacement, the Comparison with the existing system whether the feature already existed in the old system. If not, the question arises as to how much pain the lack of this function has caused users in recent years. Perhaps it is just a should requirement after all.
Together with the mandatory requirements, the should requirements form the entire scope of the project and are Fully considered in the project planning. The system is less efficient/effective without the implementation of this requirement. Possible questions for the Should requirements could be:
- Does the request replace a manual workaround?
- Does the function enable more efficient access to existing information?
- Does the feature enable new business aspects?
If you can answer "yes" to most of the questions, it is very likely to be a Should requirement.
In contrast to the must requirements, however, these are Modifiable through change requests or negotiations. If problems arise during the project so that realization cannot be completed within the set Budget or time frame is not possible, the Should requirements postponed are prioritized. The must requirements are then prioritized for completion. Acceptance can also take place if not all Should requirements are fulfilled. In consultation with the client, these can be delivered at a later date or even omitted.
These requirements are also referred to as "nice-to-have" and make a system more attractive. As a rule, they are only implemented once all must and should requirements have been met and sufficient resources and time are still available. If these become scarce at the end of the project, only those functions should be implemented that meet the greatest added value with regard to the business purpose of the system and are possible within the remaining time frame. Could requirements are usually not time-critical, but can certainly be important.
The Won't requirements are defined in terms of deadline and budget. not included in the scope of services of the current project. Instead, they will be included in a Pool of ideas or a list of requirements for the next project saved and implemented there. The delimitation helps to clarify the scope of services to the project members and to keep them enthusiastic about the project. This is because requirements submitted from the initial list of requirements are not deleted without replacement. It also prevents Functions forgotten and never be implemented.
The classification into the named requirement groups (MoSCoW-method) is often not easy in practice. One Orientation guide is the 60 percent rulewhich experience has shown to offer a reasonable distribution. The Must requirements should a maximum of 60 percent of the total expenditure include. The Should and Could requirements each account for around 20 percent of the total effort. The Won't requirements are not included in the scope.
If, at the end of the prioritization process, there are more than 60 percent of the must-have requirements for a software solution, renegotiations can be held to expand the scope of the project. Otherwise, the client should Re-examine and weigh up must requirementswhether they really all belong in the category. He should be aware that the Should requirements are very likely to be implemented. In practice, this approach proves to be a good tool for both clients and contractors. The scope of the project is clearly defined with the requirements and the agreed budget and allows the implementation to be planned in terms of time.
Image source: Usability_© Olivier Le Moal - Fotolia.com_blog
