A Project Newsletter


Facilitating Projects

 

Collaborating to Accelerate Progress

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 

 

Volume I

TECHNICALLY SPEAKING...

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

Resource Alliance, 2005
A cooperative venture between Resource Advantage, Inc., Diakon Consulting, Inc. and Chaosity LLC

If you do not want to receive this newsletter, please reply to this email and say "Unsubscribe".

Resource Advantage |  Diakon Consulting | Chaosity

Resource Alliance
New York - Kansas - Arizona - North Carolina
Phone:
518-663-5232
316-636-2940
480-775-8756
704-599-3297