Chapter 18       Summary Of The Process

This final chapter summarizes what the steps of the analysis process from the business vision through to testing the model.[1]

18.1The Business Vision

The business vision is a set of textual statements that identifies the following:

·        Description of the need for the project.

·        Statements of problems with the current business process.

·        A solution statement to the current problems.

·        A list of stakeholders for the project.

The business vision describes the objectives for the project in a textual form, but may be supported by architectural diagrams.

18.1.1  Business Need

A textual overview of the customer’s needs for the project. This statement contains the highest level description of the requirements.

18.1.2  Problem Statement

Describes a stakeholder problem to be considered for the project in terms of the people it affects, their impact and a potential solution for the problem.

18.1.3  Solution Statement

Describes a solution for the customer problems in terms of a product name, its capabilities and the changes that it will make to the business.

18.1.4  Stakeholder

An person that is interested in the outcome of the project. Stakeholders include; users of the system, business workers and customers of the delivered solution.

18.2Business Model

The business model is a pictorial view of the business vision. It describes:

·        A list of actors gaining benefit from the business process.

·        Impacted business processes as business use cases.

·        Business rules that impact the business process.

·        The scope of the project in terms of a context diagram.

·        A business architecture describing the different business organizations, their responsibilities and how they interact.

·        A list of business workers performing the activity captured by the BUCs.

·        A list of candidate use cases.

18.2.1  Business Actors

The business actors are the people outside of the business process that are either gaining benefit from the process or assisting with execution of the process.

18.2.2  BUC

The BUCs are the main components of the business model (other components are used to verify the correctness, scope and restrictions upon the BUCs). A BUC is intended to give satisfaction to a business customer (whether they are internal or external to the organization). A BUC may be modeled with a BUC activity diagram. It comprises

18.2.2.1 Business Use Case Steps

A BUC step describes the business process in terms of the actors interacting with the BUC. Each step describes a business process and its results in terms of a request from outside of the business.

18.2.2.2 Business Objects

Business objects capture the information manipulated by the business during the process of executing BUCs.

18.2.2.3 Candidate Use Cases

Steps in the BUC that are candidates for automation. Each identified step is a candidate for system  functionality that will be resolved into application use cases.

18.2.3  Business Rules

Business rules capture restrictions upon the steps in the BUC. These rules may restrict the data manipulated by the BUC, when the steps may be performed or any other description of ‘how’ the steps may be performed. Any restriction that impacts many steps of the BUCs may be captured as a business rule.

18.2.4  Business Worker

The business workers are the roles within the organization that perform the steps captured by the BUC. These roles are captured by a BUC realization diagram. The BUC realization is often described by an activity diagram with swimlanes[2]. The swimlanes show how BUC steps are performed by different business workers in the organization.

18.2.5  Context Diagram

A diagram that defines the scope of the project in terms of the external entities interfacing with the solution and the information that passes between them.

18.2.6  Business Architecture

A graphical description of the different organizations involved with the project and the information that passes between them, within the context of the project scope.

18.3Use Case Model

The requirements model includes:

·        System Actors

·        Application use cases

·        Application Activity Diagrams

·        Application objects

18.3.1  System Actor

A user of the system under construction for the project.

18.3.2  Application Use Cases

Is a system software function that yields an observable result to a system actor.

18.3.3  Activity Flow Diagrams

The steps of an AUC are captured graphically using the activity diagram. This begins with a start state, representing the AUC precondition, and describes AUC workflow steps as activities performed by the application, and transition between them representing events causing the activity to occur. the AUC postconditions are represented by stop states.

18.3.4  Requirements Objects

The requirements objects capture the data that is manipulated by the steps in the AUC. Each AUC step either receives or produces information that is externally visible to an AUC actor. This information is assigned to objects that are associated with the use case activity diagram.

18.4Analysis Model

The analysis model captures the objects discovered in the requirements model as classes with states, attributes and operations. Analysis classes are connected with relationships that describe how the classes communicate in order to satisfy the requirements.

18.4.1  Analysis Classes

