OVERVIEW: SYSTEMS ANALYSIS AND DESIGN TOOLS

ACCA Paper 5

4th April 2001

Objectives

 

1 ANALYSIS AND DESIGN TOOLS

This session covers the most commonly-used analysis and design tools. All of the tools can be used at the analysis stage of the system development life cycle to examine and record the operation of the current system, or at the design stage to prescribe and document the proposed new system.

While it is important that you are able to apply some of the tools (such as data flow diagrams and entity life histories) others need only be discussed. The relevant sections make it clear what approach will be taken by the examiner in each case.

2 LOGICAL DATA TOOLS

These tools are all used at the FIRST stage of analysis or design. They deal with the logic of the data structure within the system – where the data comes from, where it is stored, which processes it passes through and how it is delivered to the user. The tools also look at the relationships between data items. Three are considered here:

2.1 Entity-relationship model (or Logical Data Structure)

An unique attribute uniquely identifies a particular entity occurrence (eg product-code). Relationships (ie relevant business connections between two entities) are represented by a line.

The ERM is a tool used to examine the way in which things of significance to the system (entities) relate to each other. A Logical Data Structure (LDS), which uses the same diagram, is used in the logical design of database structures. Therefore, in the following description and application, the "entity" could also be a "data item".

2.1.1 Symbols used

Illustration 1

A company is run by a Chief Executive Officer, who only works for this company. The company has several divisions, each of which employs many people; no employee works for more than one division. Each division produces a number of products; no product is made in more than one division. Each product uses a number of raw materials, each of which may be used in more than one product.

Solutions

It is unlikely that, in the examination, you would be required to draw anything more complicated than this. The examiner does require that you be able to construct from first principles and interpret. You should also be able to criticise the logic of a diagram which contains obvious errors.

 

Example 1

An audit firm is made up of a number of departments. Each department is broken down into audit groups. Each group is managed by a different manager. Auditors are assigned to an audit group, and within a group the auditors work together on a range of projects.

Required:

Draw the ERM.


2.2 Entity life history

An ELH considers the events (ie stimuli NOT processes) that change stored data. Events may be external (eg a transaction), internal (eg stock level reaches re-order level) or time-based. The effect of each event may be creation (C), deletion (D) or modification (M) of an entity occurrence.

 

An ELH shows the life of something of significance to the system (an entity). The life begins with the first point of contact between the entity and the system, proceeds through the things that happen between the entity and the system, and ends with the last contact between them.

Illustration 2

A bank customer opens an account. There are a series of transactions which can include deposits, withdrawals and interest payments. The customer closes the account.

Solution

Example 2

Students register with ATC and attend a series of courses and sit a number of examinations. The courses can be introductory, booster or revision courses. The students either pass or fail their examinations (although this is very rare). After a few years, students qualify.

Required:

Draw the ELH for the student from the point of view of ATC.

 

2.3 Data dictionary

A central repository holding records of data about data elements, data structures, data stores and processes.

It is an index of the data held in the system used to assist in the maintenance of, and access to, the data. It can be maintained on paper and manually compiled and updated. Data is usually held on a Data Dictionary Software package or in a CASE tool (see later).

Each item of data would have an entry in the dictionary, and the following details would be shown.

Illustration 3

3 LOGICAL PROCESS TOOLS

These tools are used at the SECOND stage of analysis or design. They look at the logical sequence of processes and the data flows between them, for example:

3.1 Flowcharts

Flowcharts are no longer examinable in Paper 5. They are regarded as too technical, and are seldom used by anyone other than analysts and programmers. Flowcharts are thought to be too ambiguous and complex to be of value as a communication tool for users.

3.2 Data flow diagrams

A graphical representation of the passage of data through a system which is widely used in structured methods.

Data flow diagrams are a user-friendly tool for documenting the flow of data into the system, within it, and out of it. They use a very limited range of symbols and should be easy to draw and understand. There are a number of different symbol sets in use, those here being from the National Computer Centre of the UK.

3.2.1 Basic constructs

Data source or destination (sink) – external entities enter or receive data from the system but are outside the scope of the application.

Data flow – arrowed lines (showing direction of flow) connecting external entities, processes and stores.

Process – activities which transform incoming data flows to outgoing data flows. Numbered for identification NOT to show sequence.

Data store – open-ended rectangles have unique names (eg, customer).

 

3.2.2 Context diagram

The topmost (ie one process) diagram which summarises the inputs and outputs of a system under consideration. (A level 0 DFD.)

When analysing or designing a system, these symbols are used to create a hierarchical series of diagrams, starting with a level-0 or "context" level diagram, which shows the whole system as one process, and also the sources and destinations of data.

