A function, a piece of functionality, of a software is, basically, a sequence of actions or an algorithm the software can perform on request, and in the course of the actions, it takes some input data and produces output data. A use case, on the other hand, is a sequence of steps describing an interaction pattern of an external party, such as a user, with the software. In the scenario of a use case, steps are typically performed alternately by the user and the system. When the system performs a step, it performs a function. This is how functions and use cases are coupled, and this conclusion is what enables us to say, functions are the actions or reactions performed by a software system in order to implement a use case.

It is worth noting that either directly or indirectly, but each function shall be linked with some external party (actor), since either its input data is fed by an actor, or its output data is consumed by an actor, even if it is performed indirectly, via other functions. If the Business Analysts conducted a thorough use case analysis, all functions of a software are linked to actors.

Functional Decomposition

Functional decomposition means to take a problem and divide it into subproblems, until reaching a convenient level or depth at which the problem can be solved or can be seen atomic. If the problem is to create an invoice in an accounting software, it can be divided into the subproblems of entering customer details, entering items, entering notes and issuing the invoice. Entering items, furthermore, can be divided into the subproblems of searching for an item, applying some discounts, setting vat key and so on. If the problem is how to get in to a software, it can be divided into subproblems like logging in and authorization, and logging in can be divided into the steps of identification and authentication, just for another example.

This process of breaking down top problems into manageable ones is a necessary step of requirements analysis and software design. But its scene should not be use case analysis.

Use Case Analysis

Use cases describe the pattern of how an actor interacts with a software to complete some goals. If the goal is of business value (such as issuing an invoice in the accounting software), it is a primary use case, and if the goal is to perform some kinds of administration, like setting vat keys, which do not have business value at its own, it can be told supporting use case. The goal of use case analysis is to identify the top-level functions a software should feature. These functions will be defined by understanding the steps performed by the system in the scenarios of the use cases.

The set of use cases defined for a system should give you a picture of what the software will be used for, without the specifics of how its functions are arranged into graphs. This comes at a later step.

When use cases are defined, actors are assigned and scenarios are elaborated, you can start defining software requirements or functions the software should have by iterating through the steps of the scenarios. If the scenario step says “the actor selects an item”, you can define a requirement or function saying “the software shall provide a searchable combo box of items on the issue creation screen”, and the scenario step says “the system calculates the grand total”, you can write another requirement like “the software shall automatically calculate and update the gross grand total of the items already added to the invoice when any numeric value affecting the total changes”, and so on. This is how use case analysis helps you to create functional decomposition.

So the goal is to keep the use case model top-level, showing what functions to invoke to complete a business process. Also, scenarios should be kept simple so that everyone can get the picture easily.

Keep your use case model as simple as you can

The Trap of Mixing the Two

In the practice of use case modeling, however many people fall into the trap of trying to create functional decomposition with use cases. This is strongly not recommended, simply because use cases are not applicable and suitable to describe a graph of functions. When developing use cases for a system, you should not address the question how the system will perform one or other task, since your goal is to gather what the software will need to perform. This includes that you do not need to organize functions into hierarchies using use cases, and if you try, you will soon find yourself with dozens of use cases which you can not overview.

The includes, extends and invokes connectors between use cases are only meant to separate or highlight common or exceptional patterns in the scenarios, not to give a lower-level description of what happens in another use case.

An example of what not to do is shown in the following example. See how complex the use case model became, with no added value: adding an item (in itself) or a customer (in itself) has no business value, but distracts the focus from properly understanding the goals of the system.

The figure shows a DON’T DO pattern, with functional decomposition mixed into use case modeling. See how complex the model, compared to the figure above, became with no added value.

The Proper & Effective Way

The proper and effective way of uncovering, analyzing and designing the functionality of a system consists of the following steps:

• Conduct use case analysis to find the set of use cases describing the patterns along with actors interact with the system. Elaborate the scenario of each use case.
• Define requirements for the steps of the scenarios.
• Take the set of requirements, and start decomposing each functions until you reach the sufficient detail or granularity.

If you want to organize and detail functions, use other types of elements and tools, such as activities. Activity diagrams and interaction overview diagrams are proper and handy tools to break down top-level functions into atomic steps and to build function hierarchy. Here is an example of functional decomposition, separated from but rooted in use case modeling, the functional decomposition of the use case Creating an invoice:

Functional decomposition of the use case Create invoice. You can easily break down or build up function hierarchy when using the appropriate tools.

And Now the Question: Is Login a Use Case?

Mostly not. In the rare case you are performing the use case analysis of some authentication or user management software, such as an SSO solution, in which the business value for the user is really to get logged into some protected systems, login is a use case. In no other applications has the action of getting into a system any business value: the user’s company won’t have larger incomes or lower costs just because people can log on to the accounting system. Why that company spends money is that those users can easily and quickly create invoices, or the invoices are automatically posted to the G/L application and so on, but definitely not for being able to log in and sit back.

_{(Top image by Svilen Milev)}