Architecture and Functional Design

11th of November 2018

Having been slacking for the last few months, partly because of non-IT related pursuits and partly because of the new project I have been working on, I have decided to set myself the goal of releasing a new and improved version of my white paper on Solution Architecture. First up is an addition to the chapter on further developments in a project once the initial version of an architecture has been formalized: The Functional Design. So the remainder of this thought is the new information being added to the white paper:

 

Once the high-level requirements have been determined in a project, it is important that these requirements are fleshed out in an unambiguous structure so that they can be used by the development team to deliver the proper solution. It allows for early peer review of the underlying logic for the functionality and gives the developers a technical insight into its intended behavior. The most common way to elaborate requirements is to describe them with functional use cases. Once these use cases have been formalized, the next step is to write test cases that can verify whether a solution has correctly implemented the use case functionality.

Example of a Use Case Diagram
NTR-UC-00001: Check Land Registry
Preconditions:
A request for Property Purchase has been recorded
The notary checks the purchase history of the relevant property
Sequence:
  1. Notary opens Land Registry Database
  2. Client enters permission key for his property
  3. Notary searches for the relevant property with the search parameters (location, owner)
  4. The system lists all previous purchases of this property

While UML does have a use case diagram, this is only used to show an overview of all relevant use cases for a specific component or solution. Typically, a use case has the following elements associated with it:

  • A unique identifier: This can be used to have an easy way of referring to the use case in for example other use cases or documents. A good practice is to has this be in the following format: <Project Acronym>-UC-<Unique Number>. In the example above this is NTR-UC-00001.
  • A name: This is a short description of functionality the use case is describing. If this name is short and unique, it could also serve as the unique identifier.
  • A brief description: A couple of sentences detailing the purpose of the functionality and its key logic.
  • Actor(s): Whoever is needed to execute the use case functionality. Actors can be real persons or system components.
  • Sequence of events: A detailed step by step workflow of everything that needs to be done in order to achieve the end result required from this functionality.
  • Optionally, preconditions and postconditions can be listed, respectively detailing the state of the system required before the execution of the functionality, and the state of the system after the functionality has been executed.

In some agile contexts, we might even forego the use case detailing, and write test cases based on the acceptance criteria. These test cases than become the basis for development to create their solution. However, this approach strongly depends on the maturity of the implementation team and of the testing automation framework. Also, while this can work for smaller projects, once the complexity of a solution rises, this approach becomes increasingly ineffective.

Bear in mind that the decisions made during the architectural efforts before this elaboration might impact what liberties the functional analyst has when designing the functional solution. These limiting factors can be found in the Design Constraints section of the Requirements View and should be adhered to so that the implementation is not put in a tight spot. For example, if the decision has been made to use a Business Process Engine, the functional designs should be made in order to fit into the processes, and not design a case management-based functionality.

Thought Document Functional Analysis