Use Cases and Scenarios
Once you have developed an initial set of Functional Requirements during the Requirements Gathering phase you will have a good understanding of the intended behavior of the system. You will understand what functionality is desired, what constraints are imposed, and what business objectives will be satisfied. However one shortcoming of a traditional 'laundry-list' of requirements is that they are static and don't concern themselves with the different business processes that need be supported by one feature.
For example, in our fictitious online library system, the functionality for managing returns would need to handle the separate situations where a borrower returns a book early and when he/she returns it late. Although the same functionality is involved, they are different situations and the system would need to handle the separate conditions in each use case. Therefore use-cases are a valuable way of uncovering implied functionality that occurs due to different ways in which the system will be used. Also use-cases provide a great starting point for the test cases that will be used to test the system.
A use case is a definition of a specific business objective that the system needs to accomplish. A use-case will define this process by describing the various external actors (or entities) that exist outside of the system, together with the specific interactions they have with the system in the accomplishment of the business objective.
Types of Use Case
Use cases can be described either at an abstract level (known as a business use-case) or at an implementation-specific level (known as a system use case). Each of these is described in more detail below:
- Business Use Case - Also known as an "Abstract-Level Use Case", these use cases are written in a technology-agnostic manner, simply referring to the high-level business process being described (e.g. "book return") and the various external entities (also known as an actor) that take part in the process (e.g. "borrower", "librarian", etc.). The business use case will define the sequence of actions that the business needs to perform to give a meaningful, observable result to the external entity.
- System Use Case - Also known as an "Implementation Use Case", these use cases are written at a lower level of detail than the business use case and refer to specific processes that will be carried out by different parts of the system. For example a system use case might be "return book when overdue" and would describe the interactions of the various actors (borrower, librarian) with the system in carrying out the end-to-end process.
Typically you will start by defining the high-level business use-cases, and as the system requirements get defined, they will will be "drilled-down" into one or more lower-level system use cases.
Scenarios and User Stories
One related artifact is the "business scenario" or user story. These are similar to use cases in terms of what they seek to accomplish - a description of the how the system will carry out a specified business process to fulfill the stated requirements. However unlike a use case which is a step-by-step enumeration of the tasks carried out during a process (with the associated actors), a scenario is much more free-form.
A user story is typically a narrative that describes how a user would experience the functionality of the system. As the name suggests it is a "short story" that describes the tasks they carry out, what information they see and how they interact with the system. User Stories have become more popular with the advent of Agile Methodologies that emphasize customer collaboration, user interaction and simplicity.
Use Case Diagrams
These are diagrams that can be used to more clearly illustrate the set of use cases that are provided by the functionality in a system. The diagrams contain both the external entities that will be using the system (also known as "actors") and the discrete use cases (or goals) that the users will be carrying out.
These diagrams are typically represented in the UML modeling language (though other forms do exist) and will help the business analyst convey the relationships between the actors and their business goals and how the design of the system needs to support their different objectives with integrated business processes.
Relationship to Functional and System Requirements
Use cases are often used as a means of discovering and representing functional and system requirements since they define the interactions and tasks necessary for carrying our specific business objectives. However they typically are not a good way of defining non-functional requirements such as technical requirements or system qualities. A requirements traceability matrix is used to ensure completeness - namely that all functional requirements are covered by at least one business use case, and that all system requirements are covered by at least one system use case.
Relationship to Test Cases
Since you typically need to ensure that there is complete requirements test coverage for a successful quality assurance program, use cases provide a good starting point for the design of test cases that will be used to test that the system meets the specified requirements.
Once the requirements engineering actitivies have been completed and the business analysts are happy with the requirements definition, the test writers can create test cases based on the system use cases. This usually involves adding more detailed pre-conditions and post-conditions and writing different test cases "variants" of the same use-case to cover different testing scenarios. Part of this will involve the identification of the critical exception cases that could cause the system to fail, and the development of the necessary test data to ensure full coverage of all test conditions.