Use cases are not just about requirements
At the biology science, stem cells are biological cells that can differentiate into other types of cells and can divide to produce more of the same kind of stem cells. They are found in multi-cellular organisms. Cells in the body have specific purposes, but stem cells are cells that do not yet have a particular role and can become almost any cell that is required.
In the software production industry, there are some work products which work as same as the stem cells in the body. It means these work products have profound effects on the other area in the software development process by preparing or supplying input information for them, for instance, project management, design, and test activities.
Since software development intrinsically is a complex process due to dealing with human life, economy or other complex phenomenon related to the humans’ life, it is required to make a simpler model to the problem and also solution space to understand them better to make an appropriate software. This approach helps to acquire clear insight into the final product from the different point of views; During modeling process, just some special aspects of either problem or solution area get focused to decline complexity applying some abstraction. Briefly, modeling helps to make the real world easier to understand by removing unnecessary elements out of the model’s scope.
It is obvious a model is not just a graph or diagram when we talk about a model we talk about either a document, a miniature physical model, a mathematical formula or any combination of them. It is rear to have a physical model in software engineering while documents, graphs and sometimes mathematical equations are ordinary.
One of the very first models in a software project is “Use case model,” this model consists of both diagrams and documents. As this article is not about developing a “use case model,” I do not dig more in the techniques for it regardless of the following steps which end in a primitive “use case model.”
1- Find actors and write them down in a “Use case model survey” document.
2- Find use cases then add them down in the “Use case model” survey document.
3- Create a primitive “use case” diagram.
4- Outline the “use cases.”
5- Chose the most significant technical or business “use cases.”
6- Write down the use cases’ specifications.
7- Break down the “use cases” and identify their relation.
8- Update the use case diagram.
9- Organize the use case diagram using packages.
Both “actors” and “use cases” are the pillars of this model. As you may know, “use cases” are a combination of a name, and a brief business description for their business intend which represent a placeholder for describing an interaction between actors and the system to accomplish a sensible business step. Use cases’ specifications are a detailed description of the possible interactions between actors and the system to meet the business targets. If we just cared about software requirements, this descriptions would be satisfactory.
Although in this situation there is adequate information about the solution and actors’ interactions to create the system, some use cases are so complicated so that their complexity creeps to the project management activity including planning, besides increase opacity in system design. If we do not mitigate this risk, we have blindly ignored a stern challenge in the project. Hence, we should have a technique to divide the complex use cases and concur the potential problem. Dividing the use cases results in either generalization or extend/include dependency between new use cases. These relations are not about software requirements considerations. They help in managing the priority of the use cases and planning activity besides increasing more clarity in the next steps of the software development process.
When splitting a use case results in a generalization relation, customers and project managers have more options to select a valuable piece of work to do. For instance, suppose there is a use case for loan request registration which its actor is an employee in a bank. Required data for individual customers and firms are so different in this use case. Thus it can be divided into three use cases, a base use case for common steps and two use cases for individual customers and firms. In this situation, the customer is empowered to assign a different priority to each of them.
Other types of relation between “use cases” are “Include/extend dependencies,” extend dependency shows an optional extension point in a “use case” which may execute if criteria met. For instance, when a “use case A” extends “use case B”, it means use case B can meet its original goal even without use case A, but if use case A get developed more options and facilities will provide to users, it means, we can defer the implementation of use case A without sacrificing the business values. This approach is a reflection of this stated agile principle, says “Simplicity –the art of maximizing the amount of work not done- -is essential.”
On the other hand, “include dependency” shows that a “use case” is mandatory for the other “use case” to works correctly, so regardless of all considerations this “use case” should be implemented before or simultaneously with its related use cases. For example when “use case A” includes “use case B,” it is not possible to choose to implement first one in an iteration without implementing the included use case. It can be inferred the more input include dependency a use case has, the more high priority it has to get implemented more early. Otherwise, it may be a bottleneck in the next iterations.
Not only dividing use cases but also identifying their supplementary characteristics helps planning testing, activities. Categorizing use cases into primary or secondary category helps wiser planning.
a. Primary: These type of use cases are created to describe an elementary business process in the context of the project.
b. Secondary: These type of use cases are created to provide services which prepare or support the primary use cases.
Secondary use cases’ Implementation can be deferred to the LRM (Last Responsible Moment). The last responsible moment is the instant in which the cost of the delay of a decision surpasses the benefit of delay, or the moment when failing to take a decision eliminates a valuable alternative.
Moreover, Use cases and use case models can be used for developing help documents besides the as a unit of works in the transition phase of the project.
In conclusion, although use case model is a simplified view of the actors’ interactions with the system to achieve a common view about the solution with the customers by focusing on the functional requirements, it can be a suitable material for planning, estimation and other project management activities in addition to removing opacity during design the system, transition phase and similar activities. In other words, they can be changed to other types of artifacts as stem cells do.