Functional Requirements Table

Information Gathering

Before we talk about how to create a functional requirements table, let's first acknowledge the importance of gathering information early on in the project.  The process of getting to a draft list of user stories and breaking them down into functional requirements can be very challenging.  

At your first meeting, you’ll likely take copious notes and ask lots of questions.  You'll walk away with answers but even more questions.  If you feel like the initial weeks in a project are ambiguous and vague, that is absolutely normal.  Remember that many times you are starting with no documentation which is why we have a methodology to follow.

One goal at the start of the project is all about gathering information.  You can start this process even before your first meeting with your client.  Your ultimate goal is to get to the root cause of your client’s problems or gain insight into the core problems that may be solved by this updated or new system.  Before you a setup meetings and do observations you may need to start with identifying all the stakeholders of the project.  Once you know who key stakeholders are you can set up a time to interview them, conduct surveys, or observe your client(s) in action.  As you are doing these things you should be identifying symptoms and asking "why" until you drill down to that root cause.  Once you know the root cause you can then start devising a list of user stories which we'll break down into requirements. Also keep in mind that to gain a better understanding of the problems in the current system or the needs of the new system, you will likely need to draft some form of system diagram models that depict the As-Is system.  This can aid you in better understanding the system in place which helps you in your root cause effort.

How can we document and prioritize our functional requirements

Once you have broken down a user story into its functional requirement pieces, it's important to understand the priority of each underlying functional requirement.  Don't assume that every possible requirement is absolutely necessary.  A user story can take many shapes based on people's opinions and preconceived notions.  

The prioritization method we'll use is a simple one called the Moscow Method.  Here's how it works.  To prioritize each functional requirement within a user story, your team will review them one by one and ask if this requirement something we “Must Have”, something we “Should Have”, something we could“Could Have”, or something we “Won’t Have”.  Note: It’s just as important to call out something that is out of scope as it is to call out things in scope.  See the Latinitas example below of a single user story broken down into its underlying functional requirements by priority.

Latinitas User Story Breakdown.png

Tips on creating a Functional Requirements Priority Table

Start with the template or feel free to reference examples on the Resources page.  The end goal is to create a row for each user story and then break that user story out into its functional requirement by priority.  Use the methods talked about above to help figure out the information, the user stories, the functional requirements, and then the priorities. 

Also, here's one more simple tip on priorities.  Listen closely to what your client says in discussions.  If they say something like “This one thing we need is ….”, make sure you note that.  If they say “It would be kind of cool if we could ….”, then consider what that means for priority. Create a first-cut of the functional requirements and priorities.  Then run this by your client to get their buy-in on it before moving on to the next stage of the project.

  • Pro Tips:
    • It's highly like you may need to create multiple user stories for a single user because a user could have multiple needs and uses of a system
    • Also, remember that a user story should be scoped to the right size.  If you create a user story and guesstimate it would take longer then 2 weeks to complete, you need to break it down into multiple smaller stories that focus on more specific features or capabilities.

Template & Examples