Imagine you’re an architect who’s just been tasked with building a house for a client. Instead of taking the time to gather all the necessary information, you decide your brilliant idea needs to get built right away — so you head straight to the lumber yard and start construction the next day. Of course, no matter how great you imagined your new house would be, the end result is probably not going to make either you or your client happy.

Building a mobile app is demanding enough when you plan exactly what you’re building. On the other hand, if you don’t start with a crystal clear picture of what you want and how you’re going to do it, developing your app will likely involve a lengthy, painful stream of delays, errors and dissatisfied users.

It’s a lot easier to add another bathroom to your blueprints before you start building than it is halfway through construction. Even if you’re on a tight deadline, gathering requirements is essential; it ensures that you and your audience are on the same page, avoiding gaps and misunderstandings that will stretch your timeline beyond the limit. Whether your app is simple or complex, intended for in-house use or universal distribution, gathering requirements before you start development and design is essential.

How to Gather Requirements

Gathering requirements typically involves interviewing a variety of people who all have a perspective on what an app needs to do.

Sources of your information will usually include:

  • Key stakeholders: Individuals from different parts of the organization, including business and IT, who will be invested in the app’s success.
  • Domain experts: People who have a high level of knowledge about a certain field — whether it’s mobile development, specific tools and technologies, or the company’s industry.
  • Audience members: The intended users of the app, or people who are representative of such users.

In order to capture requirements efficiently, it’s best to use a standardized form for your interviewees to fill out. Form fields might include:

  • The individual suggesting the requirement.
  • A brief description of the requirement.
  • The importance of the requirement to the project.
  • An explanation of why the requirement is necessary.

Writing a Requirements Document

Once you’ve extracted enough information to feel confident moving forward, you can assemble your findings into a coherent mobile app requirements document. The chief concerns for this document can be split into three parts: business requirements, technical requirements and scope.

A (non-exhaustive) list of questions that your document should try to answer follows below.

Business Requirements

  • What are the goals of your app? What are you trying to achieve, or what problems are you attempting to solve?
  • Who is the app’s intended audience, and what will they use the app for?
  • What features and functionalities will your app provide?
  • What is your app’s business model? Will it be monetized or will it support your company’s other products and services?
  • What are the legal or regulatory limitations on the app?

Technical Requirements

  • What platforms (iOS, Android) and operating system versions will you support?
  • What are your current infrastructure resources in terms of servers, databases and software? Do you need to secure additional resources before you begin or before release?
  • How will you protect the security of users’ data and personal information?
  • What will your support and maintenance schedule look like after release? How often will you release updates and bug fixes?

Scope

  • What are the project’s budget and sources of funding? Can the budget be increased if necessary?
  • What is the estimated timeline for the project? What are the deliverables and when are they expected to be achieved?
  • Who will be working on the project and in what capacity? What roles will they play and how much time will they devote to it?

Although there are any number of questions that you can answer in your requirements document, it can be kept fairly high-level. It’s worth aiming to strike a balance between thoroughness and flexibility so that requirements can be added, removed, and modified as the project progresses.

Validating Requirements

After the requirements document has been put to paper, it’s advisable to then verify it with your original interviewees. Together, you should ensure that the document is error-free and that it accurately captures their intentions — that you have both the requirements right and the right requirements.

Before you start design and development, you and your colleagues can check the document for any of the following problems:

  • Requirements containing errors or incorrect assumptions.
  • Requirements that are unclear or ambiguous.
  • Requirements that conflict with each other.
  • Requirements that are infeasible or impossible due to technical, budgetary or time issues.
  • Duplicate requirements.

Once you and the review team have gone over the requirements with a fine-tooth comb, the team leader can sign off on the document and the design and development stage can begin.

Final Thoughts

Gathering software requirements is a little like getting your teeth cleaned; it might not be the most enjoyable activity, but eventually you’ll be glad you did it. By some estimates, 30 percent of software errors in production are due to omitted logic — the cause of which can be traced back to the requirements gathering phase.

Successful requirements gathering means taking the time to listen to and understand your audience, turning their thoughts and ideas into a clear set of plans. In the end, your application will be easier to build and maintain for it.

Tags: , , , , ,