Soft System methodology for transforming the business analysis to Software Development Architecture.

What is Soft system development methodology?

The Soft Systems Methodology (SSM) is a systems engineering approaches to solve “management/business problems”. This approach is needed simply because the different stakeholders have divergent views on what constitutes the system, the purpose of the system and therefore the problem.

Two key players in the development of the SSM are Peter Checkland [1999] and Brian Wilson [2001] .

SSM Includes include:

1. Rich Picture
2. Conceptual Model
3. CATWOE
4. Formal Systems Model

Figure 1.1, Simple Architecture for Soft System Methodology

Figure 1.2, Picture for How we trasnform Soft System methodology to System architecture with UML

In this article, I will discuss about step 1, 2 and 3, which are more important for transforming the real life problem into software design architecture.

THE PROBLEM SITUATION: UNSTRUCTURED

The first step of transforming the real life problem to software architecture design is to gather the information from different source within the problem domain, we can follow the three steps to gather information, those are optional, but we can use it for primary information gathering.

Figure 1.3 How to Business Analysis gether Unstructed Information

Figure 2.1 Sample Rich Picture

EXPRESS THE PROBLEM SOLUTIONS

We can use Rich Picture to express the problem solution and design the system context of problem domain from unstructured data, Figure 1.2 is a sample design of rich picture. As System analyst we can design or propose one or more rich picture for expressing the problem solutions. So at first we have to know about what is rich picture.

A Rich Picture is a way to explore, acknowledge and define a situation and express it through diagrams to create a preliminary mental model. A rich picture helps to open discussion and come to a broad, shared understanding of a situation.

Formulate Root Definitions

The 3rd step in Soft Systems Methodology ( SSM ) is to formulate the Root Definitions of the System you are studying, analysing, designing, evaluating or even quality assuring, inspecting or certifying.

ROOT DEFINITION

A Root Definition is a structured description of a system. It is a clear statement of activities which take place (or might take place) in the organisation being studied.

A properly structured root definition comprises three elements [what, how, why] and is of the form:

A System to do X, by (means of) Y, in order to achieve Z.

X — What the System does
Y — How it does it
Z — Why it is being done

The ‘what’ is the immediate aim of the system,
The ‘how’ is the means of achieving that aim,
The ‘why’ is the longer term aim of the purposeful activity.

CATWOE analysis helps in proper formulation of a Root Definition.

CATWOE is a mnemonic which helps identify and categorize all information [people, processes, environment, entities] of the System being analysed for formulating the Root Definition.

Using Rich Picture to Express Problem Situation To Real World

This option was originally developed as part of Peter Checkland’s Soft Systems Methodology (SSM), developing a rich picture covers steps 1 & 2 of the SSM which describe the real world[1]:

1. Identify the issue you wish to address, and
2. Develop an unstructured description of the situation where the issues lies — how it is

The key part of the rich picture are:

• Structures

“Structure” includes anything that is slow to change, such as geographical situation or hierarchical structure of an association. Example : Such as how a student get admission into university and what is the structure of admission into university.

Figure R-1.2 Structure of Rich Picture

• Cartoon Symbol

Need for representing the system or any actors or institute related to the system.

Figure R -1.3 Cartoon symbol for Rich Picture

• Processes

Process represents any transformations that occur within the system. Such as student give the educational information to University to get admission in the relevant field, then admission office process the student information.

• Actor thinking or Think bubble (Issues expressed by people)

Such as Admission officer think that only previous educational transcript is needed for admission. He also think that, is he student or not.

Figure: R -1.4 Think Bubble or Actor thinking

• Conflict

Different opinion between different actors for same process or information flow is a conflict. For admission process, admission officer think that they “need only transcript for admission” but for “registrar” he think that “University needs all of the papers needed for admission.”

FIgure R-1.5 Conflict example for Rich Picture

As a Developer I can think about “Student Admission System”, how it works. So Design eco-system with data flow or processes for “Student Admission System”. And Adding conflict between different actors of the system, which is then represented as rich picture. Few days ago I discussed about how can we design the rich picture with my co-worker and they were just interested on my concepts. I have provided the example of rich picture below

Figure: 2.2 Template Use case Description for “Query (Ask) for Admission form”

In Figure 2.2, Designed rich picture for “Student Admission System”, contains process of information or data, which is then used for designing the software architecture and help us to find functional and non functional requirement of the problem domain. The Process and information flow list is shown below:

Process and Information Flow

