One time when my Skype team and I were refining backlog items, we started to look at a ticket that I accidentally made with just a title and no further details. Initially, the developers were poking fun at how specific I was and also mentioning that a good Jira ticket is like a good joke: no explanation is required!
If only this was so simple!
In the real world, the ticket in Jira should be functional not only without explanation, but without the author being there to answer questions. The team should have a document that they can pick up, dissect, and turn into a piece of software that perfectly mirrors the product manager’s vision and intentions.
To that end, probably the most crucial element of such a ticket are functional requirements listed usually at the end of it. What are they? How can you best write them to ensure that your ticket speaks for you, even in your absence? All that and more in today’s article!
Functional requirements are the specifications of what a product or its element should do. This can refer to the features, functions, and behaviors that the product must provide to the users. Functional requirements describe the desired outcome from the user’s perspective so it’s easier to understand the end result.
A functional requirement ticket should be clear, concise, and testable, and should align with the project’s goals and scope. The benefits of using functional requirements include:
Now that you have a sense of what function requirements are, let’s distinguish them from non-functional requirements.
Functional requirements refer to features the PM or user wants the system or product to do, such as filtering products by price, category, or rating on an online store.
An example of such a requirement would be:
On the other hand, non-functional requirements describe how the system or product should function, such as its performance, security, usability, reliability, etc. Non-functional requirements are usually written as constraints or quality attributes, which have a rationale, measure, and target value.
An example of such a requirement would be:
While generally, the functional requirements are to explain to the developers what the completed product should do for the user, one can easily sub-divide them into the following categories:
These are the requirements that describe how the system should handle data input, output, validation, storage, and retrieval.
For example, Google Maps should allow users to enter an address or a place name, validate the input, display the location on the map, and store the search history for future reference.
Use data flow diagrams or entity-relationship diagrams to illustrate the data flow and relationships. This will make it less confusing and will prevent confusion.
Business rules are used to define the logic, policies, and procedures that the system must follow to comply with the business objectives and regulations.
Continuing with the Google Maps example, it should calculate the optimal route based on the user’s preferences, such as shortest distance, fastest time, toll avoidance, etc.
Include decision tables or decision trees to show the conditions and actions for each scenario. It will be an effective confusion-cleanser as the data flow diagrams from the previous category.
Within those requirements, you’ll also need to specify the information that the system should generate and present to the users or other stakeholders.
In this case, Google Maps should provide users with directions, distance, travel time, traffic conditions, etc. for their selected route:
Again, make it visual with mockups or wireframes to show the layout and content of the reports.
These requirements define the tasks and activities that the system administrators or managers should be able to perform to maintain and control the system.
Google Maps should allow administrators to manage user accounts, permissions, settings, data sources, etc.
Tip: Include use cases or user stories to describe the goals, actors, and steps involved.
With this, a system admin (or system itself) will be able to determine the access rights and privileges that different users or roles should have to the system’s data and functions.
Google Maps should restrict access to certain features or data based on the user’s subscription plan, location, device, etc.
Similar to administrative functions, it’ll be helpful to use access control matrices or lists to show the permissions for each user or role.
From an audit perspective, you should specify how the system will record and monitor the actions and events that occur within the system.
Google Maps should log the user’s searches, locations, routes, feedback, etc., and allow administrators to view and analyze the audit trails.
You can use activity diagrams or sequence diagrams to show the flow and sequence of the actions and events.
Now, in order to get the most out of the functional requirements in a ticket, those items need to best represent your intent for an update even when you’re not around to clarify. To that end, I suggest being careful about the level of detail you write down in those requirements.
Too much detail and you risk patronizing your development team and not leaving any room for some creativity. Provide too few details and you might not get what you asked for. How can you achieve that? Focus on the user perspective and the end result that should appear when following the instructions.
To illustrate this point, consider how, “a user can pay for the product” is way too vague and there is a risk that the UX will be poor and not all payment options will be covered.
On the other hand, you might write something like, “In the cart, in the left-right corner, there is a “pay” green button, size 50x100px. When clicking it a square appears offering a table with three payment options: credit card, PayPal, and ApplePay. Each option has its own border and once clicked, contacts the respective API with the amount needed to be taken for payment (…).”
Now, this is too much. A designer should be left with a little more freedom and a PM should not be asking for a specific placement and color of UI elements. The bullet point is also too long and should be split into several ones.
However, the sweet spot should sound like this, “In the cart view, the user can pay for products with a credit card, PayPal, and ApplePay.”
This is clean and simple. However, never assume anything is as such and instead always confront the written functional requirements with your development team to make sure those are understood correctly.
In fact, you might want to run a draft, high-level version with them as early as possible, rather than obsessing over providing something more final and complete. Allow them to have a say so they also share the responsibility and the feeling of ownership.
One additional thing you should consider is to ask what could go wrong with the user flow and make sure those “error scenarios” are covered in the requirements.
You might say something like, “If any of the payment options fail, return the use to payment option selection. If possible, display the error. If the payment doesn’t go through, mark the user as “need follow-up” in the sales team CRM.”
While this is long and could be split into more than one bullet point, the team has a full understanding of what happens during this rather common failure scenario. In fact, you can involve your QA engineer(s) in the process of finalizing the functional requirements and frame them as a testing plan, so they know what needs to work and how.
Before you consider your functional requirements list completed and closed, go through those questions to make sure you didn’t miss a spot:
[ ] Is the end result clear from the ticket?
[ ] Are the requirements easy to read?
[ ] Are all the flows covered?
[ ] Are all the external resources linked/attached?
[ ] Does the dev/design team have space for creative freedom?
[ ] Are all the error cases covered?
[ ] Can this list be used as a testing plan?
[ ] Did the developers understand and agree with the list?
[ ] Did the developers estimate the effort needed to complete the task?
When approaching functional requirements with your team, the differentiating factor will be the time needed to finalize the list. If this takes a lot of time and you need to go through a few difficult conversations before settling on some compromise, you have a long way to go!
On the other hand, if you bring drafts of the requirements to your team and signing off on them is super easy, you’ve reached the level of mastery that this article aimed to help you achieve.
Good luck! As always, feel free to drop any questions you may have in the comment section below.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Kristina Bailey discusses the careful balance of knowing the business outcomes you want to achieve while balancing customer outcomes.
Augmented products leverage technology and additional services to provide enhanced functionality, convenience, and value to users.
ATDD is an agile methodology involving collaboration to define acceptance criteria before starting any development.
Brian Peterson discusses how he creates empowered teams by establishing a shared vision across teams, organizations, and the company.
Learn more →
