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 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.
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.
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 stories only capture the essential elements of a requirement:
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.
Action – The behavior of the system should be written as an action.
Benefits – The benefit should be a real-world result that is non-functional or external to the system.
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.
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).
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)
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):
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.
