Requirements Analysis DeliverableColumn Four

Team-Fly    

 
Requirements Analysis: From Business Views to Architecture
By David C. Hay
Table of Contents
Chapter 5.  Column Four: People and Organizations

Requirements Analysis DeliverableColumn Four

The Row One scope should have identified the part of the organization to be addressed by each particular project.

For a particular project, then, as described above,

Requirements analysis is the examination of an organization to determine the most effective amplifiers and attenuators to build. What are needed? How are those now in place ineffective or counterproductive? What should they look like, given the purpose and organization of the enterprise?

The assignment of the system developer is to provide the tools to reduce the variety experienced by a manager. It is not to provide more information, it is to provide less information, but the right less. To do this, the systems analyst must understand not only what the business player says, but also what the true role of that business player is in the organizationin cybernetic terms.

To be sure, it will be necessary to deliver organization charts, matrix management charts, or charts describing how the enterprise is to be organized. In particular, it is necessary to articulate the structure of the part of the enterprise to be addressed by this project. Having said that, the Column Four deliverable must also include:

  • Identification of the parts of the organization that correspond to the five systems of a particular enterprise

  • Identification of the amplifiers and filters required

  • Definition of the entities, functions, locations, events, and business rules that must be brought together to construct each filter and amplifier

  • Description of the interactions of various players in carrying out the functions of the five systems (use cases)

Are we supporting System Two, the simple coordination of different Systems One? Are we serving System Three, which is trying to find the synergy among Systems One? Are we perhaps reporting on the world at large for System Four, required as we are to provide enough information about the world to be useful, even as we filter that information so that it can be absorbed? Or, are we supporting System Five, helping that system understand the specifics of a System Four proposal, along with its implications on the operation of System Three and the lower levels?

The answer to these questions will dramatically influence the kinds of systems we build.

Note that the very act of drawing the models described elsewhere in this book acts to reduce variety. This is a very confusing enterprise. By selecting things to look at (entity types, processes, events, etc.), we are able to look at a piece of it and thus are able to grasp significant truths about the enterprise as a whole. By discussing these models with a manager, we give that manager tools for understanding the variety of the enterprise.

Ultimately all of the systems we build will feature exception reporting. The trick is to design the logic for determining which exceptions to show. Something like a use case can be helpful in identifying the nature of these exceptions.

To do all this effectively, we must truly understand the particular information that is required to perform the job. This ultimately is why data modeling is more important than process modeling. If you can understand the variety equation for a particular managerial task, you know what is needed from a system that supports that task. To know just the nature of the task itself is actually less important.


Team-Fly    
Top
 


Requirements Analysis. From Business Views to Architecture
Requirements Analysis: From Business Views to Architecture
ISBN: 0132762005
EAN: 2147483647
Year: 2001
Pages: 129
Authors: David C. Hay

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net