Requirements are, of course, widely understood as a fundamental part of software development, QA and testing processes. Certain best practices should always be followed to ensure success, regardless of the approach being taken.  That might be: using a development methodology (such as waterfall) that requires a PRD (product requirements document) to spell out every aspect of the project from end-to-end, up front; or an agile process (in which only the “big picture” requirements are described in detail in advance, and implementation details are tasked to the development team); or even a hybrid of both (increasingly common these days).

Requirements management is an increasing focus for many teams to keep a laser focus on project progress.  What is perhaps less widely understood – but arguably equally important – is the potential of requirements management to support good teamwork, through better collaboration, real-time sharing, better overall visibility and faster review processes.  That said, those benefits can only be achieved by adoption of some very specific – but equally, very achievable – best practices.

More on all that shortly, but first, let’s take a step back and look at requirements, and their management, in the context of modern software development and lifecycle processes. The role of requirements is a given, providing a written representation of user expectations of what the software will do when it is delivered.  Requirements management is all about helping teams create those requirements in an organized way, so that they can prioritise and set goals, based on data.

High-quality software

Then, as the project is executed, progress can be analysed, managed, documented and traced against those goals, which might include schedule or resource constraints, or other measurable signposts.  Being able to track all the changes that happen to requirements, the impact of those changed during the inevitable twists in turns of any project, and making it easier to handle those events, is a big benefit of requirements management.  Poor quality requirements, often a cause of project failure, are discovered and dealt with more promptly.

As far as good teamwork is concerned, requirements management cannot help with a team’s basic organisational issues.  However, when used correctly, requirements management gives product owners, project managers – and in an ideal world, the whole team – near-constant visibility into the state of a project and its progress.   Teams that work from robust requirements are more likely to produce high-quality software, because they help the team focus on delivering successful products.

So, this means that good requirements management ensures that the highest value work is always being done, by choosing the right priorities and creating trust between participants: when the project succeeds, the team succeeds. The close and accurate communications that requirements management helps provide boosts team collaboration, plus providing concrete visibility into the impact of changes reduces stress (always a good thing).

Best practice

Seeing quality and velocity issues with granular data and then identifying the root causes of these issues is a form of coaching for less experienced team members. Finally, inspecting and adapting the way requirements are written, based on the team’s level of success in meeting goals, will help optimise the overall product development process.

Here’s an example scenario of how this might help in practice: business people can be encouraged to include cross-functional teams’ participation, involving the design, development and testing teams to hear directly from customers or internal stakeholders.  This gives everyone a more thorough understanding of the scope of work.

In all cases, projects live and die based on dependencies, for example: “The third step depends on the completion of steps 1 & 2.” While it is never that simple in a complex software project, links must be created between those steps, or else there is a risk of making dependencies invisible, which can lead to delays or more serious issues.

In most teams, even a single task needs to be completed by more than one person. In addition to the coder, there will also be a team member who performs QA and one or more other developers who perform code reviews. In an agile process, for example, it’s important that team members give their estimates for how much time it will take to complete each task. Then the project manager will want to measure the results versus the estimate of the development, QA time and code review times, both individually and as a product of the completion of the work.

Robust data

There are also some pitfalls or mistakes to avoid, which again, requirements management can help prevent, such as: a business person writing requirements without the participation of the team that will build and test the software; developers or testers who don’t know when requirements have been updated; requirements are written based on gut reactions, sales and support requests, opinions or out-of-context financial data, without using a prioritisation methodology supported by robust data.

Get people who are going to do the work to contribute their expertise to building requirements, too. This will help to make sure that, for example, a new feature is shippable within the deadline, to include testing and any other tasks required to get the software into production. Getting people’s commitment is achieved not through sign-offs, but through being involved.  This is where a good requirements management tool can help, by letting everyone collaborate on building the requirements and achieving a realistic set of commitments, that have a lower risk of being unfulfilled.

Measuring the success of requirements is essential. Some of the most insightful testing metrics can be gathered at the project level. They can be collected across an individual development cycle, or over the course of multiple releases and projects. Low hanging fruit are: open and close rates, plus burndown status and burn rates, task items versus requirements completed.

Increasing automation

Depending on how requirements are written, QA teams sometimes discover issues they’ve missed only when software is released, and they see the entire picture. Analysing requirements coverage is a good way to prevent this type of result, which means carefully deciding which requirements to test, and how to assure they have been implemented correctly versus testing only a particular development work item. If taking into account the workflow a user follows, then stronger and better tests can be defined and more appropriate coverage. It might be that 80% coverage would be fine for a particular project, but that remaining 20% of items that go uncovered or untested must be ones that do not prevent the user from succeeding with the new software.

One trend of increasing importance in testing is the concept of latent requirements. These are usually not written, so they are hard to plan for in advance unless a clickable prototype is used. Latent requirements are functionality that users may not expect in the software but that make them like the software more. This might be as simple as a UI in a banking app that shows the user the last amount paid. Another simple example might be a website autocompleting what the user is typing in. They might not expect it to do that, but it boosts the user’s confidence in the task they are performing. When such a requirement fails, this represents an opportunity to improve the software, but it might also mean additional work to implement. Having a testing team that can identify such opportunities is a great benefit, because they can create product differentiation, leading to happier customers or improved competitiveness.

Even in today’s world of increasing automation, AI and data-driven decision-making, the people actually building, testing and delivering software are the difference between success and failure.  This is fundamentally very much still a ‘people’ business, depending on individuals’ smarts but also, good teamwork. Requirements management isn’t just a process gatekeeper, it’s also how individuals and teams can better collaborate, understand each other or customer needs and above all, deliver projects on-track, against appropriate requirements that give end users what they actually need.

Written by Chuck Gehman, Perforce Software