Requirements management for web and app projects

Product requirements can be a rather intimidating topic for newbies. After all, it touches on the design of things but also on business and engineering. To manage the requirements of a project implies hard work, lots of prototyping and testing as well as long team meetings.

But what does it mean to manage requirements in any given project? The theory says “write everything down and go from there”. But what does that mean in practice? What is the role of a requirements backlog or a good old user story in the requirements management front?

We’ll take a closer look at an often misunderstood face of UX design, passing through the initial stages of gathering data and going all the way to alternative takes on the classic requirements management process. Let’s dive in.

With each project, comes the need to gather, analyse, implement, test and validate requirements. Think of your requirements as the most important checklist in the entire project, telling you what the product needs to do in order to function properly. This list tends to be quite long, as it includes requirements from multiple backgrounds – business, design, engineering and so on.

It’s natural that managing requirements takes a lot of attention, because it deals with everything from the big things, like how the product will make money, to the small details like microinteractions. Unlike what some may think, managing the requirements of a project starts from the very beginning of the product development process and keeps going past the product release.

Initially, the requirements are carefully put together with close cooperation with the client, which tends to cover main business requirements and broad functionality of the product. From then on, it’s all about adding other requirements and slowly creating a more defined idea of the final product. As the project advances, there’s a great need to keep things organized and document your way around the project.

Among the factors to consider when dealing with requirements in any project are the documents involved. With each requirement comes more information, such as the accompanying notes, tests that have been done and prototypes that implement that requirement in more tangible terms. Altogether, it represents a vast amount of details and information. If you’re not careful with keeping it all written down and updated, it can be easy to overlook details.

And so, it’s crucial that you and your team keep this information organized and accessible in a series of relevant documents. One of those documents is the traceability matrix or the functional specification document that guides developers. We’ll get into the details of those documents and how they are helpful to design teams further on.

This ties in with another crucial aspect of managing requirements: collaboration. When it comes to gathering, managing and implementing requirements, having everyone collaborate is non-negotiable. You’ll need different points of view in order to make sure you cover all your bases.

For a more practical example, consider a requirement that refers to a core functionality of the product. It was brought up by the client, who wants this functionality to be the main selling point of the entire thing. You’ll need designers to look at that functionality and tell you what kind of design efforts would need to go into ideating that functionality. On the same lines, you’ll need engineers to tell you what it takes to bring that ideation into reality in technical terms.

Lastly, there is the relationship between implementing and testing requirements. This relates to taking an abstract concept from the requirements, and bringing it into reality by implementing it. We’ll take a closer look into what exactly that implies, but for now suffice to say that you want to have tangible and concrete prototypes and wireframes to visualize requirements.

This is not only because your team needs to test and validate it, but also because seeing it brings some perspective to everyone. Among the main arguments for creating early prototypes to see requirements in action is to validate that the client is sure that is what he wants.

Generally speaking, the requirements management process can be broken up into five steps. We begin with gathering requirements and slowly creating our list of requirements. We define what the product will be like and pass by several steps related to implementing, testing and validating the requirements.

There is a certain order of steps in managing requirements, but it’d be a mistake to classify it as a linear process. Much like other aspects of UX design, there tends to be back-and-forth between stages of this process, as requirements pass or fail tests along the way.

These are, perhaps, some of the most difficult tasks when it comes to managing requirements. Before there’s anything to manage, your team has to work in close proximity with the client to define what the product in question will be.

This can be extremely challenging, because it requires a clear understanding of the client’s business, industry and ultimate goals. The gathering stage isn’t just about writing the broad requirements down, but also about digging deep into what this product needs to do and its role in the client’s business. This stage has a lot of research, lots of talking to the client and to the user.

Some of the main things to set straight during the gathering stage of requirements management include a crystal clear notion of user needs along with the client’s process of doing business. In these two fronts, it’s always a good idea to get visual. Taking the time to create a diagram of the client’s process in daily business is going to add value by making it easy for the entire team to grasp the information.

