MBASE

Model-based System Architecting and Software Engineering (MBASE) is an approach that

integrates the process (PS), product (PD), property (PY) and success (SS) models for
developing a software system. The essence of the approach is to develop the following
system definition elements concurrently and iteratively (or by refinement) using the Win–Win
Spiral approach defined in [Boehm, 1996].

 Operational Concept Description (OCD)

 System and Software Requirements Definition (SSRD)
 System and Software Architecture Description (SSAD)
 Life Cycle Plan (LCP)
 Feasibility Rationale Description (FRD)
 Construction, Transition, Support (CTS) plans and reports

 Risk-driven prototypes

The three critical project milestones are the Life Cycle Objectives (LCO), Life Cycle
Architecture (LCA), and the Initial Operating Capability (IOC). The system definition
elements have to satisfy specific completion criteria at each anchor point.

 The system definition elements are strongly integrated and a strong traceability thread ties the various
sections: e.g., the System Definition (documented in the SSRD) is a refinement of the Statement of
Purpose (documented in the OCD). Therefore, to enforce conceptual integrity, it is essential that team
members work collaboratively, particularly on strongly related sections.

1. Operational Concept Description (OCD) 

 The Operational Concepts Description (OCD) tells how a proposed new system will operate
within its environment. For the operational stakeholders (including users, operators,
administrators, maintainers, owners, general public), it enables them to understand and refine
the proposed new system. For the development stakeholders, it enables them to better
understand and make development decisions consistent with the operational objectives and
constraints. The OCD should describe:
 a top-level shared vision of the system's goals and how it will achieve them;
 the reason the new system is being built, including any problems or deficiencies that
the new system is intended to fix or improve;
 The concept for new system including what it is expected to do and how it will affect
the operational stakeholders.

Here are the sections of the OCD:

1.1 Organization Goals 

Identify the broad and high-level objectives and/or aspirations of the sponsoring
organization(s) and of representative organizations using the system. The goals should be
relevant to, but independent from, the proposed system. System-specific goals would be
documented as Project Goals.

1. A brief enumerated list of goals. To facilitate traceability, assign each goal a unique number (e.g. OG-
1). For example:

OG-1: Increase sales and profits via more efficient order processing.

OG-2: Improve speed via faster order entry.

OG-3: Improve quality via better in-process order visibility, reduced order defects.

OG-4: Improve customer satisfaction via better and faster operations.

2. A set of tables, one for each goal, like Table 1.

Table 1: Organizational Goal Form

Goal Identifier: <<Give a reference number>> such as “OG-1”

Organization Goal: <<Give a reference number and name>> such as “Increase Sales and Profits”

Description: <<Describe the goal within the relevant organizations>> This may be deleted if the title
describes it adequately, as above
Measurable:
<<Indicate how this goal is measured, perhaps within the results chain OCD 2.1>> such as
“Since sales and profits normally vary by quarter, increases will be measured with respect to
the corresponding quarter in the previous year.

Relevant: <<Describe how this goal is relevant to the organization’s success factors OCD 2.4 and
background OCD Error: Reference source not found>> such as “Increased sales improve
profits via increased volume and economies of scale.”

 
Common Pitfalls
 Including elements from the proposed system (i.e. elements that do not currently exist,
but are planned to be built).
 Including system capabilities or behaviors of the proposed system.
 Having superfluous activities that are not referenced by anything later.
 Describing the current system rather than domain activities

1.2 Key Stakeholders 

Identify each stakeholder by their home organization, their authorized representative for
project activities, and their relation to the Results Chain. The four classic stakeholders are the
software/IT system’s users, customers, developers and maintainers. Additional stakeholders
may be system interfacers (the order fulfillment people above), subcontractors, suppliers,
venture capitalists, independent testers and the general public
1.3 System Boundary and Environment 

The system boundary distinguishes between the services your project will be responsible for
developing and delivering and the stakeholder organizations and interfacing systems for
which your project. This section includes the context diagram of your system

1.4 Project Goals and Constraints 

 Project Goals are factors, project-level constraints and assumptions that influence or
contribute to the eventual outcome of the project: such as legacy code or systems,
computer system compatibility constraints, COTS compatibility constraints, budget
limits and time deadlines. Project Goals may carry out or support Organization Goals
and Activities. 
 Project Goals are separate from Capabilities: Project Goals usually affect many parts
