Functional Requirements
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.
Use Cases
A use case defines a goal-oriented set of interactions between external actors and the system under consideration.Actors are parties outside the system that interact with the system. A use case is initiated by a user with a particular goal in mind, and completes successfully when that goal is satisfied. It describes the sequence of interactions between actors and the system necessary to deliver the service that satisfies the goal. It also includes possible variants of this sequence, e.g., alternative sequences that may also satisfy the goal, as well as sequences that may lead to failure to complete the service because of exceptional behavior, error handling, etc. The system is treated as a “black box”, and the interactions with system, including system responses, are as perceived from outside the system.
Thus, use cases capture who (actor) does what (interaction) with the system, for what purpose (goal),without dealing with system internals. A complete set of use cases specifies all the different ways to use the system, and therefore defines all behavior required of the system, bounding the scope of the system.
A good use case
- Starts with a request from an actor to the system
- Ends with the production of all the answers to the request
- Defines the interactions (between system and actors) related to the function
- Takes into account the actor’s point of view, not the system’s
- Focuses on interaction, not internal system activities
- Easy to read
Scenarios
A scenario is an instance of a use case, and represents a single path through the use case. Thus, one may construct a scenario for the main flow through the use case, and other scenarios for each possible variation of flow through the use case (e.g., triggered by options, error conditions, security breaches, etc.).
Functional requirements specifies a function that a system or system component must be able to perform. It can be documented in various ways. The most common ones are written descriptions in documents, and use cases.Use cases can be textual enumeration lists as well as diagrams, describing user actions. Each use case illustrates behavioural scenarios through one or more functional requirements. Often, though, an analyst will begin by eliciting a set of use cases, from which the analyst can derive the functional requirements that must be implemented to allow a user to perform each use case.
Difference between Use case and Requirement
- Use cases approach is considered a more efficient means of collecting essential requirements, whereas functional requirements approach ensures a complete specification that can then filter out redundancies, overlaps, and unwanted features.
- Use cases approach takes into account at the outset external actors (users, processes, agents, etc.) and how they interface with the system, whereas the functional requirements approach the problem from a solution angle (how can we employ this feature to solve our problem?)
- Use cases capture actors, users, methods, domain knowledge, unique techniques, etc. Use cases can lead to complete packaged solutions. Functional approach capture product categories, product variants, market differentiations. Functional approach can help develop finely tuned release strategies where functionality is developed and layered over previous releases.
Another way to describe is that use cases is more an user-oriented spec and functional approach is a developer spec. From a language and communication perspective, it is said that use cases approach leads to easier to understand documentation that is already cast in the end-users’ language idioms. On the other hand, functional approach is what makes the system complete and integrated whole.
Both perspectives are essential for a complete, useful system. Ideally, one has to map to the other.