Software Project Requirements 101: What You Need to Know To Get You Started

Photo credit Marius Klapatauskas

If you’re new to IT project management, you’ll likely hear your development team using terms you’re not familiar with.

And there will be activities and processes you may not yet know much about.

The requirements gathering process may be one of these.

You want to talk confidently with your team about the requirements gathering process for your project. However, you first need to understand it better.

Get familiar with this process with this primer on software development project requirements.

Let’s get you started.

Project Requirements – The Basics

This isn’t meant to be a full training course on requirements gathering. But, if you’re new to software development project management, you’ll need to have an understanding of this critical component of your project.

This article will give you the basics to build upon.

Why It’s Important to Get Them Right

Until this point in your project, you’ve likely gotten a high-level understanding of your customer’s business need. But you need to get many more details to ensure that the solution you deliver satisfies that business need.

By gathering more detailed requirements you’ll make sure you understand everything your client needs to solve their problem and deliver what they expect.

You want to deliver a product that satisfies your customer’s needs and expectations. Your project requirements play a significant role in doing that.  The requirements will provide a description of what the product should be.

And the product can’t be better than the requirements writers and the requirements produced.

For this reason, gathering, documenting, reviewing, and getting agreement on your project requirements is essential for the quality and success of your product.

Don’t take requirements gathering lightly.

Requirement Gathering 101

Your project requirements will provide information about the business need. Create the business requirements in a way that the end users/stakeholders can understand.

It’s important to provide as much detail as possible.  For example, you need to be clear about what the customer means when she says she wants a welcome page. There are many different ways it could be designed so you want to know exactly what she has in mind.

When you’re discussing the project requirements, it’s important to speak in language and terms that are clear to non-technical users.

In addition, you’ll have more technical requirements about how the solution will function, too.

Once your requirements are gathered and documented, you need to review these with your customer and get approval that they’re correct.  This ensures that the team is indeed designing and developing to the customer needs.

Different Types of Project Requirements

There are various types of software project requirements that serve different purposes. Here’s a high-level explanation.

• Business Requirements – Business Requirements explain how the solution will address a specific business need. They relate to the need or problem that you’ll address through the project or product you’re delivering.  The business requirements are usually described at a high level.  However, they must provide enough information for the development team to ensure they’re addressing the customer need.  An example of a business requirement for a client who wants to allow users to pay bills online would be to provide a user payment interface and access to their account information.

• Functional Requirements – Functional requirements explain what the software must do and the steps it will take to carry out that activity.  They’re very detailed and explain the “how” of your solution. For the example above regarding a bill-pay solution, the functional requirements will go into who has access, how they’ll access the system, how data is managed, etc.

• Non-Functional Requirements – Non-functional requirements (NFRs) can be easy to forget about since you don’t really see them. They are behind the scenes making sure that everything acts as it should. They’re performance requirements, such as reliability, usability, scalability, and performance, to name a few.  To help ensure you don’t forget about them, I’d recommend Gonçalo Borrêga’s fun explanation of non-functional requirements in his article on Outsystems. He explains that while the functional requirements are like Disney princesses, the non-functional requirements are like the Seven Dwarfs – not the stars of the show, but you’d have no show without them. Pay attention to them now or you’ll be doing so later when things don’t go as planned. In our bill pay example above, one NFR that needs to be addressed is security. How will you ensure the user’s data is secure as she pays her bill online?

• Don’t forget Data – Your team will need to include information on any data that’s part of your project. Include as much detail as possible as it relates to data to be included. You may have existing data that must be considered or shared between systems so plan for it, if so. Again to our bill pay example – how will data be shared between your bill pay system and then bank? How will payment history data be stored? What information will you need?

•  Process – It helps to understand the process your users will go through in using the product. This will help uncover information you’ll need for the design. For example, you can see other systems that the solution must integrate with, or other components and behaviors.

Requirements Gathering Techniques

There are various ways to go about gathering requirements for your project:

• Interviews – You can conduct interviews either one-on-one or in small groups. If you’re doing group interviews, it’s easier if you bring together a group of people who have the same understanding or do similar tasks.
• Focus Groups – Bringing together user representatives from different areas to present information about needs and problems. This approach can help you cover the needs of large groups in a more effective way.
• Prototype – If you create a mock-up or prototype of the solution, you can have users interact with it and give feedback and input.
• Brainstorming – Brainstorming can be a great activity for your project particularly if you’re creating a brand new solution.  You can assess all the ideas afterward and prioritize what fits best.
• Observation – This involves watching users as they interact with an existing system or a prototype. As you watch users, you’ll be able to gather more information about how they interact with a system. Some users may forget to tell you about small steps in a process. Watching users can keep you from missing something. Ask questions as they carry out tasks in order to gather more detail.
• Document Analysis – Review documentation of existing solutions that explains the current “as-is” state of any software solutions you’ll be including as part of your project.
• Requirements Workshop – This is a structured, facilitated session in which you bring select stakeholders and subject matter experts together to define or refine project requirements.

Scroll to the bottom to get this article in PDF format for easy reference!

Document your requirements 

• Functional Specifications Document – The functional specifications document provides a high level of detail about the product’s intended capabilities and appearance, and how the user will interact with the software. The developers will use this as a guide as they create the solution.

• Design Specifications Document – According to Philosophe.com, “The design specifications address the ‘look and feel’ of the interface, with rules for the display of global and particular elements.” This document can get very technical. It gives more information about how the system will function and perform.

• Diagrams & Process Flows – You may have flow diagrams that show a user’s path through the software. You might also have diagrams that show the logic and flow according to different decision points in your data flow or user experience. Process flows can show the steps and decision points that a user undertakes as she uses the software.

• Wireframes – ExperienceUX explains that “a wireframe is a layout of a web page that demonstrates what interface elements will exist on key pages.” It looks like a drawing or mockup of the page. It allows you discuss the elements and behavior of a web page design more easily with a user.

Get customer sign-off

If you’ll be working from a set list of requirements that should not change throughout development, make sure to get a final sign-off on the requirements. This goes for designs, process flows, etc.

Other Points To Consider

• Be clear on your project scope.  When you know the scope and acceptance criteria for the deliverables, your requirements will be much easier to approach.

• As stated above, review the requirements for accuracy with your stakeholders. Don’t just assume you got them right the first time.

• Gather and document your project assumptions, dependencies, and constraints.  These can impact your project and need to be factored in.

• The team may not be able to deliver everything the customer requests. Have a good understanding of the priorities. There may be things your client says they want that are actually “nice-to-haves” rather than real priorities. It’s good to know the difference.

• Make sure to dig deep when gathering details of the solution. Details such as data retention policies, the number of licenses, compliance considerations, and reporting needs are easy to overlook but play an important role in the success of your solution.

If you found this helpful you may be interested in this post: Project Planning Cheat Sheet. It covers how I approached ensuring things were included as I took on more complex projects.