1. Go to University for Admission
2. Student ask for Admission Form
3. Provide the Admission Form
4. Student Fill Up the Student Form
5. Admission Officer Ask for Other Document Related to Admission
6. Student Provide Other Documents
7. In Adminssion Officer Group there is Registrar
8. Registrar Check the Document for Student Eligibility
9. Registrar Confirm the Candidate for Accceptance and Rejections
10. Save the Data to Database
11. Admission Officer Check the Stored Student Data from Database for Student Eligibility or existance of Student

Conflict

Conflict is created in the Functional and Non Functional Requirement, in this Rich Pricture, conflict occured between “Registrar and Admission officers” for admission documents

1. Only Need Transcript for Admission
2. Need Full documents and Transcripts

We can also find the requirement from constructive thinking of a actor, which is then represented as think bubble in rich picture.

1. For Admission Officer: I can check student document , if all the information is valid for eligibility
2. For Registrar: I can check the student document for eligibility

Actors

1. Student
2. Admission Officers
3. Registrar

There is one external entity named “Governing Body”, So the information flow between external entity and problem domain also a source of requirement.

Think Bubble

From think bubble developer can find the functional and non functional requirment. He can also find the validation process of any functional and non functional requirment.

In figure 2.2, We can find two think bubble which can be use to add the validation process for checking the student eligibility for admission in “Student management system”

As System analysis, I can also find the “root definitions” from process and information flow from rich picture. Then for further development or analysis purpose actors, conflict, think bubble and process of information flow helps developer or analyst to build the “Use Case” Models.

Use case Models

An Use case model is business analysis presentation of the steps defining the interaction between a user and a system. it details the interactions and set the expectation of how the user will work within the system.

Use case diagrams are usually referred to as behavior diagrams used to describe a set of actions (use cases) that some system or systems (subject) should or can perform in collaboration with one or more external users of the system (actors). Each use case should provide some observable and valuable result to the actors or other stakeholders of the system[2].

The use case modal consist two artifacts

1. Use Case Diagram
2. Use Case Description

Analyst can design the “Use Case Diagram” and “Use Case Description” from the Figure 2.2 rich picture using “data flow or process”, conflicts and think bubble. It is not important that every data flow or process will be at use case’s actions. We can combine more processes to make one action if necessary.

We can conbine first 2 process flow into one named “Query(ask) for Admission Form”

1. Go to University for Admission |
2. Student ask for Admission Form | 1. Query(ask) for Admission Form

It would not be neccessary to combine all the process

2. Provide Admission Form         
3. Fill up Student Form 
4. Process Other document for Admission
5. Check Document for Student Eligibility
6. Check the Student Info to Store
7. Process for admission student
8. Save Data to Database

For UML 2.0, we can add actors and system as responsible for doing the use case action. The actors for use case diagram are

1. Student
2. Admission Officer
3. Registrar
4. System

Use Case Diagram of “Student Admission System”

Figure 1.4 Use Case Diagram of “Student Admission System”

For Simple explanation purpose I have discussed about one Use Case Action for Use Case Description.

Figure: 1.5 Template Use case Description for “Query (Ask) for Admission from”

• Title: The title action name of the use case. In Figure 1.5, “Query (Ask) for Admission form” is the title of the use case description.
• Actors: These are the people or systems who interact with the use case. In Figure 1.4, Student, Admission Officers and registrar and System is actors.
• Preconditions: Preconditions are the things or stage,which is needed before the use case is started. In Figure 1.5 for “Query (Ask) for Admission form”, Candidate should be student, Student should go to university first, Admission Officer will be available for Query, those are the Preconditions.
• Postconditions: Postconditions are in place when you finish the use case successfully or unsuccessfully. In Figure 1.5 Student Should be Notified if Form Is available. is the post conditions .
• Path: Also called flow or story, the path is the step-by-step action and interaction between the actor and the system. Paths come in three types:
• Primary path (also known as happy path or main flow): This route is the most commonly taken path to a successful conclusion. In Figure 1.4 Is the Primary Path for This use case acions.

1. Go to University
2. Search For Admission Department
3. Search For Admission Officer
4. Ask for Admission form

• Alternate path: This path is an alternate, less-frequented way to get to a successful conclusion.

1. Go to University
2. Ask Help Desk to Admission Officer
3. Get Info about admission officer
4. Meet with admission officer
5. Ask for Admission form

• Exception path: This path is an alternate path that leads to an unsuccessful conclusion.

1. Check Admission Form Availability
2. Do have any Admission Form
3. Provide notification for have no Admission Form

• Use case ID: A unique identifier used for tracing.
• Created by: The author of the use case.
• Date Created and Revision History: A chronology of the use case, which allows you to see how old the use case is (useful when doing document analysis),
• Priority: An indicator of this use case’s importance, which is helpful in solution planning.
• Frequency of Use: An indicator of how often this use case is executed (also helpful in solution planning).