|
Brought to you by Resource Alliance
|
|
Larry Garrison
President of
Diakon Consulting, Inc.
With over
25 years of experience in Information
Technology both as a technician and as a technology manager,
Mr. Garrison is skilled in all aspects of the Software
Engineering Life Cycle, Project Management and Process
Management.
His training in leadership techniques,
motivational theory and continuous process improvement
have enabled him to manage large organizations and
projects to solve business problems through the
appropriate application of technology.
|
|
ABOUT US |
|
Resource Alliance
is a cooperative venture between three companies -
Resource Advantage, Inc., Diakon Consulting, Inc.,
and Chaosity LLC - who have joined
forces to provide specialized collaborative
consulting, training and facilitation
services.
|
Back to
top |
|
|
Effective Transition
from Business Requirements to System
Design
|
One of the perennial challenges in the
development of business systems is to have software
developers build what the business users want in a
system.
We’ve all seen the cartoon depicting a tire swing
as the user requirement and the various distortions that
took shape through the stages of the software
development life cycle. The resulting
device only slightly resembled the desired outcome.
Strother Martin said it best in Cool Hand Luke, “What we
have here is failure to communicate.” The Project
Charter/Scope and Business Requirements Definition were
created by the business users in their terms, and from
their perspective, they are clear and complete. The software
developers, however, do not have the same perspective
and do not always understand the requirements
narrative.
The solution of course is to bring both groups
together in collaborative work sessions to develop
models that translate the business requirements into
useful design constructs. Details of the
models and processes for building them can be found in
David Brown’s book, An Introduction to
Object-Oriented Analysis: Objects in Plain
English.1
Briefly, both business and technical subject
matter experts meet together with a facilitator and an
experienced scribe who creates the models. The model that
will serve as the guide for subsequent design,
construction and testing activity is the Class
Diagram. It
is the central model of Object Oriented Analysis &
Design (OOAD), but is also a useful tool for defining
systems that are procedural. Classes are
modeled much like Entity Relationship Diagrams, but they
also contain the functions or methods that define the
behaviors of each entity or class. We arrive at
this model by first depicting the project scope as a
context diagram.
The system is shown interacting with other
organizations and systems (external agents) outside the
boundaries of the functions it is expected to
perform.
Within the scope of the system, users interact to
accomplish tasks.
These tasks are initially extracted from the
Business Requirements narrative and illustrated in Use
Cases. The
work session participants will use the Business
Requirements document as their starting point for
brainstorming the functions of the system. These functions
will be illustrated in Use Case diagrams such as this
simplified example.
Once the Use Cases have been created, the
participants will begin selecting the “real world”
objects or entities referenced in these diagrams. The
resulting list of entities are the Candidate Classes.
The group then collaborates to define the
characteristics (attributes) and the behaviors (methods)
of each Class.
Finally, they will determine the associations
between all the identified Classes. The resulting
diagram will resemble the following
example:
So,
in a nutshell, to bridge the gap between business
requirements and system design, you need to follow these
three steps:
-
Step 1 – Depict the project scope in a
Context Diagram
-
Step 2 – Draw Use Case Diagrams from
discussion centered around the Business Requirements
document
-
Step 3 – Build Class Diagrams from the Use
Cases and group
brainstorming
If your Information Technology organization
rarely if ever fails to grasp and fulfill your business
requirements and these requirements accurately represent
what you really want to occur, ignore everything I have
said, and send me an overview of your software
development methodology. If however, you
are looking for ways to improve communication between
business and technical associates, reduce the time
required to develop new systems, reduce system
maintenance costs and improve the quality and
performance of your computing applications, you may want
to consider employing these Object Oriented concepts on
your next project.
1.
Brown, David. 1997. An Introduction to
Object-Oriented Design: Objects in Plain
English.New
York: John Wiley & Sons,
Inc.
Back to
top |
|