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).
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 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?).
Specification of an information system is given by their
Most CASE tools co-ordinate information systems projects through a project or system dictionary. The function of the dictionary is to standardise the use of terms throughout the organisation and to serve as a repository of all common information in the project. It enforces consistency as well as (relative) completeness of the specifications, and facilitates verification & validation of such specifications. It also serves as a means of communication between the different persons on the information systems building team.The figure below shows the various components of the specifications and the modeling techniques utilised. We will be studying some of those techniques in this course.
Return to Contents
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.
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):
The methodology SDLC is closely linked to what has come to be known as structured systems analysis & design. It involves a series of steps to be undertaken in the development of information systems as follows:
The figure below provides an illustration for the above description.
The waterfall model has many attractive features:
It does, however, have some drawbacks:
Return to Contents
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:
These physical DFDs may be levelled, or, if the system is not very large, prepared all on a single DFD.
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:
In this step, man-machine boundaries are drawn, and media selected for all dataflows & datastores.
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
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:
I will not provide the physical DFDs below, since they are implementation dependent, and I have not based this toy system on any real-world accounting system.
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.
Return to Table of Contents (Example)
Return to Table of Contents (Example)
Return to Table of Contents (Example)
Return to Table of Contents (Example)
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)
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)
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)
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
Updated on October 12, 1997 by Jagdish S. Gangolly.