Writing Use case effectively

Before discussing about what goes into Functional Specification document, let us understand what is a Functional Specification(FS) document and why we need it.

Functional specification is the document containing requirement in detail, helping business in understanding and confirming the requirement. Moreover, it gives developer details of the requirement Business requirement document is the other artifact that has details about the requirements. But it list requirements at high level and not the details. FS contains requirement in detail, including validation and alert messages etc.

A complete Functional Specification document contain purpose, scope, assumption and use cases etc. This article is about the typical format of use cases that would help business in reviewing the requirements and developers in implementation.

Though FS document template might vary depending on the requirement, I am listing high level items that should go inside use cases.

Use Case number – Generally starts with UC-01. Purpose of putting number against use case is to have requirement traceability matrix.

Use case name – Title of the use case. E.g. Login or Signup

Description – Business purpose of the use case. I recommend writing it in form of user story like “As a user, I should be able to see the login page so that I can see the home page after supplying valid credentials”.

Actors – e.g. Admin, Customer etc. These are different roles who will be using the function/use case.

Precondition – These are the conditions that should exist for the use case. E.g. User should have logged into the system in order to see the ‘my account’ page.

Success – End result of the use case. e.g. if user is adding items to the cart, user should be able to see items added in cart.

Failure – Failure conditions. e.g. User is not able to see the item added in cart.

Main flow – This section contains steps required to achieve/realize the use case. Also called as Happy path scenario- generally it is written in term of user or system.

Alternative flow (if required) – These are alternative flow of the use case. E.g. if there is a user case to update items in the cart, alternative scenario will be that quantity is not available or item is back ordered. This section is optional and there can be multiple alternative flow. Generally, its number start from the step of the main flow. E.g. if alternative flow start from step 7 of the main flow, alternative flow could be named as 7a.

Notes – We can put any other instruction here.

Validation including character types, limits, messaging/alert etc.  We can either put it in notes section or there can be a separate section for validation and messaging.