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 – and these can take many different forms depending on the methodologies in place at your organization. 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. A few of the most common formats are:
- 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 and User Stories, which is what we teach at Bridging the Gap.
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 were heavy and took entirely too long to write and approve.
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 with accompanying wireframes 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?
I’ll share examples of a use case and user stories. But first, let’s discuss the longer documents – FRDs, SRSs, or BRDs.
- In an 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 its 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.”
- You can use the link below to download my use case template – it’s absolutely free.
- 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 to 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 it’s easy to lose track of the big picture if you focus on user stories alone.
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.
The Importance of Use Case Thinking to Create Good Functional Requirements Specifications
And no matter what specification format you use to document your functional requirements, ensuring you get the right requirements requires use case thinking, often with corresponding wireframes.
When you think in terms of the interchange of a user and system interaction, you will get to the right level of detail in your software requirements and often discover requirements that otherwise will often get missed.
This is why we teach use cases as a core foundational skill at Bridging the Gap.
And if you want to learn more about that and get started right away, again you can download my absolutely free use case template below.
We build our profession one business analyst at a time, and success starts with you.
Download Our Free Use Case Template
And if you want to learn more about that and get started right away, again you can download my absolutely free use case template.