System Design is part of the end-to-end Solution Design, providing a view of system processing that is based on a Functional Design and the Solution Architecture, and which is input into Technical Design.

The requirements define the needs of the business, in business terms, to solve a problem. The requirements are elicited from the business, and should be aligned with the target operating model. The requirements are analysed to define a functional design that describes:

• Business Process - A view of the end-to-end business processes and associated activities to be supported by the solution, along with key user and system interactions
• Business Rules - The rules that must be applied by the system to manage the process and to automate validation of user input, computations, persistence of information and formatting of information for presentation to users.
• Information - The information that is input by the user, processed by the system and used in the formatting of user interfaces and reports.

Non Functional Requirements (NFRs) are concerned with operational aspects as opposed to functional behaviour. They typically form the basis for Service Level Agreements, that defines a formal contract for the delivery of IT services to the business, including:

• Performance - The transaction throughput volumes and response times to be supported.
• Availability - The schedule (e.g. 24×7) of when the system should be operational, and the degree to which it should be operational within these periods (e.g. 99.999%).
• Resilience - The ability of the system to recover following a fault or disaster, including recovery time and point objectives.
• Security - The user access and data protection controls to be enforced.
• Usability - Requirements for user accessibility, ease of use and efficiency.
• Operability - Requirements to support system administration, monitoring and management.

Non functional requirements may also define more general system qualities that need to be considered during technical design, including:

• Scalability - The ability for the solution to scale vertically and horizontally to support additional load
• Extensibility - The ability for the system to be extended to support new functionality
• Interoperability - The ability for the system components to work together and share information
• Modularity - The ability for the system to be decomposed into discrete, de-coupled components
• Maintainability - The ability to identify issues with the system, and isolate and repair associated defects

The system design maps the processing described in the functional design to logical system components. It can be described via an extension of the System Design Meta Model (see System Architecture Composition).

A high level system design maps the functional design elements to application functional components:

• Business process activities are mapped to system sctivities in specific applications / application packages
• Information is mapped to data entities and attributes to create a data dictionary, which also used to define screen and report definitions
• Application interfaces are defined to support inter-activity interactions as part of the end-to-end business process

A more detailed system design may be produced to describe the system activity processing to describe the interactions between user interface, process control and service components. The following sequence diagram describes a 'master system activity pattern' based on the design principle of limiting activity scope to a logical unit of work orientated around maintaining a discrete data entity. This can be decomposed into various sub-types for example to support read or update only functionality.

The technical design maps the functional components described in the system design into technical components, including software modules, data schemas and interfaces.

The technical design for a given technical component may be described in terms that are quite specific to the target technology platform and associated software architecture that supports it.

The approach applies basic engineering principles to derive a solution to a problem, breaking the problem down across various levels of design abstraction, from functional design through to technical design.

The approach involves decomposing the solution requirements defined at a higher level of abstraction into a candidate solution at a lower level of abstraction.

This then enables the candidate solution to be compared with the current solution at the lower level of abstraction. The current solution specification is required in order to be able to perform gap analysis against the decomposed requirements.

A Reference Architecture (see Architecture Definition) can define the appropriate scope and structure of the solution at each level of design abstraction. The Reference Architecture provides:

• Reference Models that define structural elements and reference instances of those elements (e.g. the Business Function Model).
• Design Patterns that define standard, repeatable solutions to commonly occurring problems. These can be applied from one level of abstraction to another and where the transition is not straightforward, such as from functional to technical, the link between patterns at each level provides clear direction.

The software architecture defines how functional components are delivered using technology components. It comprises an Application Framework (or blueprint) supported by an underlying Technical Architecture.

The Application Framework defines how business functionality is delivered via various processing styles (e.g. online, batch) through a various types of related software components.

The Technical Architecture provides the platform for delivery of the application, via processing layers (e.g. presentation, business services) and technical services (e.g. logging, transaction management).

As well as provision of a Software Architecture, a Development Architecture to support software development and an Operations Architecture to support solution execution within specific environments may also be defined.

The purpose of design is to effectively describe the functional and technical elements of a solution to a business problem that allows the solution to be developed into technology components.

The Design Specification aims to meet the following criteria, with associated benefits:

• Complete - The specification must be complete and aligned with the inputs from the previous design stage. This ensures that the solution will address the required scope.
• Unambiguous - The specification must be clear with no vague or ambiguous statements. This ensures that the there it does not leave it open for interpretation in different ways.
• Structured - The specification must be structured to ensure that it is readable.
• Concise - The specification should be succinct and to the point to aid readability and avoid ambiguity. It will also initially be “lightweight” to facilitate adoption whilst covering the minimum needed to be fit for purpose.
• Consistent - The specification should be based on a standard template and design patterns. This means that it can be interpreted by anyone familiar with the standard and aids efficiency.

In addition to the benefits described above the following additional benefits aim to be realised:

• Efficiency - Whilst it may seem that the design specifications contain more content than previously, and therefore take more effort to produce, standardisation and a structured approach allowing the use of patterns will minimise the effort required. This and the improvement in quality will ensure that downstream work resulting from poor design specification is minimised, bearing in mind that the cost of resolving a design issue in UAT is likely to be several times more than resolving it during the design phase.
• Quality - The designs will be fully verifiable through test conditions that can be easily determined from the design specifications. This will ensure that the quality of the product prior to user acceptance testing.
• Reuse - The design artefacts should be reusable in subsequent work relating to the same scope.
• Consistent Behaviour - The use of standard design patterns will facilitate consistent behaviour in the solution, facilitating usability and reducing user training.
• Measurement - A standardised, structured and repeatable approach allows the delivery effort associated with specific scope elements to be measured more effectively, facilitating reporting and estimating.