In fact, the gathering stage of managing requirements is the time to take out the big guns in terms of visual representation of all the information you’ll obtain. As you create an entire system of information where your team can find everything it may need, you’ll circle back to some familiar names in the UX sector. Those are user flows, user personas, diagrams, along with every other tool you have in the toolbox. The goal here is to define the central problem, possible solution and the context surrounding it all.

Business analysts. These are the guys that will make sure the product can actually be financially sustainable and beneficial to the client. Money and business are a central part of any UX project, and the team will rely on these guys to guide them through the sea of industry and business models.

Product Managers. It’s true that the job description for PMs can change from company to company. Some of them engage in design, others in testing and others in marketing. With that said, the PM is the person in charge of allocating resources and tasks, communicating with stakeholders and ensuring things get done.

UXers, Designers. Your designers are the creative souls who take abstract requirements and bring them into the realm of reality with prototypes. The role of design can’t be overstated, going far past simple visuals. These guys will deal with navigation, interaction, information architecture and other crucial aspects of the product.

Software and system engineers. The engineering team should be involved from the very start, so that they can give their validation that the requirements can be technologically implemented. Their input is vital, tending to cover more practical sides of requirements such as the efforts to develop the whole product.

Over time, as the team develops a better understanding of what the scope of the product will be with the basic requirements, there will be a better idea of what it will take to see the project through. This leads us to the planning aspect of gathering requirements, when we estimate the amount of resources needed to ideate, prototype and develop the entire product.

The resources, such as time or man-hours, will vary greatly from project to project. How many people do you need to make this real? How many hours? How much time do we need?

Among the things that make this planning a complex task is the fact that things can change direction rather quickly in the early stage of the project. We’ll get into the details of change management later on in this post, but for now, suffice to say that planning is a continuous endeavour as opposed to something done once at the beginning.

As things progress, you’ll want to take a moment to assess how much progress has been made, the resources that were used up and see what that means for the remainder of the project.

Once you know your main requirements, comes time to transform them into something tangible. It’s time to bust out your prototyping tool and see the requirements in action, before you can test them. While each team approaches prototyping in their own way, we find that prototyping requirements early and often is the best approach.

That’s because not everyone dealing with the requirements are designers, as seen by all the different roles involved in this process. For some of the people involved, a written requirement doesn’t necessarily paint a picture. While most designers can all but close their eyes and see the requirement in practice, that jump in imagination can be hard for some.

There’s great value in making early prototypes of key requirements, such as those regarding the main features of the product.

Seeing it with their own eyes can change the way stakeholders feel about the requirement, give them some perspective on the product or even make them change the requirement altogether. Keeping in mind that the requirements management process isn’t linear, prototyping requirements in the gathering phase can give the entire project more security and stability.

The prototyping side of managing requirements is closely related to testing and validation. With an actual prototype in our hands, we can go on to test it and see if the requirement has been met or not.

For a more concrete idea of how you can use the power of a prototyping tool like Justinmind and sound requirements management, check out our interview with Product Owner Carol Nejedly: Prototyping functional requirements.

Testing is key not only in order to make sure our current list of requirements is indeed the final list, but also to make sure that each of them are met. This can represent a huge amount of work, mainly because it includes testing every little detail of the design in order to validate and approve each requirement.

Each requirement comes with certain testing that is needed. No matter what it is, you want to prototype it and test it. As mentioned before, the full list of requirements to be managed can be quite long. This drives teams all over the world to keep a meticulous record of what has been tested and what the findings were. Classic documentation, such as the Traceability Matrix, are a good way to make sure no stone is left unturned.

Testing a prototype can shed so much light on how the design can be improved, where it fails to function properly and how users react to it. There’s a whole relationship between testing a prototype to validate a requirement and testing its usability.

We won’t get into the details of usability and how crucial it is to carefully test designs. For that, you can check out our full guide to user testing. For now, suffice to say that requirements can often hint at usability without some of us even noticing it at first. It’s all about how you look at requirements and their relationship with the product’s usability.

