As the headline implies the purpose of this chapter is to tell the reader what functionality the architecture provides for the solution (functional viewpoint). In its simplest form, this can be illustrated with a UML use case diagram:
The advantage of using this diagram – or model – is that maps elegantly to the use case specifications that make up the bulk of the requirements specification.
However, the use case model easily falls short of mapping the use cases to the business processes in which the specified functionality is used.
Sometimes I chose to present a business process model, still using the use case model diagram but the the bobbles representing processes instead of use cases. What’s the difference, you ask? Well, a worker performs a task, which consists of steps – this is what constitutes a process. In some steps, the worker uses the system’s functionality to do something very specific, and it is this specific part that is detailed in the use case specification.
In some cases I end up presenting a mind map, which was the result of an early brainstorming session to define the scope of the project.
If I’m facilitating such workshops, I always use the universal business model as the starting point of the brainstorming session. This helps map the identified processes to the business capabilities as well.
Regardless of my choice of modelling, I always accompany the model(s) with text brief descriptions of the processes and use cases shown in the model(s). And I always explain which impact each use case has on the solution architecture.
I recommend that this chapter contains a table with the following columns:
| Use case (or process) | Description | Consequences |
|---|---|---|
| Create account | The user registers, receives an email and confirms the email address by clicking on a link in the email, thereby activating the newly created account. | The server application calls an external service to send the activation email. |
| Sign in | The user enters the necessary credentials to access the system. | A database is needed to store the user’s credentials. The connection is encrypted, and the password is obscured using ‘salt’ and other techniques. |
| Simulate | The user creates a model, inputs the relevant factors, runs a simulation, and analyzes the outcome. | As the simulation may take considerable time, the user’s screen shows the progress, enabling the user to predict when the results can be expected to be ready for analysis. |
If use case specifications are created as separate documents you can of course add a column to the above shown table with links to the documents.
Some companies still write so-called functional specifications, but it’s not a practice I would encourage. They are usually a mix of requirements specification and detailed design, sometimes with some business rules thrown in here and there.
I have seen several problems with this approach:
- Functional specifications are usually written by business analysts after a formal requirements specification has been approved and ‘sealed’. So the BA is constrained by the already approved list of requirements, making it difficult to specify the best possible functionality.
- Functional specifications tend to focus on – wait for it – functionality! So, usually the write will not present any information models, which should be the backbone of the design. And even if tried, the limited scope of each individual functional specification makes it hard to capture the information aspects, since the only truly meaningful information model is designed for the entire solution as a whole.
- Functional specifications are hard to slice into small chunk that are easier to pick up in small incremental sprints.
I know this, because I have been the BA writing these diabolical functional specifications in several very big projects over the years.
Write use cases, which are easy to slice into user stories, which work very well as input to developers and testers (see Use Case 2.0).