The concept of “Agile Development” can have different meanings depending on who you are asking. For some, it is about adopting a more pragmatic delivery approach and departing from traditional rigorous planning. For others, it is more about a rigour of a different kind that is implemented to tackle the product backlog more effectively; and more generally to cope with constantly changing business needs. But one does not preclude the other.
One thing is certain: everyone agrees on the changing nature of business needs. In the world of software development, it has become exceptional not to be under constant pressure to release new versions and to respond to change requests faster and faster.
Users and stakeholders are fickle, they are assuming certain things and then change their minds when they are delivered what has been requested. It is not systematic but it is very common. And in the end, is it really their fault? It seems increasingly difficult for end users to determine their needs. And this is especially true for applications with client interfaces that are part of a constantly evolving market. The digital shift of many industries makes this volatility more normal than exceptional.
Leave Room for Error
Agility argues that this is one of the reasons why we must adopt a more iterative approach that allows you to make mistakes, an approach in which knowing everything is not necessary to start working. But to do this, it is still fundamental to efficiently manage requirements. When these requirements are constantly evolving, mechanisms must be put in place to deal with this uncertainty.
There are various tools to help manage requirements and change requests and to communicate dependencies, but it is even more important to ensure that there is no ambiguity in these requirements, even if they are susceptible to change. It is one of the main factors that will influence quality and efficiency of the delivered software.
The changing nature of the needs does not justify developers having to deal with unclear demands. It is imperative that they be able to design and plan their development minimally. The viability of the overall process depends on it.
We could even say that the ability to capture what is expected of developers (the problem that their product must solve and how it should do it) is the most decisive factor in the success of the software project as a whole.
One of Agility’s main objectives is to enable companies and their development teams to better serve their customer’s needs, including delivering functional software as quickly as possible. Requirements management is therefore central to any Agile project.
Related post : Room for error
Requirements Management
An initial phase to apprehend and draw a picture of the requirements is essential. This stage is not about establishing the details of the final product, but rather about identifying the project’s scope, which will make it possible to estimate duration and cost at high-level. We seek to have a general understanding of the business objectives and of what we need to achieve them.
Once we have a good idea of overall the goals, the timeframe and the costs, as well as a minimal agreement on them, we can move to Agile requirements management.
The first step is to create a requirements backlog that includes user stories describing in a few simple sentences how a user expects the software to work under certain circumstances. The backlog may also include visual representations, UML diagrams, functional requirements, etc.
Secondly, we seek to plan and prioritize the requirements. To do this, we link them with the strategy and business objectives to estimate their importance and take into account the effort required to accomplish them.
Finally, we break down these general requirements to create the product backlog. It is during this step that the requirements are somehow translated into real features and tasks that developers can undertake. They must be directly involved to actually understand what they are doing and why they are doing it.
I will conclude by mentioning that throughout this process, it remains important to include the customer, the end user. Interacting with him allows you to always maintain an understanding of his basic needs. Obviously, these tips are just a glimpse of all that may be involved in requirements management and I invite you to learn more by visiting the following links:
https://link.springer.com/chapter/10.1007/978-3-319-16101-3_6
No Comment