Let’s go over a silly but practical example. A requirement states that users need to log into the solution, prompting the login to be prototyped and tested. It fails to meet our standards of usability. This means that far too many users would experience difficulties in logging in. Now take a moment to ask yourself: if most users can’t actually login, has this requirement been met?

After all that thinking, debating, prototyping and testing, finally comes the release of the final design. Once all your requirements have been met and everyone is happy, the roll out begins and users can start to enjoy the design. As much this can be a moment of triumph for the entire team, it’s far from the end of the requirements management process. In a sense, managing requirements is to manage the product.

Once you have real users interacting with your product, you get access to all sorts of data that will paint a picture of the product’s overall health. Truly great product teams understand that data is a precious resource and that it can point to unseen issues and work to constantly improve the design.

Many design teams tend to use the time following the release to first hunt for overlooked usability issues and errors. Once those are corrected, it becomes possible to work on the requirements that were sidelined before due to lack of sufficient resources, resulting in a list of requirements that could be added later on.

Future updates will bring further improvements and consistently improve the solution’s value to the user and to the client. For a better idea of how you can use your data to pin down updates that will benefit users, check out our UX talk with our friends at Userzoom: UX research for updates that matter. It’s a wonderful read.

The requirements backlog is composed of every single requirement that has yet to be implemented, tested and approved. It can be a rather long list, depending on the project and how far along it we are.

Some teams have their own way of creating a backlog, with some using the requirements as they are while others transform each requirement into something a bit more understandable. That can result in a backlog of use cases or user scenarios or something entirely different. Each design team has their own take on the backlog and that is ok.

The backlog itself already shows a lot of information by listing out requirements as they are. This means that adding too much additional information would make the backlog overcrowded and difficult to understand. The best way to handle the additional information you want to add to each requirement is progressive disclosure. Include a link that people can follow if they want to know more. Let them explore as deep as they need to. It’s important to offer context, data and testing information on each requirement – it’s just a matter of making sure it’s not overwhelming.

Remember that a lot of people will be making use of the backlog, not just designers. For a business analyst, seeing a bunch of user scenarios and user personas, diagrams and flows might be too confusing. You want to keep it simple upon first glance, so that anyone can look at the backlog and get a realistic sense of how far the project has gotten, and how much further it has to go.

Another key factor in managing a requirements backlog is prioritizing. In any given project, we’re bound to run into requirements that would be ideal, but that aren’t necessary for the initial product launch. These “nice-to-haves” can add real value to the product, but they can also delay the release and take away from other more important aspects of the design.

Prioritizing the backlog is important, as time can pass by the entire team much quicker than expected. With tight deadlines and any kind of unforeseen issue, time might just be the single most precious resource when it comes to requirements management. You want to get the most important requirements done as early as possible and secure the main functionality of the product.

It’s a good idea to use a scrum tool for your backlog. That way you can name teams or individuals to implement specific requirements, keep track of who did what and when, as well as having freedom to add as much information as you see fit. It’s just too many details and factors for anyone to be able to do it manually.

The traceability matrix consists of a complete list of each requirement, from business to design. Each requirement is translated into a use case, pointing to a specific point in the experience. In theory, this is done so that we can consider every single possible outcome that can result from a user action. In practice, this is done so we can make sure that every single thing has been tested before launching the product.

The traceability matrix takes all the use cases for all user actions and lays out all the possibilities for our team. From there, it’s a matter of testing every single outcome and making sure that the solution works.

This is a concept that is called testing coverage, and the ultimate goal here should be to achieve 100% coverage. That means that your team will ensure that each and every single one of the requirements will be met and that your users won’t find any nasty errors and failures in the experience of the solution.

The main goal of creating a traceability matrix is to keep track of the details. Each requirement comes with its own details, context, and additional data. Organizing all of that, plus the testing findings to each one can quickly turn into a nightmare if done carelessly. The traceability matrix can be quite handy in giving us a map, a snapshot of what has been done and what needs to be done.

