Building custom-developed software without having solid requirements is like trying to fly a plane without a flight plan. Yet, so many custom software developers set off blindly without understanding the problem they’re trying to solve, only to discover when it’s too late that they were totally off course.

The only way to avoid this is to invest the time at the outset to draw up clear and concise requirements to guide the product design and development process.

Sounds easy enough, but creating a solid set of requirements can be a real challenge. Let’s look at the difficulties and how best to draw up requirements for software development projects.

Why are Custom Software Development Requirements Important?

Software product requirements are essential in product design because they force you to think more deeply about the problem you’re trying to solve and exactly how it will be solved by the product.

Eva Weinstein, Co-Founder, and COO of The Pursuit by You, who helps medical device companies better understand their requirements, says:

“Solid product requirements are fundamental for any medical device and, of course, software. It’s an essential first step in design control. Not only do they tell a story of the specifications required for building the product, but they explain why the team built the product in the first place.”

By going through the exercise of drawing up requirements, you expose gaps and missing use cases, which otherwise would trip you up later in the process. In taking the time to thrash out the details at the start, you often discover that midterm requirements are too large in scope for the first version of the product and that the project must be divided into more manageable chunks. The end result always is a much more detailed plan which leads to more realistic design development and/or engineering estimates.

So, Why are Product Requirements so Often Overlooked?

Well, the process of drawing up detailed requirements is painful, particularly because owners or founders (the typical clients of custom software development companies like REEA) often don’t know what they want.

At this point, they can really benefit from an outside perspective, such as an experienced founder or owner who is not too close to the project, to force them to keep digging towards the root requirement. As they keep peeling off the layers of the onion, they often get to a simpler and more effective solution than what they originally had in mind.

The ‘5 Why’s?’ are really helpful here, to unearth more details. You simply keep asking Why? until you get to the clearest answer. The goal is to define the problem very well.

For example, a custom software development client once asked us to measure the bandwidth usage per customer.

We asked: “Why?”

The answer: “So we can charge our customers for excessive usage.”

We asked:  “Why is the usage excessive?”

The answer: “Because the contract states they get x – usage.”

This, in fact, was the requirement.

We reviewed the contract only to find that it did not define the bandwidth usage with enough detail to enable our client to charge their customers for excessive usage. The outcome was that the measurement project died.

If we hadn’t asked why enough times, we would have performed a significant amount of unnecessary work. Because we asked the right questions, we discovered that the requirement did not exist.

How to Draw up a Software Product Requirement Document

By following several rigorous steps as part of a disciplined process you end up with clear and concise requirements to guide the development of custom software.

Step 1 – Find a Narrative

All great things start with a good idea, so the process usually starts with a high-level narrative that captures the big picture surrounding a problem and its potential solution. However, the devil is in the details. Stopping the fine-tuning of the requirements at this point in the hope that the details will be washed out in the design or estimation phases, is asking for trouble.

Not only are these subsequent phases not meant for working out the details, but they typically involve fewer people and often people who are not as close to the product.

Step 2 – Make a List

In the next step, your narrative has to be translated into a more granular set of specific requirements – a clear numbered list or outline of the requirements in written form. It’s only now that the gaps will start to show.

This phase requires less creativity and more discipline. As Atul Gawande says in The Checklist Manifesto: How to get things right:

“What is needed, however, isn’t just that people working together be nice to each other. It is discipline. Discipline is hard–harder than trustworthiness and skill and perhaps even [more] than selflessness. We are by nature flawed and inconstant creatures. We can’t even keep from snacking between meals. We are not built for discipline. We are built for novelty and excitement, not for careful attention to detail. Discipline is something we have to work at.”

How exactly you turn your idea into an outline is less important than the exercise of forcing your developing team to engage in deep critical thinking around the solution, use cases, and requirements.

Eva Weinstein of Pursuit by You says: ”It’s important to consider feedback from different groups or perspectives within an organization (e.g., regulatory, engineering, customer experience, etc.).”

“For example, the engineers may be ok with the requirements, but have they considered the regulatory pathway and the impact on design? The best product requirements are clear, specific, measurable, and incorporate feedback from a cross-functional team.”

This task can take the form of outlines, spreadsheets, or separate narratives for each section of the solutions, which in the end should be a result of a collaborative effort of critical thinking.

If you should stop here, you are already a step ahead of those who jump straight into the design from the narrative stage but ignore the inevitable gaps that show up later in the process. The alternative is to try to manage the process on the fly from this point, which creates the risk of project delays, overrun costs, and suboptimal UX.

Step 3 – Identify User Stories and Listen

Identifying user stories has already begun during the previous steps.

Now it’s time to document each of the user stories that collectively make up all capabilities and functions needed for the end application. This could range from resetting a password to running specific reports with date range pickers as examples.

Think of your users as actors in a play, each with their point of view. It is important to consider every point of view to ensure you don’t miss anything.

As Malcolm Gladwell puts it in What the Dog Saw and other Adventures “To a worm in horseradish, the world is horseradish.”

The task is to capture each one’s voice and reflect this in the requirements.

For example, Weinstein says that just stating that the product should be “user friendly” is a start but doesn’t adequately define the criteria to meet. Instead, ask yourself, Who is the user? Why does it need to be user-friendly? How should it be user-friendly? This is why use cases from all user types are important. Bring in a group of people with different perspectives about how the application needs to work.

Now define each user’s needs and translate them into functional requirements.

User stories often work best when grouped into sections and organized by user type, for example, there should be a separate user story for admin users and regular users.

For example:

Template

As a [user type] I want the ability to [explain requirement]

Completed version…

As an [admin user] I want the ability to [view a list of active users on the platform.]

If you stop here to go onto the design stage, you are still likely to burn unnecessary design and engineering hours for excessive scope and confusion due to poor workflow planning

Step 4 – Prioritize

At this point, owners usually realize that what they thought seemed ‘pretty straightforward’ will require a lot more work than they imagined. This is when they need to prioritize and break up the task into phases.

Luckily, because the user stories are already categorized and written, they can more easily be labeled into ‘must have’ functionality vs. ‘later phase’ functionality.

Ending here will mean that you expect the engineers to plan the workflow without any input from the commercial team. The design and builds start without proper consideration of what will be best for the end-user.

 Step 5 – Create a Picture

A picture says more than a thousand words. So, in this step, you convert your user stories into workflow diagrams. Diagrams seem like a waste of time until you start working on them and you realize some challenges only become clear upon visualization.

For example, sometimes workflow diagrams uncover bad UX design in the form of too many steps required for the user to complete simple tasks. In other cases, diagramming exposes dependencies on other components or forces discussion around sequencing the user inputs and their impact on development complexity.

Well-executed workflow diagrams make it faster and easier for a team to understand the requirements upfront and serve as a valuable reference during the engineering phases.

Step 6 – Pull it Together in a Document

The final step is to pull everything together in a written requirement document. Once it’s been written and Q&A’d to death, it should be locked down, so the solution is designed for a stationary set of requirements. Any changes to the record should be analyzed and agreed upon, because they may have downstream effects on the solution.

If your software development project has come this far, you are highly unlikely to feel that these steps had been a waste of time, but are more likely to say:

“Can you imagine what would have happened if we had not done this?”

Although speed is very important in software development, your project will have a better chance of moving faster and being on budget if it starts with solid requirements as the first step.

At REEA we have years of experience setting solid software product requirements across industries and projects. Let us help you start your project in the right way.