How to Better Define Requirements for a Software Product

Software development is a complex process to start with, but the success of a software project ultimately comes down to the quality of communication between the entire team, stakeholders, and clients.

As an Agile team, we strive to minimise risks, while ensuring close contact with our clients and establishing a constant feedback loop to keep our project in sync. But the first steps are the most important ones for securing a common understanding and vision for the software product we’re about to take from idea to an actual successful project on the Internet map.

Clients usually come with a very enthusiastic approach to their ideas, and they want a lot of functionalities, because they want their users to get the best experience out of their products. They often ask if certain features can be accomplished, and our most common answer is: “Everything can be done!”, but of course there are many other aspects to be evaluated until then. We need to focus on the little steps at first, and we admit that this is one of the hardest things to do in software development.

First things first: we have to identify the MVP (Minimum Viable Product).

There are several techniques available to achieve this, but we prefer the user story mapping method. This stands for arranging user stories to create a more holistic view of how they fit into the overall user experience.

Through user story mapping, we get to foresee the overall process of the product and even identify additional steps that can’t be defined without putting the idea into perspective. With visualizing the big-picture, the software development team can prioritize, and the management team can keep the backlog feasible.

Next — what goes in and what goes out

After gathering requirements together with the client, we try to establish what will go into the MVP and what is more suitable to be implemented in future iterations. We split the user stories in 4 quadrants:

→ High impact + high urgency — will be automatically included in the MVP.
→ High urgency + low impact — will be individually analyzed and for each particular user story, a decision will be made: to be included into the MVP or not (if not, most likely will be included in the first iteration).
→ High impact + low urgency — based on our experience, these are usually included in the upcoming iterations (first or second iteration); they are what we call nice-to-haves.
→ Low impact + low urgency — usually go in the backlog, and they tend to stay there. This doesn't mean they will never be implemented, but depending on the budget and new improvements requested by clients, they will be the “sacrificial” ones.

After we clearly identify the MVP and the main user stories, we start writing them. There are different approaches in doing this, but we prefer to keep them simple and short, but with great value.

First thing we need to do is remember that user stories are about users. We identify who does the action (the user/ admin/ guest/ vendor/ buyer etc), what action needs to be done and what’s the outcome. Simply put, we focus on WHO, does WHAT and WHY?

Therefore, if you follow these simple steps: keep the focus on the user, encourage the team to think freely and creatively and keep the end goal in mind, your software requirements should be clearly defined.