Architecture-First Use Cases to Data Scenarios
Overview
This is another article in the Architecture-First Strategy.
Both Use Cases and Data Scenarios are part of the Business Architecture. The goal of working though Data Scenarios is to thoroughly design the application to handle the core Use Cases. This is achieved by running though test data for the key scenarios.
Use Cases
Uses Cases are often diagrammed in UML and described in text form. As a word of warning, just like I use a custom development strategy, I don't follow UML in the purest sense. Sometimes, I refer to my version of diagrams as TML (Tony Marius language)
Now one key concept for Use Cases to work is understanding that they are requirements. They are the processed form of the bullet list of requirements that by themselves are not enough to describe a system. Good Use Cases can exercise the application without writing any code. The path through one or more Use Cases is called a Scenario.
Use Cases are written in the perspective of one or more Actors. There are many useful diagrams, such as Context and Activity diagrams that visually demonstrate the system.
Comparison to User Stories
It is important to note that Use Cases do not replace User Stories or visa versa. The current industry technique is to build applications with User Stories, but Use Cases will increase the quality of the application.
User Stories are course grain descriptions of the desired result from a perspective of the user. For instance, a User Story for the retail example could be:
As a user, I would like the ability to checkout so that I can purchase my items.
User Stories can be nested, but typically I have seen them setup as nested Features, User Stories and Tasks.
Use Cases, on the other hand, are detailed descriptions of the interactions needed to produce one or more results.
There are two types of Use Cases.
Business Use Cases
They are not concerned with the application and represent the pure business interactions.
System Use Cases
They are given to developers and contain information related to the application.
These documents contain references to buttons, tables, etc. and are another form of Functional Specs.
The Architecture-First approach prefers the Business Use Cases, because it is easier to help the stakeholders find out what they really want without narrowing their vision with technical details.
Use Cases and User Stories can be used together. Use Cases can be written first then modified into User Stories for Agile project management. .
Context Diagrams
Context Use Case Diagram
The Use Case Context diagram is a visual way to specify the application interactions. There may be many diagrams or a few combined diagrams. Generally, the Actors (such as Customer and Merchant) will interact in order to satisfy one or more Use Cases.
Often, the application is named System instead of Merchant as seen in the diagram. I like to stay with business based actors so that the Business Architecture is separated as much as possible from the Technical Architecture. Therefore, my diagrams will show Merchant to represent the System.
Activity Diagrams
Activity Diagram
The Activity Diagram is a way to show the business process flow through an application. There are other mechanisms to achieve similar results, but this is the UML sanctioned approach.
There is a beginning, the solid black dot, that leads to one or more activities. Since this is TML, I took the liberty of drawing the activity as Use Case ellipses.
There is a flow through the diagram that contains decision points, which are shown as diamonds. The swim lanes represent the various actors (or departments) that perform that activity.
Finally, the activity ends and is displayed as a dot with a surrounding circle.
This case represents a scenario through multiple use cases.
Use Case Descriptions
Use Cases descriptions are important and are not just arduous documentation. The descriptions contain detail flows through the application. This exposes issues and forces decisions that would otherwise occur late in the project where is it expensive to deal with.
The Use Case description expects to have an Exceptions section. This allows the stakeholders to make decisions on how to handle problems that may occur and not just focus on happy path items. It forces these difficult to deal with issues up front before coding has started and data has been loaded.
There is no official template for Use Cases, but they are likely to contain the following fields.
In the main flow above, any step can refer to another Use Case, such as 'UC002 Reserve Items' if the step contains sub-steps. Each path through this example represents a scenario. Therefore, there are three scenarios in the Use Case template above
The Main Flow
The Main Flow to Alternate Flow 2.x
The Main Flow to Exception 5.x
At minimal, there should be a test case for each scenario. The failure to identify these flows will likely lead to a lack of code to handle and test key scenarios. This will inevitably lead to a lower quality application, since there will be built in bugs right from the start.
The template above can be implemented as User Stories, but in my experience Use Case authors use far less discipline where troublesome paths are often missed or skipped. Therefore, there is still value in doing Use Cases even in the current Agile model.
Data Scenarios
Data Scenarios represent flows through Use Cases at the detail level against the Data Model. There are many benefits from focusing on Data Scenarios that can increase the quality of the application and reduce the chance of costly project changes late in the project.
Data Scenarios can
expose requirements not seen at the diagram or document level
can cause requirements themselves to be refined
can cause changes in the database schema
Applying Data Scenarios
Domain Model
For the domain model above, there is an equivalent database structure. The finalized structure may contain relationship tables and denormalized tables in the actual schema.
In the Architecture-First approach, in order to exercise the scenarios, the BA or DE will list the relevant Use Cases. There should be one or more queries that are performed and captured to support those Use Cases. These queries will refine the database and can be given to the backend developers when they start to code. The queries may also be contained in stored procedures if deemed appropriate.
Some examples of Data Scenarios are below. They are over simplified so a real application is likely to have many more statements and properties.
Add Product to Shopping Cart
insert into Order_Product (orderId, productId, quantity) values(100, 201, 4);
Reserve Products
update Product_Inventory set quantity = quantity - 4
where productId = 201;
View Order Confirmation
select o.confirmationNumber, prd.name, prd.quantity, prc.id, prc.onetimevalue from Order o
join Order_Product op on o.id = op.orderId
join Product prd on op.productId = prd.id
join Price prc on prd.id = prc.productId
where o.id = 3;
Exercising these scenarios will force the database to handle the Use Cases. The earlier this is done the better. The more scenarios that are covered the fewer surprises there will be.
Wrapping Up
Data Scenarios bring Use Cases to life. They also exercise the application without writing backend code.
This technique is an efficient way to build a mature database that meets the core requirements. If changes are needed to support the details there is less dependent code affected.
It is easier to blow things up and start again if the requirements missed something big. Instead, if a project is not using this technique and a problem occurs late in the schedule, after much of the code is written, the project team will likely have to live with the deficiencies.