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.
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.
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):
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:
* Problem definition: On receiving a request from the user for systems development, an investigation is conducted to state the problem to be solved.
o 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.
o 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.
o 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.
o Deliverables:Specifications of the proposed system.
* Systems construction: Programming the system, and development of user documentation for the system as well as the programs.
o Deliverables: Programs, their documentation, and user manuals.
* System testing & evaluation: Testing, verification and validation of the system just built.
o Deliverables: Test and evaluation results, and the system ready to be delivered to the user/client.
The figure below provides an illustration for the above description.
The waterfall model has many attractive features:
* 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.
It does, however, have some drawbacks:
* 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)?
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:
* 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)?
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).
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 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)).
No comments:
Post a Comment