Capturing Functional Requirements with Use Cases and User Stories

The first step in defining a new product, service, process, or system is to define requirements, i.e., specific functional or non-functional requirements.

• Functional requirements describe how the product or service meets customer needs. This includes features and functionality in use cases that document how users will interact with the product or service.
• Non-functional requirements are operational and product attributes that are sometimes not obvious to the user, including performance, usability, durability, security, and financial (price and cost).

Edit this illustration – functional requirements vs non-functional requirements

Functional requirements can be thought of as what the product needs to do for the customer, while non-functional requirements can be thought of as constraints that the product or service needs to be designed to meet.

Functional requirements capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions the system is required to perform. In software development industry, use case approach have quickly become a widespread practice for capturing functional requirements. This is especially true in the object-oriented and UML community where they originated, but their applicability is not limited to object-oriented systems.

What Techniques for Capturing Functional Requirements?

Functional requirements are typically captured in the form of use cases or user scenarios. These terms are sometimes used interchangeably, but they actually mean slightly different things.

• Use cases focus more on the system and what it must do to meet the needs of users.
• User stories, on the other hand, show product functionality from the user’s point of view, specifying user roles and specific goals they want to achieve.

Capturing Functional Requirement Using User Stories

User stories are a lightweight method for quickly capturing the “who”, “what” and “why” of a product’s requirements. Simply put, user stories are ideas that express the needs that users want. User stories are short, and each element usually contains less than 10 or 15 words. User stories are “to-do” lists that help you identify the steps along the project path. They help ensure that your process, and the resulting product, meet your requirements.

User Story Template

User stories only capture the essential elements of a requirement:

• Who it is for?
• What it expects from the system?
• Why it is important (optional?)?

Here is a simple format of user story used by 70% of practitioners:

Role – The user should be an actual human who interacts with the system.

• Be as specific as possible
• The development team is NOT a user

Action – The behavior of the system should be written as an action.

• Usually unique for each User Story
• The “system” is implied and does not get written in the story
• Active voice, not passive voice (“I can be notified”)

Benefits – The benefit should be a real-world result that is non-functional or external to the system.

• Many stories may share the same benefit statement.
• The benefit may be for other users or customers, not just for the user in the story.

How to Identify Functional Requirements with Use Case?

In order to fully understand the functional requirements of the system, you must know who the system is for, i.e. Who will use the system?

The answer to this question is: the actor in use case analysis

Use cases or user stories capture functional requirement which the behavior may be expressed as services, tasks or functions the system is required to perform. Use cases define the interaction between the user and system service which can help define the functional requirements of the system under developed. Or in other words, what the product or service needs to do to satisfy the customer’s needs and wants.

A use case starts with an “actor” or “who”, a specific user of the product or service.

An actor is a person or an external system that plays a role in interacting with the system. Instances of actors can be individuals or external systems; however, each actor provides a unique and important perspective of the system, a perspective that is common to each instance (actual person / user) of the actor.

Real User vs Use Case Actor

In order to fully understand the purpose of the system, you must know who the system is for, i.e., who will use it. The different user types are represented as Actor (roles).

The difference between a role and an individual user is that a role represents a specific class of users, rather than an actual user. Different users can play the same role, in which case each user constitutes an instance of an actor.

This distinction between actors and instances of actors is illustrated in the following:

The Figure below shows a case where Mary and John are customers of a vending machine. When they use the vending machine, each is represented by an instance of an actor called customer that expects to have access to certain functions of the system (in this case the printing of buy food).

Edit this vending machine illustration

Conversely, the same user can play multiple roles (i.e., the same person can play different roles).

For example, Dr. Gates, who is a committee member of the Computer Society. He is responsible for managing the membership management system, such as adding and removing user accounts. When he does this, he plays a role called Administrator (Actor). However, the same Dr. Gates may also be a member of the Computer Society. In this case, he would also play a role called “Member” (Actor)

How to get the functional requirements by identifying the use cases of the system

A use case can be identified by asking stakeholders the following types of questions (to which they must answer from the point of view of the actors):

• What are users in this role trying to accomplish?
• To fulfill this role, what do users need to be able to do?
• What are the main tasks of users in this role?
• What information do users in this role need to examine, create, or change?
• What do users in this role need to be informed of by the system?
• What do users in this role need to inform the system about?

Note That:

Use cases are often used as a means of discovering and representing functional and system requirements, as a use case defines the interactions and tasks needed to execute to fulfill a specific business goal. However, they are usually not a good way to define non-functional requirements, such as system performance and quality.

References

• User Story vs Use Case for Agile Software Development
• What is User Story?
• What is User Story Mapping?
• Identify User Requirements with Use Case Diagrams
• How to Use Wireframes with User Stories?
• Use Case Driven Approach for Agile Development
• What is Use Case Specification?