How can we create a cohesive picture from different techniques?
During analysis, we use many different techniques. The results of these techniques, and artifacts, should form a coherent picture and be interconnected to easily trace different aspects of one analysis element and various levels of analysis detail.
Let’s look at how one technique creates a foundation for another, and how one technique can be a continuation of another. A very illustrative example is the Use Case Diagram and User Stories.
The Use Case Diagram helps us understand the product scope and decompose it correctly. User Stories are the main embodiment of this decomposition and the formation of the backlog (scope).
While working on the Use Case Diagram, we not only outline the main capabilities of the system that certain users should perform, but we also identify recurring functions and separate them, establishing an “Include” relationship with many cases where they are used. We also determine which cases are primary and which are secondary through the “Extend” relationship. In this way, the Use Case Diagram helps us structure our product by function, decompose thoughtfully, and provides a basis for defining User Stories and their priorities in the backlog. User Stories will be a continuation of the Use Case Diagram, embodying the cases in the stories.
I will use an example of a Use Case Diagram from the Internet. In the first picture, we see the documented user capabilities and a deeper analysis of what needs to be implemented in the system to make these capabilities work in the second picture. Additionally, in the second diagram, we identify common requirements, logic, or functions used for several cases and must be separated through the “Include” relationship. These new cases are not directly related to the user’s goals but are necessary to complete their tasks. In the third picture, we see additional cases that extend the main functionality.
Thus, we moved from user requirements to functional requirements, structured them, and prepared the foundation for User Stories, which can now be easily linked to the Use Case Diagram through names or a Use Case — User Story matrix. Such a matrix also helps ensure that all cases are covered by user stories.
What user stories do we encounter here? I will provide an example for the user “Client”.
“As a client, I want to withdraw money from my account to have cash for my needs.”
“As a client, I want to transfer money from my account to pay for my purchases or to help a relative or friend.”
“As a client, I want to be able to deposit money to save and grow it.”
“It is necessary to perform card identification to identify the client and present them with options to withdraw cash, transfer money, or open a deposit.”
“It is necessary to implement the recording of the user’s selected transaction to account for the movement of funds in the client’s account when they withdraw cash, transfer money, or open a deposit.”
“As a client, I want to receive immediate assistance to overcome difficulties I encounter when working with my bank account.”
This is how we transitioned from scope analysis and decomposition to forming a backlog through user stories. We see very clear connections between these two techniques and the ease of defining User Stories, the coherence, and the consistency of the requirements.
In practice, we link more techniques; for example, in this case, we could also analyze processes for each case, document business rules, the lifecycle of certain business entities, specify Use case scenarios, and more, identifying additional requirements and complementing the cases.
I believe that structure and coherence are the foundation of requirements that drive the product and development.