Illustration 4

Context diagram for a sales order system:

The context level diagram will then be "exploded" into a more detailed level-1 diagram, again showing the whole system, with the main processes and data stores.

Illustration 5

The context diagram above might be exploded into a level-1 diagram as shown.

 

 

In a more complex system, each process in the level-1 diagram would be further exploded into a series of level-2 diagrams, each showing only part of the system.

Illustration 6

Process 2 from the above diagram could be exploded as shown below:

In the examination you may be asked one of a number of different-style questions on data flow diagrams.

If you are asked to draw a data flow diagram, the examiner normally only requires a level-1 diagram as this shows that you understand the theory and can apply it.

Example 3

The purchasing department of a manufacturing company follows the procedure described when ordering goods.

Following a request from the stores, a purchase order document is completed and sent to the appropriate supplier. A copy of the purchase order is kept in the "orders outstanding" file. When the goods and despatch note are received from the supplier, the details on the despatch note are compared with the copy of the purchase order. Any differences are reported to the supplier by telephone. The copy purchase order is then filed in an "orders received" file.

The goods are checked to see if they agree with the despatch note details. Any differences are reported to the supplier by telephone. The goods and the despatch note are sent to the stores.

Required:

Draw a data flow diagram of the above procedure.

 

4 PHYSICAL TOOLS

These tools are all used to define the precise operation of an individual process or the structure of a data store. Quite often these tools form the FINAL stage of analysis or design and are used after data flow diagrams, to describe individual elements on the lowest level data flow diagrams.

4.1 Decision trees

This diagrammatic method of representing process logic shows the alternative actions that can result from different combinations of circumstances. The "fallen tree" is read from left ("root") to right ("branches").

You will be familiar with decision trees from your earlier Paper 3 Management Information studies . In Information Analysis the trees are descriptive so you will not be required to calculate expected values.

4.2 Decision tables

A decision table is a diagrammatic representation of a decision. The decision process is broken down into a series of "conditions". These are simple questions with yes/no answers. Depending on the answers to these conditions, one or more of a range of "actions" are taken.

A decision table is divided into four areas as shown below.

4.2.1 Limited entry decision tables

Conditions are expressed as questions to be answered yes (Y), no (N) or irrelevant (–). Action entries are limited to X (ie "take this action") or blank (ie "do not take this action").

Only these types of decision table provide the unambiguity and precision necessary for structured methods.

Illustration 7

A decision whether to pay a supplier invoice might be presented as follows:

4.2.2 Points in construction

4.2.3 Redundant rules

Note that the decision table shown above can be simplified. This is because it has been drawn in full, and some of the conditions are not relevant in all cases. The decision table can be "reduced" if a dash is inserted to show that a condition is not applicable (eg in rules 3, 4, 7 and 8). This can also be done to rules 5 and 6 as shown below:

In the examination you may be required to describe a decision table, correct one, or draw one from a narrative description.

Example 4

A night-club has a range of entrance charges which it applies to different customers.

In the case of employed people, the charge is $5 for females and $2 for males, unless an employed male is at least 40 years old in which case he is charged $7. Unemployed people are charged 25 cents.

Required:

Draw the full decision table, then remove the redundant rules.

Solution-Reduced table

 

 

4.3 Structured English

Standard narrative constructs are used to describe a process. It is an approach rather than a set of rules.

Describing a process in English is the simplest way to define if, but English is like all languages in that it has ambiguities. This makes normal English unsuitable as a means of defining any but the simplest process.

Structured English attempts to solve this problem by using a limited vocabulary consisting of keywords, actions and conditions, but no pronouns eg IF, THENDO, ELSE, END, GOTO, AND, ENDDO, ENDIF etc.

4.3.1 Constructs

Illustration 8

It is very unlikely that you will be required in the examination to do anything more than describe the use of structured English or deal with a very basic structured English statement.

4.4 Normalisation

A data analysis technique used to reduce or eliminate the effect of system changes on file structures.

Data normalisation is a process used to optimise the performance of a database by reducing the volume of data contained in it. Normalisation does this in two ways.

Normalisation is a very common technique when designing relational databases. For each data table/file it is only necessary to have a linking field. There is no need to repeat data within each file.

5 CASE TOOLS

5.1 Definition

CASE stands for computer aided software (or system) engineering. A CASE tool is a software solution that supports the construction and maintenance of logical system specification models.

5.2 CASE facilities

Solution 2 – ELH

Solution 3 – DFD

Solution 4 – Decision tables

Full decision table

Reduced table