System Methodology

From idea to Specified/Designed System

Modeling Methodology

Get inspired by a collective view "From "Business Scenario to Specified System".
Six views and structuring principles that helps the requirement process to specify a working system.

In the form of workshops with system management and system architects lifting both functional and non-functional requirements, with concepts and principles aiming at creating a common language.

Step 1: Specify the Functions

With a top / down method starting with the Business Scenario the missing Use Cases to fully support the Business Scenario is a lot easier to define than starting directly with what functions that are needed.
Using templates for Business Scenarios, Use Cases and Guiding Principles for Application Functions will give a very good foundation for both design and test.
The method is well suited for Agile development and gives the Product Owner agood overview. With pre-designed functions it supports composite solutions of "micro services".

Step 2: Define the Applications

From the list of Application Functions define which will be composed to form a Delivery Application and which to compose a Management Application.
In addition to the Application Functions take also into account who the Application will serve, the application's place in the Enterprise application architecture and how it serves the Business Model of the Enterprise

These aspects will not only help to group the Application Functions to Applications, aspects coming in following steps will either confirm or reject the compositions.

Step 3: Specify the Information/Data model

The so important Information/Data Model is often very tricky to define. With some guiding principles it becomes a little easier.
Categorization of the data entities into five types with different roles towards the applications will significantly help to define the data model.
If these data categorizations are kept throughout the design, other aspects in later steps will benefit from it

Step 4: Application Characteristics

To build an Application is not only to build the expected function.
Non-functional requirements are necessary to design for e.g. the right Responsiveness, Performance, Availability, Robustness etc..
Responsiveness, for example, means design requirements for the application to be either "Real-time", "Interactive" or "Batch", with their respective specifications.
"Real-time" is machine-to-machine communication with maximum response time, if this is not met, it is malfunction, while "Interactive" is best effort.

Step 5: Deployment Aspects


The deployment is for a specific platform either embedded software in proprietary hardware, COTS hardware and software or for virtual installation.
Other deployment requirements can be the ability to have the whole or parts of the application distributed. The application might be depending on other applications or 3PP:s that needs to be installed in the local environment.

Step 6: Operation & Maintenance Aspects

For the operations and maintenance there is a long list of aspects to consider. Many of these Operations Application Functions comes from Associated Use Cases from Step 1 in the Methodology
This Step 6 is the last, and now it is time to start at Step 1 and take a second tour. It is quite natural that, by now, there are additional Use Cases and Functions, improved Applications, additional Data, revised Characteristics and additional Deployment requirements to take care of.