of the system, whereas Capabilities address more local and specific areas
 Project Goals should be M.R.S. (Measurable, Relevant, Specific). Note that the Project
Goals may also be relative to the infrastructure on which the system is based.

Describe in detail any goals and constraints that are critical to the project’s success, such as:

 The project shall be completed rapidly to sustain the company’s competitive edge.
 The user interface must be compatible with other company systems.

 The system must be able to adapt to changes in Internet sales tax laws.

 The system must be compatible with legacy code or systems.

 The software must run on the XXYY computer system.

 The software must be compatible with (or use) the ABC COTS package.

 Build the system within the budget of a gazillion US dollars. 

Common Pitfalls
 Including Organization Goals as Project Goals
 Including Capabilities as Project Goals
 Including Project Goals that do not reference Organization Goals or Activities
 Including Project Goals that are not referenced by Project Requirements.

1.5 System Capabilities 

 This section describes overall what products and services the operational stakeholders
ideally expect from the proposed system with respect to their organizations, including
desired modifications to the current system.
  Capabilities provide a high level overview of broad categories of system behaviors, as
opposed to an operational breakdown provided by System Requirements. Capabilities
should realize high-level service activities provided in the Context Model (the picture
of how the new system fits into the organizations world).
 Capabilities should be detailed enough to be sufficiently testable that one can
determine if the capability has been implemented.

1. Capabilities should be detailed enough to be sufficiently testable that one can determine if
the capability has been implemented. The following examples show the desired level of
granularity or a capability.
 “Maintain up-to-date information on sales items”
 “Provide a virtual experience of touring the Doheny Library”
 “Report all leave records of the employees for a given period of time”


Common Pitfalls
 Including System Requirements as Capabilities (thus making them too detailed).
 Including Levels of Service as Capabilities.
 Including System Behaviors as Capabilities. Those belong in Design.
 Including too many Capabilities for a relatively small system (some of them may be
either System Requirements or System Behaviors)

2. Requirements Definition  
Requirements describe all the services provided by the system and include Level of Service
Requirements as needed. Every single detail that designers need to know must appear in the
requirements definition. If it's not here then:

 it doesn't get implemented, or

 the designers guess at the details

2.1 Project Requirements  

Project Requirements are general constraints placed upon the design team, e.g.,
constraints on the way that the problem must be solved, such as a mandated
technology. If project requirements were left unmet, then the proposed system
would not be acceptable.
 Example: "The system shall use the Microsoft Active Server Pages technology"

 Example: "The system must have the core capabilities [specify which ones] by IOC within twelve
weeks"
 2.2 System Requirements 

 System Requirements should be a refinement of OCD Capabilities.

 Each Capability must translate into at least one System Requirement (be sure to
reference which one).
 System Requirements refer to what the system has to do; the design will tell how it
will be implemented).
 In general a Use Case and some scenarios are used to give requirement details.

2.3 System Interface Requirements  

Describe any applicable requirements on how the software should interface

with other software systems or users for input or output.

3. Design 

3.1 Architecture Design  

This section will identify the software and hardware components of the system. It
describes how the components interact, and how specifically they communicate. It should,
as much as is feasible, be free of implementation details. That comes later.

3.1.1        Structure and Topology

What does the system look like? Good place for block diagrams, description of layers,
subsystems, and/or subsystems.

3.1.2        Hardware Required

Anything that must be solved to make the hardware "work" within your system must be
documented, e.g. hosting issues for website,  connectivity for computers, etc.

3.1.3        Software 

This section is the guts of your work. Here you identify subsystems, modules or packages
Anything that must be implemented must have a full design. O-O classes, HTML pages, user
interfaces, data base schemas, etc.

3.2 System Services and Processes 

 Here you must prove that the designed system will fulfill its requirements. Focus on the
users of the system and what services the system is providing them. Before we had
capabilities and requirements, now we have specific services that produce the required
behavior.
 3.2.1        The Processes

A good way to model the services is as use-cases, but this time, the external players must
be interacting with components through formal computer protocols and interfaces. The
same object classifiers might appear as in the requirements, but now they have to be
"computerized."

Life Cycle Planing (LCP)

Sections that is required as mentioned in the long LCP descrioption is as follows:

Section: 1.1, 1.2, 2.2, 3, 3.1

Fesasibility Report Description (FRD)

Sections that is required as mentioned in the long FRD descrioption is as follows:

Sections: 1, 2.1, 2.2, 4, 5.2