What Goes Into a Functional Specification?

If you find yourself in a business analyst role on an IT project, it’s likely that at some point you’ll need to create a functional specification. But what is a functional specification? Why do you create a functional specification? And, perhaps more importantly, what goes into a document like this?

The purpose of a functional specification is to define the requirements to be implemented by the software solution. Now, as business analysts, not all aspects of our solutions are software-based. A perfectly legitimate solution to a business problem could involve a business process change, organizational change, or even a configuration adjustment.

But since so much of business today is supported directly by IT systems, many times solving a problem means upgrading or building new software…and that means specifying functional requirements.

Functional Specifications Take Many Forms

Depending on your methodology and business analysis practices, a functional specification can come in a variety of different formats. Let’s look at a few of the most common formats.

  • Functional Requirements Document
  • System Requirements Specification
  • Business Requirements Document (contrary to the name, they commonly do not include only business requirements but also functional, software requirements)
  • Use Cases
  • User Stories

Whatever template is in place at your organization, the purpose of the functional specification is to capture what the software needs to do to support a business user. Often it is reviewed and approved by both business and technical stakeholders. The business users confirm that yes, this is what they really want the system to do. The technical users confirm that, yes, these requirements are feasible, implementable, and testable.

The Functional Spec is Where Business Meets IT

The functional spec is the moment of true alignment between business and IT. Other documents, such as business process models and business needs assessments might be primarily reviewed by business stakeholders. More technical documents such as technical design specifications, are often primarily reviewed by BAs, QAs,  and technical stakeholders.

It’s the functional spec that sits in the middle and holds everything together.

Early in my career I tended to create 50+ page software requirements specifications which included information about the project, project team, open issues, environment, assumptions, dependencies, constraints, key dates, business model, data requirements, and, finally, the functional requirements. (The functional requirements typically took up all but 10-15 pages of these long documents.) These documents were thorough, but they lacked spunk.

As I matured as a business analyst, I gravitated towards a shorter scope document that consolidated many of the overview sections in my earlier documents along with a set of use cases to drill into the functional details. I’ve also been on a few agile projects where user stories were the preferred format.

Whatever the format, my focus was creating alignment between what the business users wanted and needed the system to do and what IT was prepared to build for them. And that’s really the essence of the functional spec.

What Actually Goes Into this Spec?

You might be wondering what you actually need to put into your functional specification. In addition to contextual information about the project, a functional specification includes a list of features and functions to be supported by the software. How these features and functions are represented depends largely on the template in use.

Let’s take a quick look at our examples again, this time adding more detail about what the functional requirements look like in each case.

  • In a FRD, SRS, or BRD, functional requirements are typically represented as “system shall” statements. You’ll typically have a list of system shalls, often organized in tables by feature with a priority identified. For example, “The system shall enable course participants to submit a question.” or “The system shall enable the course instructor to view all course participant questions.”
  • In a Use Case, functional requirements are typically represented as a series of steps. The use case puts a collection of functional requirements into the context of user action, which typically eliminates a lot of ambiguity that makes it’s way into an out-of context list of system shalls. For example, “Course participant selects to submit a question. Course participant provides their name, selects a question category, and provides a textual question. System sends an email to the course instructor containing the information provided by the course participant.” (We cover documenting use cases in a lot more detail in our Use Cases and Wireframes course.)
  • In a User Story, functional requirements are typically captured in the following syntax: “As a {user}, I can {do something} so that {I receive some benefit}. When used appropriately, the user story syntax is brilliant at capturing user goals, functional requirements, and business benefits altogether in one concise statement.  For example, “As a course participant, I can submit a question so that I get my concerns about the course materials addressed” and “As a course instructor, I can view all course participant questions so I can respond in a timely manner.”

Each of these ways of capturing functional requirements has its pros and cons.

  • System shall statements are easy to track in requirements management systems but difficult to implement and test as they are often presented without context.
  • Use cases provide great context which helps get the right functional requirements approved and implemented, but it’s also easy for the scope inside a use case expand while meeting user goals (which may not align to business goals) or for individual requirements to get lost in larger use case documents.
  • User stories link together business benefits, functionality, and user goals and are often at the right level of detail to facilitate easy planning, but often lack the detail that’s needed to implement. It is also easy to lose the big picture in the midst of working through individual user stories.

The approach you choose will often be dictated by organizational standards. In the absence of standards, you get to define your own. It’s a good idea to start by asking the business and technical stakeholders what they’d like to see in a spec, as this can help you avoid a lot of issues down the line. Believe me, I know from some personal, painful experiences.

I’ve made no secret that my personal favorite approach to specifying functional requirements is use cases with accompanying user interface wireframes, and a short scope statement to get aligned around the big picture. (There are templates and work samples covering this approach in our Business Analyst Template Toolkit.)

Regardless of the approach you take, keep your eye on the goal of meaningfully aligning business and IT around a common understanding of what the software solution needs to look like. Whenever you have doubts, this goal will help you find your path.

>>Learn More About Use Cases and Wireframes

UseCasesWireframesIf you’d like to learn more about how to create a functional specification using use cases and wireframes, join us for Use Cases and Wireframes – a virtual, 4-week course. You’ll learn a time-tested approach for creating a use case and associated wireframes. With the professional credit option, you can earn 8 PDs/CDUs too.

 

Stay informed about new articles and course offerings.

(You'll get a free step-by-step BA career planning course too).

Click here to learn more