A Complete Guide To Requirements Gathering

If a project goes into production after requirements gathering, and no one has taken the time to painstakingly document every decision, exception, specification, and assumption, were the project requirements really gathered?

The importance of requirements gathering is often underestimated on multiple levels. When budgets are thin, timelines are tight, and scope is creeping, requirements documentation tends to be the first deliverable to go and the last deliverable to be considered. This is surprising, especially when you consider that disregarding a thorough requirements gathering process means sacrificing a sound point of reference for checks and balances throughout production and QA, jeopardizing expectations between the client, your team, and the end users, and leaving plenty of room for error and ambiguity. All of this can very quickly eat into your margins (and your sanity).

At first glance, the requirements gathering process and requirements documentation can seem intimidating — but it doesn’t have to be. I’m going to shed some light on the importance of requirements, the process of requirements management and gathering, some techniques to consider, and approaches to writing requirements documentation. While requirements documentation may get complicated, the process doesn’t have to be. My goal with this article is to provide you a simplified, intuitive approach to requirements gathering and documentation.

What Are Requirements?

Starting with a basic requirement definition, requirements in digital can be categorized into two types: functional and non-functional.

For the purposes of this discussion, we’ll focus on these two types of requirements that we usually see in digital products and services. Of course, there are other types, such as legal and technical requirements, and depending on the context, the person in charge of handling requirements documentation may need additional training in technical writing, information mapping, and more.

What Are Functional Requirements?

For a digital engagement, functional requirements relate to a product’s functionality: its capabilities, usability, features, and operations as they relate to the intended purpose of the product. Often, functional requirements are clearly referenced as such in Functional Requirements Documentation (FRD). While a Statement of Work (SOW) outlines the high-level goals and requirements of the desired product, an FRD provides a more in-depth elaboration of these requirements, which are gathered as soon as a project kicks off and up until a project begins production.

Side note: requirements are not limited to the window of time before production: change order documentation, warranty documentation, etc. are useful forms of ongoing requirements documentation that occurs throughout a project — or even beyond the project! For as long as you work with a client, the documentation is ever-growing and ever-evolving.

Depending on the size and scope of a project, you might decide on a milestone between the SOW and FRD (as this timeframe can span for months). In this case, some teams create Business Requirements Documentation (BRD) to provide a formal midway sign-off — an expectation checkpoint — for all parties. This presents the opportunity for the Project Manager to confirm the team is heading in the right direction before getting too far down the road with deliverables.

What Are Non-Functional Requirements?

Non-functional requirements encompass anything not related to a product’s functionality: its performance, stability, security, and technical specifications, to name just a few types of non-functional requirements in the digital industry.

Functional vs. Non-Functional Requirement Examples

Both functional and non-functional requirements documentation are equally instrumental in their own ways. They exist hand in hand; one is directly affected by the other.

Even so, not all non-functional requirements correspond directly to a functional requirement. Server setup and configuration, for example, is a non-functional requirement that has an impact on an entire site’s stability, without a direct 1:1 relationship with any singular functional requirement.

Here are a few examples of functional and non-functional requirements, and how they are related:

• Functional Requirement: payment processing functionality
• Non-Functional Requirement: SSL certificate

While it’s 2018 and websites should have SSL certificates regardless, it’s especially important to do so if there is payment processing functionality implemented on the site. This is an example of a non-functional requirement (SSL certificate, an element of the implementation which affects security) directly affecting a functional requirements (payment, an element of the implementation which affects usability).

Here’s another example:

• Functional Requirement: tools and resources (PDF, infographics, courseware, spreadsheets) available for users, accessible via the Resources landing page
• Non-Functional Requirement: administrative panel file format specs (e.g. “The following file formats are valid for upload within the administrative user panel, in relation to the Resources page: .zip, .jpeg, .csv, .pdf”)

Per the functionality of the Resources landing page, users are able to access resources such as PDFs, infographics, courseware, or spreadsheets. This functionality is a feature and an operation of the page. It is a functional requirement.

The administrative panel file format specs, on the other hand, are a non-functional requirement; they are technical specs related to administrative functionality. They do not affect the usability of the end users. Yes, these specs do affect the usability of the administrative users, but it does not directly define what the product’s functionality is for the end user. This is a non-functional requirement.

The Importance Of Requirements Management

Requirements management is important for two main reasons:

• Requirements documentation serves as a point of reference to document the evolution of a project, its moving parts, and its implementation
• Requirements documentation serves as a blueprint for the client to better understand what to expect out of the project (the what, where, when, and why of the project).

In addition to outlining what they can expect, part of requirements management planning should outline what not to expect. Including an “Assumptions” and/or “Exclusions” section is a wise approach to eliminate the risk of the dreaded client imagination.

Let’s look at an example showing how requirements gathering is important as a point of reference and a blueprint for managing expectations:

Requirement Example:

• What: PayPal integration
• Where: Checkout
• When: Within step 3 of 4 in the checkout experience (after the shipping address webform, before confirmation)
• Why: An established integration (e.g. PayPal) is a better solution than a robust custom build integration for a payment service in this case because it easily meets client requirements.
• Assumptions
• Flat fee for all shipping & handling
• All shipping is within the U.S. (not including Alaska or Hawaii)
• Taxes do not apply
• Exclusions
• Custom shipping & handling fee calculations
• Shipping internationally, to Alaska, or to Hawaii
• Tax rules

Remember: the smaller the delta between client expectation and reality with their digital product, the happier your client is going to be with the end result.

The quality of your requirements management directly correlates with your ability as a Digital Project Manager to reduce “gray area” for client expectations.

A vast majority of the time, a client will be receptive to your limiting scope creep if it means you’re preserving their budget; if you educate the client sufficiently on why a feature will be addressed (or not addressed) and then document the logic behind that approach within the requirements, your client is far more likely to be collaborative (they usually love feeling involved, don’t they?!). They’re more likely to provide their approval, and further down the road when they’re doing User Acceptance Testing (UAT), they will have a head start on understanding the “why” behind your team’s solution.

Understanding The Requirements Gathering Process

While requirements gathering should start as soon as an engagement starts and throughout your entire project life cycle, the bulk of your requirements documentation for something like a full website build should land after discovery (content strategy, site mapping, wireframes, designs) and before development. It’s never too early to start gathering and documentation project requirements. In fact, start yesterday.

It’s never too early to start gathering and documenting project requirements. In fact, start yesterday.

Here are the steps on how to gather requirements, taking you through a complete requirements gathering process. These steps will help you to finalize requirements documentation through team collaboration, checks and balances, and client education.

Read the full article to learn more:
- Step-by-step guide on how to gather requirements
- The wrong way to gather requirements
- All-important requirements gathering techniques
- Expert tips on writing a project requirements document
- Requirements document template for free download

Originally published at www.thedigitalprojectmanager.com on November 6, 2018.