How to Prepare a List of Requirements for Your Product

When Bill Gates developed Microsoft, he had an idea of what he wanted each component of the software to do.

Let’s just take “Word” as an example. The general purpose for this piece was word processing. He wanted a program that users could learn easily. He wanted some very specific elements – bold, italics, underline, tabs, margins, font choices, spacing, saving, printing, security, and a host of other more sophisticated options.

What Gates had to do was sit down and create a software requirements document – the type of feature list that would define all of the functional requirements for this piece of software.

This initial list was the “what” of the software – the project requirements. The development that followed was the “how” of the project – the requirements engineering, so to speak. It was the architecture, both back-end and front-end, that caused that software to do what Gates had envisioned.

How to Prepare a List of Requirements

Bill Gates is a techie. In putting together his requirements list, he and his team probably fashioned UML diagrams that described processes, wireframes, and mockups.

As a businessman, you may not be a techie, and yet you know that you need to figure out how to generate a requirements list for the product you envision. If you can’t clearly describe your needs, and make sure that those are completed, you cannot expect the final software development project to be successful.  

What you need is a requirements document – something that can be presented to developers when you submit a request for proposal (RFP). If you don’t present a detailed document, no developer or team can provide you with an accurate cost to develop an app.

So, let’s take a look at how to define requirements and how to write a software requirements specification.

You must begin with a statement of the overall purpose for the software. In the case of Microsoft Word, for example, the large purpose was to develop a word processing program that would be user-friendly and contain the features that typical users would want. You must first define your general purpose too.

The requirements document will end up being the basis for any agreement you finalize with a software development individual or firm. Remember this as you craft it. Also remember that, because you are not involved in the “how” the developer you choose may have important questions and suggestions that he will alter or add to the document.

Begin with a requirements analysis – the larger objectives – and list these, knowing that you will be filling in much more detail later. These are rather like section headings. One section for Microsoft Word might have been, for example, “page layout options”.

Of course, the issue here is how do you get to a comprehensive list without leaving anything out? This will require some research on your part, but there are some human and web resources to use.

Conduct discussions with your team/staff. Set a period of time during which they can brainstorm about requirements and submit them. Either you or a designated staff member should scour the web for RFP’s for similar software. Sometimes, software development companies will have requirements list templates published on their sites. 

Use reverse engineering. Take a look at the similar software that a competitor has if you can access it. Outline the key features. Next, look at online manuals, reviews, product description pages, online tutorials, and even video demonstrations of similar software products. As you review these, requirement ideas will come.

As your list of requirements grows, you will find that you can construct logical groupings. Synthesizing these will bring logic to your larger list and also show you where you can merge and/or delete duplicates.

Going back to “Word” as an example, one logical group would be the physical layout options to give users – margins, spacing, justification, tabs, etc.

If your desired app is complex, you may wish to scrap the idea of a single document and divide your requirements list into two or more, based upon the groupings you have identified.

If your process has been agile, and you have utilized reverse engineering, you will reach a point where there are no longer ideas coming in to you or your team, and your investigations of other products no longer suggest something new to you. At this point, you can probably be confident that you have a comprehensive list.

Structural Tips for Technical Requirements Documents

Generally, you will want to divide this document into two sections – The Application Overview and The Functional Requirements.

The Application Overview

This is the section that speaks to the “big picture.” You identify the purpose and the objectives of the app you want to be developed.

Who are the users of this product? Objectives will be very different for a product you want for in-house business use vs. an app that you want to be developed for purposes of marketing and revenue generation.

For In-House Use
You will need to define the business process that your app will address. And you also need to address how it must interact with other existing systems you have.

If you are replacing a part of a legacy system, the development team needs to know this. Bootstrapping can be complex and require a lot of technical detail. No development team/firm can give you a projected cost without the details of the legacy system. Your IT department will need to be heavily involved here.

For Marketing/Sale Purposes

Having a clear picture of your user demographic will drive a lot of the decisions that are made in development. Any development firm will need to understand your target audience.

Marketing a product to individual consumers involves specific demographic information that will drive some of the development processes. An app that is built for millennials or younger will have very different elements than one developed for an older demographic.

Marketing a product to businesses will also entail differentiation in UX and UI, based upon the target market. A traditional conservative enterprise will demand different features than a progressive startup.

Functional Requirements

This is the “meat” of your product requirements list. It will provide all of the detail of what the application is supposed to do. You must be precise as you lay out all of the functions you want the app to perform because developers will use these as they code the app.

You will have multiple sub-sections here, each of which will be devoted to one function.

Suppose, for example, that you want a travel reservation app. Bookings will be one of your sub-sections, and you will need to list all of your requirements for that function. This is considered a type of object-related functionality.

You can also list requirements by feature. This would be in the case of a word processing program – features might include such things as file management, editing, formatting, etc.

There are also certain functions that are common to all apps, as follows:

• What type of security features do you need? For an in-house app, for example, you may need to have functions in place for user permission. For a travel app, you will need security measures that protect personal and financial information.
• What types of modification or customization will users be allowed to make? This is especially important for an in-house app. If you are developing a project management app to market, what customized feature options will you be providing a user?
• Performance and usability are also common to all apps. How fast must pages or files load? Be specific. What is your goal for the speed of navigation? All of these things are a part of UI, and the development team must understand your requirements for them.

Ready for the RFP

Once your requirements list document is finalized to the best of your ability, you are ready to submit it for proposals and ultimately make a software vendor selection from the responses you receive.

1. Do not be surprised if a vendor contacts you for further explanation and detail. You may not have provided everything they need to create a final proposal for you.
2. Never consider a developer/firm that does not have a significant portfolio to share with you and references you can contact personally.
3. Do not make cost the only consideration. Get a feel for how the developer or firm collaborates with their clients and makes their clients a part of the “team”. You need involvement throughout the process, on a regularly scheduled basis, if only with the project manager.

If you are ready to get this app on the road to development, Romexsoft is ready too. Even if you have not fully developed your product requirements list, we have a requirements list template that will ensure you have covered all of your bases!