An analysis class captures the AUCs in terms of components that have ‘responsibility’ and ‘behavior’. A complete set of analysis classes in analysis model will encompass the functionality and objects described by the use case model.

18.4.1.1 Operations

An operation is a requirement of the application that is assigned to a class. It is a description of a part of the ‘behavior’ of the class.

18.4.1.2 Attributes

An attribute is a description of data that is manipulated by the class. Attributes define the ‘responsibility’ of the class in terms of the data that the class is responsible for maintaining. Attributes are defined in terms of real-world mathematical constructs.

18.4.2  State Diagrams

The state diagram describes the behavior of an analysis class over time, in terms of events handled by the class and activities performed by eh class.

18.4.2.1 States

States are used to capture system functionality in terms of the dynamic behavior of classes. Each state describes the activity performed by an analysis class in terms of it operations. The states of the analysis classes determine the behavior of the system at any point in time. All class states are externally recognizable through observing the behavior of the system as a whole.

18.4.2.2 Transitions

Transitions are responses to external events that are handled by classes. All transitions cause a state change, even if it is back to the same state that the system was already in. Invalid external events in a system state are ignored. They have no associated transition from any class the current system state.

18.4.3  Use Case Realization Diagrams

Used for detailing how the AUCs are captured by the analysis model.

Each use case workflow is described by a sequence diagram that describes how a use case step is captured by messages between use case actors and instances of analysis classes.

18.4.4  Software Requirements

The software requirements are individual statements of functions that the deployed software will perform. The software requirements are used to clarify steps in the AUCs.

18.5Other Models

The following models are outside of the scope of this book, but will be of interest to the analyst in order to understand how their work will be used by members of the development team.

18.5.1  Design Model

The design model serves as an abstraction of the implementation model and its source code. Out of scope for this work, it briefly comprises an architecture applied to the analysis model.

The architecture model comprises:

18.5.2  Subsystems

The major components of the architecture.

18.5.3  Design Classes

These are the analysis classes as they are assigned to the architecture. A single analysis class may map to several design classes.

18.5.3.1 Attributes

Describe the data used by the design model in terms of the language in which they are to be implemented. Whereas analysis attributes are described in terms of real-world constructs, the design attributes are described in terms of the types used to implement them.

18.5.3.2 Methods

These describe how the analysis operations are to be implemented by the software.

18.5.3.3 Use case Realizations

For traceability purposes, the use case realization describes how an AUC workflow is implemented by the classes within the system architecture.

18.5.4  Implementation Model

The Implementation Model describes how the design is deployed into components. It represents the physical composition of the implementation in terms of directories source code, data, and executable files.

18.5.5  Test Model

Out of scope for a pure analysis discussion, but such an important part of the SDLC that it is worth a mention in any work on software development.

A test activity comprises 2 parts:

·        The unit and integration testing components – Concerned with ensuring that deployed software components perform as they were designed to perform. The objective being that when code modules are integrated they interact so that the application performs in a manner that satisfies the requirement.

·        User Acceptance Testing (UAT) Components – Test cases and supporting artifacts that ensure that the application as a whole satisfies the requirements for the application.

Of particular interest to the analyst is the UAT model.

18.5.5.1 User Acceptance Test Cases

Assuming that the software requirements were used to ensure that AUCs are complete and correct, the UAT cases may be derived directly from the AUCs, and supporting data (class) diagrams.

Each UAT case may be traced directly from a workflow in the AUC. The steps in the AUC should correspond 1 to 1 with the steps in a UAT case. Each step in an AUC workflow describes an externally visible action performed by the application, that is either initiated by an actor or witnessed by an actor. Each step in an UAT case describes an externally visible event in terms of the data that either input-to, or output-from the system. Ideally the steps in both cases will correspond, although one AUC workflow may be the cause of several UAT cases once data is added to the steps.

This is why, when building AUCs it is important to consider the needs of the person responsible for testing the application. (In fact the tester should be an important role when approving the AUC.)

18.5.6  Deployment Model

This describes the physical and architectural configuration of the run-time processing nodes. It also includes documentation describing how to install and configure the deployed software.