Systems Analysis & Design
Introduction | Specification of Information Systems | Methodologies for Systems Development | Strategy in Analysis & Design | An Example | References
My experience has shown that many people find it hard to make their design ideas precise. They are willing to express their ideas in loose, general terms, but are unwilling to express them with the precision needed to make them into patterns. Above all, they are unwilling to express them as abstract spatial relations among well-defined spatial parts. I have also found that people aren't always very good at it; it is hard to do..... If you can't draw a diagram of it, it isn't a pattern. If you think you have a pattern, you must be able to draw a diagram of it. This is a crude, but vital rule. A pattern defines a field of spatial relations, and it must always be possible to draw a diagram for every pattern. In the diagram, each part will appear as a labeled or colored zone, and the layout of the parts expresses the relation which the pattern specifies. If you can't draw it, it isn't a pattern.
Christopher Alexander (1979) in The Timeless Way of
Building.
One anxiety inherent in the design methods is the hierarchical nature of complexity. This anxiety moves in two directions, escalation and infinite regression. I will use a story, "The Warning of the Doorknob," to illustrate the principle of escalation.
This has been my experience in Washington when I had money to give away. If I gave a contract to a designer and said, "The doorknob to my office doesn't have much imagination, much design content. Will you design me a new doorknob?" He would say "Yes," and after we establish a price he goes away. A week later he comes back and says, "Mr. Eberhard, I have been thinking about that doorknob. First we ought to ask ourselves whether a doorknob is the best way of opening and closing a door." I say, "Fine, I believe in imagination, go to it." He comes back later and says, "You know, I have been thinking about your problem, and the only reason you want a doorknob is you presume you want a door to your office. Are you sure that a door is the best way of controlling egress, exit, and privacy?" "No, I'm not sure at all." "Well, I want to worry about that problem." He comes back a week later and says, "The only reason we have to worry about the aperture problem is that you insist on having four walls around your office. Are you sure that is the best way of organizing this space for the kind of work you do as a bureaucrat?" I say, "No, I'm not sure at all." Well, this escalates until (and this has literally happened in two contracts, although not exactly through this process) our physical designer comes back with a very serious face. "Mr. Eberhard, we have to decide whether capitalistic democracy is the best way to organize our country before I can possibly attack your problem."
On the other hand is the problem of infinite regression. If this man faced with the design of the doorknob had said, "Wait. Before I worry about the doorknob, I want to study the shape of man's hand and what a man is capable of doing with it," I would say, "Fine." He would come back and say, "The more I thought about it, there's a fit problem. What I want to study first is how metal is formed, what the technologies are for making things with metal in order that I can know what the real parameters are for fitting the hand." "Fine." But then he says, "You know, I have been looking at metal forming and it all depends on metallurgical properties. I really want to spend three or four months looking at metallurgy so that I can understand the problem better." "Fine." After three months he will come back and say, "Mr. Eberhard, the more I look at metallurgy, the more I realize that it is the atomic structure that's really at the heart of this problem." And so, our physical designer is in atomic physics from the doorknob. That is one of our anxieties, the hierarchical nature of complexity.
Eberhard (1970) quoted in Teague & Pidgeon (1985) and
Yourdon (1989).
Introduction
The work of Christopher Alexander, a mathematician-turned architect, has had a subtle and yet a profound impact on the methodologies for the development of information systems in business. The main idea in architecture, espoused by Alexander, is that buildings and cities can be designed from the combination of certain basic patterns. Such patterns can be documented as diagrams which, in the architectural domain, specify spatial relationships. In the domain of business (and accounting) information systems development, the task is to create languages for describing and manipulating patterns to create systems that meet the needs of business.
In this note, we shall study the way in which information systems are specified, and the methodology of Systems Development Life Cycle (SDLC) that is often used in the development of accounting information systems.
Return to Contents
Specification of Information Systems
Why specifications?
Specification of any system before its development is crucial. Specifications perform for information systems the same function that blue-prints and engineering specifications perform for physical structures. Specifications serve as benchmarks for evaluating designs as well as their implementation. They also facilitate quality assurance via verification (are we building the system right, ie., do the design and implementation meet the specifications?) and validation ( are we building the right system, ie., does the system meet the user needs?).Components of specifications
Specification of an information system is given by their
- Structure: How it is organised.
- Function: What it does.
- Behavior: How it responds to events and stimuli.
- Data: Its meaning and organization.
Methodologies for Systems Development
There are many methodologies for the development of information systems: Systems Development Life Cycle (SDLC), Data Structure-Oriented design, Object-Oriented design, Prototyping, among others. We shall, however, be concerned here primarily with SDLC.Systems Development Life Cycle:
Referred to variously as the waterfall model and linear cycle, this methodology is a coherent description of the steps taken in the development of information systems. The reason why it is referred to as the waterfall model should be obvious from the following figure (from Horner, 1993):
- Problem definition: On receiving a request from the user for
systems development, an investigation is conducted to state the problem to be
solved.
- Deliverables: Problem statement.
- Feasibility study: The objective here is to clearly define the
scope and objectives of the systems project, and to identify alternative
solutions to the problem defined earlier.
- Deliverables: Feasibility report.
- Systems analysis phase: The present system is investigated and its
specifications documented. They should contain our understanding of HOW
the present system works and WHAT it does.
- Deliverables: Specifications of the present system.
- Systems design phase: The specifications of the present system are
studied to determine what changes will be needed to incorporate the user needs
not met by the system presently. The output of this phase will consist of the
specifications, which must describe both WHAT the proposed system will
do and HOW it will work.of the proposed system.
- Deliverables:Specifications of the proposed system.
- Systems construction: Programming the system, and development of
user documentation for the system as well as the programs.
- Deliverables: Programs, their documentation, and user manuals.
- System testing & evaluation: Testing, verification and
validation of the system just built.
- Deliverables: Test and evaluation results, and the system ready to be delivered to the user/client.
- Clearly defined deliverables at the end of each phase, so that the client can take decisions on continuing the project.
- Incremental resource committment. The client does not have to make a full committment on the project at the beginning.
- Isolation of the problem early in the process.
- Requires an all-or-nothing approach to systems development. Does not allow incremental development.
- Requires very early isolation of the problem. In the real world, often the problems are uncovered in the process of development of systems.
Strategy in Analysis & Design
The understanding and management of complexity is perhaps the most important task of the designer of an information system. It is carried out bearing in mind the strategies of abstraction as well as hierarchical ordering (divide & conquer).In the real world, an accounting information systems designer (systems designer for short) is rarely called upon to analyse and design a system from the scratch. Usually, such a system does exist, but the client (user) is not quite satisfied with it. The systems designer starts with the documentation of the existing accounting system, if it does not exist. Often, documentation pertaining to the existing system is contained in the audit workpapers pertaining to the auditor's study of control risk assessment. However, since such documentation is not prepared with a view to design a system, it is used only as a starting point in building the documentation to aid systems design.
In this document, we shall study how abstraction and hierarchical ordering strategies are used to manage the complexity of analysing and designing the functions of an information system.
The methodology of structured systems analysis & design provides a roadmap for the development of functional specifications for an accounting information system, shown in the Figure below.
The functional specifications are documented graphically in Dataflow Diagrams (DFDs)
described in the next section below.
STEP 0: (Defining the scope of the system under study.) This accomplished by drawing the context diagram for the system.
STEP 1: (Documentation of how the existing system works.) This is accomplished by drawing the Physical DFDs of the existing system. These DFDs specify the current implementation of the existing system, and would answer questions such as:
- Who performs the tasks?
- How they are performed?
- When or how often they are performed?
- How the data is stored (media)?
- How the dataflows are implemented (media)?
STEP 2: (Documentation of what the existing system does.)This is documented in Logical DFDs of the existing system. Deriving these logical DFDs of the existing system from the physical DFDs involve abstraction of all implementation details. Since the systems designer would not like to be tied down by the current implementation of the system, all such details are abstracted. These logical DFDs are usually levelled in order to reduce the perceived complexity of the system, and balanced in order to assure consistency in the design.
STEP 3: (Documentation of what the proposed system will do.) After step 2, the systems designer will examine why the existing system does not meet the user requirements, and how it can be modified in order to meet such needs. The result is a set of logical DFDs which describe what the modified (proposed) system will do. These functional specifications are devoid of implementation considerations, and therefore rather abstract specifications of the proposed system. These logical DFDs are also levelled and balanced.
STEP 4: (Documentation of how the proposed system will work.) The logical DFDs of the proposed system derived in step 3 above are then examined to determine which implementation of it meets the user requirements most efficiently. The result is a set of physical DFDs of the proposed system. They answer questions such as:
- Who will perform the various tasks?
- How they will be performed?
- When or how often they will be performed?
- How the data will be stored (media)?
- How the dataflows will be implemented (media)?
The function of any information system can be expressed in
terms of transformation (processing) of certain inputs (which are data) into
outputs (which are data too) where memory (which too consists of data) may need
to be consulted (or updated). This suggests that two crucial elements in a
system's description are data and processing of data. A complete
description of an information system demands description of both these elements.
In fact, we can reduce this, in a mundane fashion to the equation:
System = Data + Processing of data
While it is impossible to describe an information system exclusively in
terms of data or its processing, it is possible to study a system's functions
(what the system must do) in terms of the transformations it must perform of the
data which is modeled separately. A coherent description of the information
system, however, would require that the models of data and its processing are
not inconsistent. An information system's functions, which describe its
processing aspects, is modeled in the structured systems approach, as dataflow
diagrams.Such a model of an information system is, for obvious reasons,
referred to as functional model or process model.A dataflow diagram consists of external entities (represented by rectangles), processes (represented by either rounded rectangles or circles), data stores (represented by either an open rectangle or two parallel lines) and dataflows (represented by arrows).
Return to Contents
An Example
A Toy Sales Order Entry & Processing System:
I give below the functional specifications for a toy sales order entry and processing system. The specifications given are for the logical aspects of the system only, and therefore are, incomplete. They are also incomplete in that the behavior model is absent. They are given as illustrations only. They consist of:- Context diagram
- levelled logical dataflow diagrams
- Relation specifications for a Relational Database
- Specifications for the dataflows
- Process descriptions in raw prolog code. (Prolog is a relational language.
The code is given
here, since prolog code is generally easily grasped). The code given here, with very minor
changes, should be executable.
We have yet to discuss the data models and databases. We will not be discussing programming aspects of systems. Therefore, the database specifications are given as a prelude to our class discussions on databases later in the semester. The code is given just for the purpose of appreciation.
We are talking about a very small firm that considers orders from customers for one item. You should be able to add bells and whistles as you wish. The situation considered is rather unrealistic, but it makes important points about specifications for an accounting system and its documentation.
Table of Contents
- Context Diagram
- Level 0 Logical Dataflow Diagram
- Level 1 Logical DFD: Sales Order Entry Sub-system
- Level 1 Logical DFD: Sales Order Processing Sub-system
- Dataflow Specifications
- Datastore Specifications
- Process Specifications
Context Diagram: (Sales Order Entry & Processing System)
Level 0 Logical Dataflow Diagram:(Sales Order Entry & Processing System)
Level 1 Logical Dataflow Diagram:(Sales Order Entry Sub-system)
Level 1 Logical Dataflow Diagram:(Sales Order Processing Sub-system)
Dataflow Specifications
Syntax: dataflowName(attribute1, attribute2,.....)order(CustomerName, CustomerAddress, Item, Quantity) pricedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice) weDontSell(CustomerName, CustomerAddress, Item) sorryBadCredit(CustomerName, CustomerAddress) approvedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice) sorryNotInStock(CustomerName, CustomerAddress, Item) acceptedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice) salesOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice) billOfLading(CustomerName, CustomerAddress, Item, Quantity) invoice(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)Return to Table of Contents (Example)
Datastore Specifications
Syntax:relationName(attribute1, attribute2,......)priceList(Item, Price) customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit) inventoryMaster(Item, QuantityOnHand) salesOrderMaster(CustomerName, Item, Quantity, OrderPrice) billOfLading(CustomerName, Item, Quantity) openInvoices(CustomerName, Item, Quantity, OrderPrice) customer(CustomerName, CustomerAddress) order(CustomerName, CustomerAddress, Item, Quantity)Return to Table of Contents (Example)
Process Specifications:
Syntax:prolog clause/* Orders are priced by multiplying the quantity ordered by the */
/* price for the item on the price list */
pricedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
if
order(CustomerName, CustomerAddress, Item, Quantity),
priceList(Item, Price),
orderPrice is Price * Quantity.
/* We don't sell the item ordered by the customer if such item */
/* is not on the price list */
weDontSell(CustomerName, CustomerAddress, Item)
if
order(CustomerName, CustomerAddress, Item, Quantity),
not priceList(Item, _).
/* A customer order for an item is approved if the order is priced */
/* and the account balance after the order is less than the credit limit */
approvedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
if
pricedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice),
customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit),
NewBalance is Balance + OrderPrice,
NewBalance < CreditLimit.
/* A customer order is rejected on account of bad credit if the */
/* order is priced and the account balance after the order */
/* exceeds the credit limit for the customer */
sorryBadCredit(CustomerName, CustomerAddress)
if
pricedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice),
customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit),
NewBalance is Balance + OrderPrice,
NewBalance >= CreditLimit.
/* A customer order is accepted if it is approved and the quantity on */
/* hand of the item ordered is at least as much as the quantity ordered */
acceptedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
if
approvedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice),
inventoryMaster(Item, QuantityOnHand),
QuantityOnHand >= Quantity.
/* A sales order is prepared if a customer order is accepted */
salesOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
if
acceptedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice),
/* A bill of lading is prepared if a sales order is prepared */
billOfLading(CustomerName, CustomerAddress, Item, Quantity)
if
salesOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice).
/* An open invoice is prepared if a bill of lading is prepared */
openInvoices(CustomerName, Item, Quantity, OrderPrice)
if
billOfLading(CustomerName, CustomerAddress, Item, Quantity).
/* A customer's account is updated by adding the order price to the */
/* current balance in the account if open invoice is prepared */
updateCustomerAccountsForInvoices
if
openInvoices(CustomerName, Item, Quantity, OrderPrice),
retract(customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit)),
NewBalance is Balance + OrderPrice,
assert(customerMaster(CustomerName, CustomerAddress, NewBalance, CreditLimit)).
Return to Table of Contents (Example)References
Alexander, C. (1971). Notes on the Synthesis of Form, 2d ed. Cambridge, MA: Harvard University Press.Alexander, C. (1979). A Timeless Way of Building. New York, NY: Oxford University Press.
Eberhard, J. (1970) "We Ought to Know the Difference", in Engineering Methods in Environmental Design and Planning, Gary T. Moore, ed. Cambridge, Mass.: MIT Press. pp.364-365.
Harel, D. (1987). Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, pp.231-274.
Horner, K. (1993). Methodology as a Productivity Tool, in Software Productivity Handbook, J. Keyes (ed), New York, NY: Windcrest/McGraw-Hill, pp.97-117.
Pressman, R. (1987). Software Engineering: A Practitioner's Approach, 2d ed. New York, NY: McGraw-Hill.
Teague, L and C. Pidgeon. (1985) Structured Analysis Methods for Computer Information Systems. Chicago, Ill.: Science Research Associates.
Yourdon, E. (1989) Modern Structured Systems Analysis. Englewood Cliffs, NJ: Prentice Hall.
Yourdon, E. (1993). A Natural Productivity in Object-Orientation, in Software Productivity Handbook, J. Keyes (ed), New York, NY: Windcrest/McGraw-Hill, pp.97-117.
Return to Contents
No comments:
Post a Comment