While not necessarily a requirements management document, it’s good to keep the functional specification document in mind. It’s a new take on a classic report, intended to be passed down from design to development as a guide.

It lists out everything, from the big and central aspects like the client’s original problem, to more the small and detailed ones, like the exact position of visual elements in any given screen. It’s a complete overview of the solution, much like a blueprint to an architect – the last thing we want is to forget a wall!

Remember that your technical team of engineers and developers will also be a part of your requirements management process. Their input is crucial, and it’s a good idea to involve them in the creation of this document. Their insight will make sure the document is thorough, giving them everything they need to make the prototype a real product.

Old friends that most UX designers are familiar with. User stories, cases and scenarios are a great tool to have among your requirements documentation. They can put things into perspective and translate requirements into more exemplifying language. As we mentioned before, use cases are also crucial in creating other documents such as the traceability matrix.

User stories and user personas. Both aim to give us more insight into the final user, helping the design team see things from the user’s perspective. User personas tend to focus on the user’s habits and preferences, while stories are oriented towards the user’s end goal.

User scenarios and cases. Scenarios are situations that point to the user’s motivation for trying to complete that task, offering insight into expectations and possible ways to complete that task. Use cases also portray a task, but focuses on possible outcomes from interactions between the system and the user.

The agile methodology has enjoyed a lot of popularity over the last few years. Today, it’s quite often we find design teams using agile workflows to pace their work and allocate their resources according to what the priority is at that point in time.

It’s favored because it helps teams to communicate better and gives a good structure to control the way things are done, while allowing for a lot of flexibility. It was only a matter of time before someone tried to apply this concept to requirements management – and succeeded. In broad strokes, the first initial steps in agile requirements are pretty much the same to the classic process.

It’s once we have all the pieces of the puzzle laid flat on the table that we notice the sharp difference in the workflow. Armed with a thorough understanding of the client’s business and the gathered requirements, the design team will work in short sprints to quickly implement requirements in prototypes. As the requirements are implemented, new requirements will come up. That is ok, as the agile way allows for a lot more margin to adapt along the way.

The first pillar in the agile requirements management workflow is stakeholder participation. At the end of each sprint, the client and other relevant stakeholders get their hands on the actual prototypes of the requirements. That way, we have constant validation and a project that doesn’t lose its way in the mist. It secures the project and gives the client a realistic feel of how much progress has been made.

The second pillar is communication. One of the main advantages of agile workflows is that once every two weeks, we have everyone in the same room going over what’s been done and what is left to do. That can be a powerful way to make sure each requirement can be implemented both in theory and in practice, as well as spotting troubled areas where issues may delay timelines. Cooperation decreases chances of things being overlooked or mistakes being made.

The third pillar is a favoring of implementation rather than simple documentation. The agile way is all about being quick on our feet and delivering tangible progress quickly. Loyal fans of the agile method tend to say that the classic way of managing requirements focuses too much on documenting things. That takes time, effort and holds the project back. When dealing with agile requirements, it’s preferable to do and see it in action over discussing it and analysing it.

To manage the requirements of a project is to manage the project. It deals in crucial aspects of the product, being the kind of thing you want to dedicate true time and effort into. Writing things down and keeping track of everything is essential, as your team will be dealing with a massive amount of information – from the client’s business model to the latest testing of a specific requirement.

The main thing to keep in mind is that you need the entire team in order to gather and implement the requirements. Collaboration and communication is a basic building block of requirements management, and can make or break a product development initiative. On a similar note, you need everyone to pay attention to the details at every turn.

Prototyping an abstract concept and making it real can make a better development process and avoid any sudden changes down the line. You want to go from conceptual to tangible as quickly as possible, so you and your team can test everything. Hopefully, armed with this guide and a new understanding of managing requirements, you’ll be ready to guide your team through the maze of creating something completely new.