Requirements for software applications as well as for infrastructure resources are important. Some development companies do not pay special attention to them, even large enterprises tend to underestimate the importance of them. Changes to features of applications later in the development process are difficult and costly to implement. Furthermore, clear requirements prevent miscommunication between teams. With these advantages in mind, which other advice for software application requirements is important?
Why requirements are needed
Requirements are the heart of every software application. Without requirements, it’s absolutely unclear why time and effort are spent on the project at all. You’d better stop your project since you’re wasting precious time.
Since requirements greatly determine how the project and application evolve over time, it’s important to pay attention to them from beginning to end.
Key risks when requirements are not properly specified and maintained:
- Stakeholders & end-users expect feature A and they get feature B. A lot of rework and bug-fixing is needed.
- Delay of the project (milestone) since requirements are missing, incomplete or constantly trigger time-consuming discussions.
- People (stakeholders as well as the persons who actually executing the tasks) do not feel involved, this creates friction and resistance.
Proper requirements help to come to solid solutions. When requirements are created “on the fly”, execution teams might miss them. However, at the same time, requirements should not dictate a (technical) solution up-front since then the solution becomes the constraint.
And last but not least: one of the main reasons to write down proper requirements is to avoid high costs later in the software development lifecycle. Numerous studies in this paper emphasize this. It’s far more costly to fix a bug in production compared to fix it in the initial design phase. You might argue this is not a big issue when practicing DevOps. However, if you choose the wrong cloud provider since your requirements were not clear, it’s very costly to change half-way through the project.
Different types of requirements
Most often, requirements are focused on the “what” and “how” of the system. That is important, but even more important is the business justification of why you spend time on something at all.
Business requirements
Business requirements answer the “why” question. It’s important to have management buy-in for whatever you do, so the answers to the “why questions” are most important. All the others come later.
Examples of business requirements are:
- Reduce the amount of bugs across all software projects by 25% the coming year.
- Migrate 10% of the applications to the cloud before the end of the next quarter.
- Reduce the number of canceled bookings by 15%.
Notice these business requirements are very specific. They are SMART: Specific, Measurable, Acceptable, Realistic and Time-bound.
If you omit the SMART component, everyone will have its own interpretation of what is “good”. No clear goals lead to bad results. Sometimes even no results at all. So avoid requirements like the following: The system must provide useful information to the end-user in a timely manner. This is very subjective and leads to a lot of discussions. Be as precise as possible.
Verify the business goals by constantly asking the “why” question until you reach the level of the organizational business goals. This helps to determine if your business requirements are aligned with the overall business strategy.
System requirements
The other category is system requirements. They answer the “what” and “how” questions. Those are aligned with the business requirements and fall into two categories:
Functional requirements. Answers the “what questions”. Examples are:
- Build a reporting function which aggregates the reasons why customers cancel their booking in the last stage of the order process.
- Improve the Graphical User Interface to support smartphones so people can use your website without the need for a computer.
Non-functional requirements. These answer the “how” questions. Examples are:
- Improve the stability of the application to minimize downtime. Strive for 99,99% uptime.
- Reduce all critical security bugs coming out of security tool X to increase the applications’ security.
- Implement high-availability across two availability zones to spread the load between multiple servers.
Both categories also have an enclosed “why-question”. This section expresses the business value. It helps to prioritize the requirements and get an agreement of the various stakeholders to work on the features to implement the requirement. Without it, you might get the feedback too late and you need to adjust it later or stop the development of the feature at all. Even in a DevOps environment in which you have high iterations you need to avoid this scenario.
Requirements process
Requirements should not only be created up-front but constantly changed according to new insights and new external requests. The following phases are important for the initial as well as the updated requirements:
- Elicitation: gather the requirements from the stakeholders. To come up with a reasonable list is to ask for what a stakeholder really needs instead of what he wants. This makes things more explicit and limited (you can never implement everything). It’s the most important phase since it determines the outcome of the other phases which follow.
- Analysis: the requirements which have been gathered should be analyzed to make them consistent (with each other), make them complete, prioritize them, and correct them if needed.
- Specification: all stakeholders must have access to the requirements you have written down. It’s important to let them enter meta-data as well as comments to make them complete. And a simple technique to prioritize them is to use the MoSCoW classification. Let your stakeholders weigh them, this keeps them involved.
- Validation: requirements should be of high quality. The analyst is not the most ideal person to check this. Some of the validation techniques are reviews by the stakeholders, formal inspection by an external person, and walk-through between the analyst and the stakeholders themselves. Testcases and acceptance criteria (just like software application tests) help to keep the quality high. This also gives an indication of the feasibility of the intended feature.
After these phases, you have a clear list of base requirements to start the project with. Be sure not to add too many details yet, since it is very likely that things will change while the project is being carried out.
Breaking down the walls
In the cloud era, the non-functional requirements (aka operational requirements) are as important as the functional requirements. Since the cloud is an unpredictable and hostile environment, you need to add those operational requirements to the list. These kind of requirements can help to break down existing walls.
Involve the Site Reliable Engineers (the formerly OPS people) early in the requirements gathering process. Basically this forces business and OPS to work together on the same goals.
A couple of examples of operational requirements which are relevant in the cloud era are:
- What is the required response time of requests and which cloud-native features are best to support this?
- How to utilize the fail-over capabilities of the cloud to handle unexpected failures?
- What are the security requirements in terms of data encryption (in transit and at rest) and how to handle the keys to encrypt en decrypt this data?
- How does feedback of the CI/CD pipelines flow back to the development team (e.g. are push notifications to tool X supported?).
In the cloud, infrastructure is paid based on the actual usage and security is not an afterthought (anymore). This makes operational requirements a great candidate to help break down the silos. It helps to involve everyone and there is more:
- It helps to capture duplicate requirements that already have a solution elsewhere in the organization.
- People of other departments help to check the existing requirements and they can correct them if needed.
- Operational requirements help to start with the end in mind and work the way back. Customers come first since DevOps helps to think from a product perspective.
An iterative process
Since there is a lot of theory which helps to keep your requirements up to date, this is merely focused on the waterfall project methodology. In a DevOps world, it’s rather difficult to keep your requirements up to date with the ever-changing world. Changes happen at a very fast pace and external factors influence your projects while you are running your sprints. Keep the following tips in mind to make sure your requirements are constantly aligned with the reality:
- Invite all of your stakeholders to your sprint reviews. In case requirements change adjust your backlog and notify them. You can let them commit on the sprint planning. Not on the amount of work (which is the responsibility of the team itself) but on the order of the user stories. This helps to keep them aligned and committed.
- Link your initial requirements to your ticketing system.
- With every epic or user story add the person who requested it as the main “benefits owner”. This helps others to see who is involved and from which perspective the requirement and thus the feature is brought to the table.
Systems
- Collect feedback from your running systems like performance problems that differentiate from the baseline. Furthermore, collect critical errors and create user stories directly from them. These can even be annotated with the person who actually did the original request.
- Application code which is pushed through a CI/CD pipeline and which ends up in production should be able to trace back to the original requirement. This can be realized when every commit is prefixed with the ticket number so everyone can trace it back to the original request. From here, it traces back to the original requirement. Consistency is king: pre-commit hooks help to force every commit to have a ticket number. In case you need to track down problems (bugs, security incidents), you can relate this to the business value. It helps you to determine what to do (e.g. how much effort you should put in it and what the priority is compared to other activities).
Wrap up
Proper requirements are essential for the success of your products. Great requirements are SMART and all relevant stakeholders are involved in every phase of the process. Be sure to split the functional and non-functional requirements and make sure they answer the “why” questions to justify your project in its entirety. And last but not least: adjust your requirements regularly to be aligned with reality. In the end, the customers of your application are happier and this is one of the most important goals.
