You are on page 1of 47

file:///F|/Courses/2010-11/CGA/MS2/06course/m04intro.

htm

Module 4: Systems analysis and design


Overview
In Module 3 you were introduced to the process(es) by which systems are acquired in organizations. You learned about the
challenges of managing IS projects, the different approaches to acquiring systems, and the factors that tend to result in
successful systems projects.
Module 4 covers the more technical aspects of systems analysis and design. You may think that as a non-IS professional or
manager you will not have to deal with this level of technical detail. But regardless of your role in an organization, you are
likely to participate in these activities as an eventual user of the system. You will also play a role in managing IS projects and
evaluating the performance of developers. To do this effectively, you will need to understand the kinds of considerations that
face the IS project team.
Therefore, Module 4 looks at the detailed activities involved in developing systems. Most of the examples focus on situations
where systems are developed in-house (rather than bought) with occasional references to the situation of purchasing
systems. Nonetheless, it is important to remember that these techniques are equally applicable, at least to some degree, for
purchased systems.
This module will help you develop the following professional competencies:

Advise on the design, development, and implementation of IT projects.


Collect, select, verify, and evaluate information relevant to the defined problem, in this case, gathering user
requirements.

Aggregate information from various sources to obtain the "big picture."

Identify the organizations IT needs to meet financial data processing, control, and reporting requirements.

Use technological tools in the workplace.

Apply professional ethical standards.

Protect the public interest.

4.1 Analysis and design overview


4.2 Systems analysis: Requirements gathering
4.3 Process modelling
4.4 Data modelling
4.5 Logic modelling
4.6 Use case analysis
4.7 Systems design
4.8 Systems analysis and design in smaller organizations
4.9 Ethical issues in systems development
Module Summary
file:///F|/Courses/2010-11/CGA/MS2/06course/m04intro.htm (1 of 2) [20/08/2010 11:05:40 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04intro.htm

Print this module

file:///F|/Courses/2010-11/CGA/MS2/06course/m04intro.htm (2 of 2) [20/08/2010 11:05:40 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t01.htm

4.1 Analysis and design overview


Learning objectives

Distinguish between logical and physical models. (Level 1)


Elaborate on the steps in developing a system in particular the phases of analysis and design (Level 1)

Required reading

Review Chapter 9, Section 9.2, Overview of Systems Development

LEVEL 1

There are two phases in developing systems: the systems analysis phase and the design phase.

Systems analysis phase


The systems analysis phase of the SDLC is concerned with identifying a systems functional requirements in other words,
what it should do. In systems analysis, you focus on identifying what data and information are required in the system and
what processes the system must support. This process focuses on analyzing the needs of the system.
Three sub-phases make up the analysis phase:
1. Requirements gathering (Topic 4.2)
2. Requirements structuring (Topics 4.3, 4.4, 4.5, and 4.6)
3. Generation and selection of alternative design strategies (Topic 4.7)

Design phase
In the design phase, you focus on how the system will meet its functional requirements. With any system, there are different
ways to fulfill the requirements.
Consider, for example, a system to do project planning. Such a system would need to provide tools for developing Gantt
charts, preparing and monitoring budgets, and allocating work to different participants. You can build such a system using
tools embedded in MS Office (Excel for budgeting and Gantt charts, Outlook for allocating tasks, Word for maintaining project
documentation, and so on). Or you can build it using custom-developed tools for each aspect. You can build it for use by a
single person (the project manager) or by multiple members of the project team. You can build it to be accessed from a
website, a PC, a terminal, or even a cell phone or personal digital assistant (PDA).
As you can see, there are many different designs that can fulfill information needs. Deciding on the best design and design
strategy is the goal of the system design phase. The design strategy includes various activities, such as file and database
design, program design, network design, and user interface design.

Overview of modelling
Modelling plays a significant role in systems analysis and design. System modelling can be used to study the existing system,
document business requirements, and detail design of a new system. In this module, three types of system models are
covered: process models, data models, and logic models. However, two important concepts apply to all of them: logical and
physical models.

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t01.htm (1 of 2) [20/08/2010 11:05:41 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t01.htm

Logical models

Logical models (not to be confused with logic models described later in this module) are used to visually document the logical
requirements of a proposed system. They contain no reference to physical implementation details. They show the "what" of
the system independent of technical details. Logical models are mainly used to document the business requirements of a
proposed new system.
Physical models

Physical models are used to document the current system, including all implementation-specific information. They reflect the
physical components of the system, the choice of technology, and its limitations. They show both the "what" and "how" of an
information system, and include all the technical details. Physical models can help you understand the existing system in the
study phase. They can also be used to visually present the approved design for a new system at the selection phase of
systems development.

Modelling in analysis and design


In systems analysis, you focus on the logical models that help analyze business requirements for the following reasons:

They remove biases resulting from the existing implementation of the current system and help to encourage creativity.
They reduce the risk of missing business requirements by better analyzing the requirement for completeness,
accuracy, and consistency.

They reduce the risk of being preoccupied with technical details.

They can be used as non-technical communication.

Physical models are more commonly used in the systems design phase for communication among technical staff as the
details of the system are finalized. They are not a significant focus of this course.

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t01.htm (2 of 2) [20/08/2010 11:05:41 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t02.htm

4.2 Systems analysis: Requirements gathering


Learning objectives

Plan the requirements-gathering phase of systems analysis. (Level 1)


Assess situational factors and choose between the different approaches to requirements gathering. (Level 1)

No required reading
LEVEL 1

A system is only as good as its requirements statement. The cost of fixing errors increases dramatically the further you get
into the systems development process. Getting the requirements right the first time is critical to the successful management
of IS projects.
The systems analysis phase requires fairly extensive interaction with users and other organizational stakeholders because it is
only by talking to those who need the system that its functions and operations can be determined. The involvement of
various stakeholders is also important to building support for the new system. This change management aspect of systems
development will be addressed in Module 10.

Information required What do we need to know?


The first step in building any system is to determine its functional requirements that is, what does it have to do? This step
focuses on three kinds of information:

Information about processes: What are the things that the system has to do? For example, a customer information
system has to allow for creating new customer records, updating existing records, checking customer credit
references, recording new orders, looking up old orders, and so on. These things are all part of the component
processes that make up the system.
Data and information used and produced by the system: What are the inputs to the system, and where do they come
from? What reports are produced by the system, and what data do they contain?
Policies or rules embedded in the system: These policies describe the logic of how decisions are made in the system.
For example, what are the criteria for assigning an "A" credit rating? How does the system determine tax owing on a
retail purchase? Each of these decisions requires the implementation of a set of rules.

Steps in determining requirements


As you can see, a great deal of information is required before a new system can be constructed or a decision can be made
about whether to purchase a new system. Traditionally, determining the requirements for a new system requires several
steps:
1. Documenting the current system (its processes, data, and logic)
2. Analyzing problems with the current system and/or opportunities for improvement
3. Establishing objectives for the new system and constraints
4. Documenting the proposed new system to achieve the objectives outlined
1. Documenting the current system

Various modelling techniques are used to document the current system. Use case diagrams, data flow diagrams, entity
relationship diagrams, structured English, and decision tables and trees are all useful modelling techniques in this phase.
They will be covered in more detail in Topics 4.3 to 4.6.

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t02.htm (1 of 3) [20/08/2010 11:05:41 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t02.htm

2. Analyzing problems and opportunities

While studying the current system, you should identify problem areas and opportunities for further analysis. A tool to help
identify problem areas is the PIECES framework. PIECES is an acronym that identifies six areas in which problems might be
found:

Performance This refers to technical performance such as throughput and response time.
Information This includes problems with what data are collected or not collected and how they are stored, as well
as the information outputs of the system and whether they provide the needed support to the organization.
Economics The costs of supporting the system may be too high or there may be opportunities to generate new
revenue through a different approach.
Control Inadequate controls for data integrity, security, and privacy are critical problems for the organization and
can require changes to systems.
Efficiency This relates to the efficiency of human processes (for example, the number of steps to complete a task)
and the efficient use of organizational resources (such as supplies).
Service This may include problems of consistency and reliability, ease of use, flexibility, compatibility, and
integration with other systems.

3. Establishing system improvement objectives and constraints

Based on the information gathered from the current system and the result of analyzing the current systems problems, you
are then able to identify a set of objectives for the new system. Objectives and constraints for the new system must be
established and agreed to by users and management. Clear objectives and constraints can avoid any misunderstandings and
ambiguities.
4. Documenting of proposed new system

Finally, you are prepared to document the requirements of the proposed system. Based on the problems and opportunities
identified and the objectives agreed on, the formal requirements of the system can be documented. The same modelling
tools and techniques that were used to document the current system can be used here. Prototypes may also be used in this
activity as a way of clarifying system requirements.

Methods of data collection


To get the most useful information about the requirements of the new system, a variety of data gathering techniques are
used. Relying on a single method tends to produce limited information because each method of gathering data will tend to
miss certain aspects of how a system functions.
Interviews

Interviews are an essential part of the requirements-gathering process. Interviewing the people who will be using the system
directly, as well as the people who use the outputs of the system and those who provide the inputs, helps the analyst to
determine what data the system needs, what information it provides, and how it must operate to turn the data into
information.
However, interviews are difficult to do well. Analysts are often frustrated at the inability of users to articulate their needs.
When asked "What information do you need to do your job?" many users are unable to answer clearly. They miss things,
they suggest things they dont need, and they struggle to come up with things. Yet this is one of the fundamental questions
that must be answered.
The problem is with the questioning style. It is much easier to get useful information by asking more indirect questions, such
as: "Tell me about how you do your job." By following up on the activities that users engage in and asking for more detail,
such as "How do you do that?" "Where do you get the information you need to make that decision?" and "Are there any
problems you have with how you do that now?" the analyst can answer the overall question much more completely and
effectively.

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t02.htm (2 of 3) [20/08/2010 11:05:41 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t02.htm

Questionnaires

Questionnaires are useful for gathering structured information from a wide range of stakeholders. Because interviews are
time intensive, and thus costly to conduct, we tend to do fewer of them, which can result in a biased picture of a systems
priorities. Questionnaires make it possible to involve a much wider group of people and get a more representative perspective
of the system.
The downside of questionnaires is that it is difficult to follow up on responses, so the depth of information is lower.
Observation

Observation of users engaged in their work tasks is an important supplement to interviews and questionnaires. Often, when
asked to explain parts of their jobs, even with good questioning, users miss things. Some of our daily activities are so
automatic that we no longer even think of them, and then forget to talk about them. Others are rare occurrences that we
dont think to explain. Watching users as they walk through their tasks is a good way to pick up on these unstated tasks. For
tasks that occur rarely, you may have to observe for a long time before they come up, making this approach better for
dealing with information that people just forget to mention.
Document review

Document review involves looking at screens and forms produced by the current system, reports that are used by various
stakeholders, project documentation from previous systems (if it exists), and letters and memos that document problems.
These provide a further perspective on the system and are an important supplement to the other methods.
Looking at forms and reports to see how they are used and what information they contain is particularly helpful in
documenting the data needs of the system.
Prototyping

Prototyping, covered in Module 3 as an approach to developing systems, can be used in a more limited way as part of the
requirements-gathering phase. When users find it difficult to clearly explain what a system needs to do (especially for a
system that is less well-understood in the organization), building small prototypes of different aspects is a helpful way of
opening a dialogue about their needs.
By building a prototype that can be tested by the users, analysts can make it easier to recognize the pieces that are missing
from the requirements or identify opportunities for additional functionality that may not have been considered.
Joint application development

Joint application development (JAD) is a formal method of doing requirements analysis in which teams of people both
users and developers go to an off-site location for a series of intense meetings. Teams usually consist of 8 to 10 people. A
professional facilitator guides the discussion as the team works through the specification of requirements.
Bringing the team together as a group is helpful, as people can build off each others ideas to more quickly state the
requirements of the new system. JAD sessions often use extensive computer support, in the form of modelling tools, to
document the system requirements. This can greatly speed up the process of systems analysis.

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t02.htm (3 of 3) [20/08/2010 11:05:41 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t03.htm

4.3 Process modelling


Learning objectives

Explain process modelling. (Level 1)


Draw a simple data flow diagram (DFD). (Level 1)

No required reading
LEVEL 1

Process models are used to document the activities (or processes) that take place within a system and show how a system
fits together by linking the activities with the movement of data throughout. Process models are the first element in the
requirements-structuring process. You can draw process models in many ways. One of the most common ways of
documenting processes is using data flow diagrams (DFDs). DFDs show the main processing steps in a system, the data
flows that link the processes, the data stores where data are kept between processes, and the external entities to the system.
The important thing to remember when drawing DFDs that are intended to represent the current system is that you are
trying to create a model of reality. Analysts can get into trouble in developing systems by assuming they know how the
system should work. In drawing DFDs, you need to frequently check with users to ensure that the representation is correct
and complete.
Example 4.3-1: Automobile insurance system

This example is a partial description of a system for automobile insurance from the perspective of the insurance agent. It is
not meant to describe every activity involved in the system, but rather to show how a DFD can be used to graphically
represent a textual description of a system.
The automotive insurance system is intended to provide insurance to car owners through an insurance agency. Customers
who want to apply for insurance are required to fill out an insurance application request. A number of activities are involved
in processing this application. First, a drivers record request is sent to the local police department, which sends back a
drivers record report. Also, a vehicle registration request is sent to the Ministry of Transportation, which supplies a vehicle
registration. Policy contracts are sent in by various insurance companies. The agent determines the best policy for the type
and level of coverage desired and gives the customer a copy of the insurance policy along with an insurance coverage card.
The customer information is now stored. Periodically, a fee statement is generated and policy changes are sent to the
customer, who responds by sending in a payment with the fee stub.
Exhibit 4.3-1 shows a data flow diagram for this system.
Exhibit 4.3-1:

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t03.htm (1 of 4) [20/08/2010 11:05:42 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t03.htm

Four external entities are shown in the system, represented by rectangles. Customers provide information to the system in
the form of application requests and fee stubs (along with fees). They receive information from the system in the form of the
insurance policy and fee statements. The police department, the Ministry of Transportation, and the insurance companies are
also external entities in this system.
The system completes four main processes. They are the numbered ovals in the diagram. The first process (1.0 Receive
Application & Request Documents) indicates where applications are received and where documents to evaluate the
application are requested. The second (2.0 Agent Chooses Best Policy) indicates where the compiled information is used to
determine the best policy and issue it to the customer. The third and fourth processes deal with the periodic distribution of
invoices (3.0 Generate Fee Statement) and the receipt of fees from customers (4.0 Receive Payment).

Data stores
Data stores represent the places where data are kept between processing. Often these are computerized databases, but they
could be paper files in a filing cabinet or stored on an employees desk awaiting further processing. Data stores are shown in
Exhibit 4.3-1 as open-ended rectangles.

Data flows
Data flows are shown with arrows connecting the two processes. DFDs show the flows of data/information, rather than
physical items. You can see in Exhibit 4.3-1 that the actual payment is not shown as a data flow into process 4.0. Rather, the
accompanying fee stub is shown as the data flow.
In Exhibit 4.3-1, data flows can connect processes to each other, to external entities, and to data stores. Data flows must
either start or end with a process. For example, you cannot show a data flow directly from a customer to a data store. If you
think about this, it makes sense. In order for the application request to get into a pending applications file, some processing
has to take place. The processing may be done by a person or by a computer, but the data doesnt just magically appear in a
database or in a filing cabinet. The activities that get the data from the customer to the data store are described in the
file:///F|/Courses/2010-11/CGA/MS2/06course/m04t03.htm (2 of 4) [20/08/2010 11:05:42 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t03.htm

processes.
Similarly, data cannot flow directly from one external entity to another. On occasions where customers communicate directly
with the Ministry of Transportation (for example, in renewing their drivers licenses), these flows of information are considered
outside the scope of the system and are not depicted in the DFD.
Activity 4.3-1: Identifying inferred data flows

You should be able to find specific statements in the system description in Example 4.3-1 for all but four of the data flows
shown in Exhibit 4.3-1. Which data flows are inferred from the description rather than being explicitly stated?
Solution

Sets of data flow diagrams


DFDs are drawn in sets. To minimize the amount of information presented in any one diagram, a hierarchical set of DFDs is
constructed to show increasing levels of detail. The highest level diagram is called the context diagram. It consists of a
single process, carrying the system name, linked by data flows to the systems external entities. No data stores are shown in
this diagram, and the only data flows shown are the ones that connect the system to its environment.

Purpose of the context diagram


The main purpose of the context diagram is to communicate the scope and boundaries of the system. By showing the inputs
into the system from external entities and the outputs from the system back to those entities, you can infer what activities
must take place inside the system to produce those outputs from the given inputs.
Activity 4.3-2: Drawing a context diagram

Try drawing the context diagram for the automotive insurance system described in Exhibit 4.3-1. Remember to start with a
single process bearing the name of the system. Then add in the external entities and the data flows that link them to the
system.
Solution

What the context diagram shows


The context diagram shows the scope and boundaries of the system. The DFD in Exhibit 4.3-1 is presented as a level 0
diagram, which means that it shows the overall function of the system. The remaining DFDs that would be drawn would
show more detail about each of the processes.
In the automobile insurance application, for example, you would draw a separate diagram for each of the level 0 processes,
showing how the processes are subdivided or decomposed. Agent Chooses Best Policy might include sub-functions such as
determine driver rating, determine vehicle cost, and find lowest cost policy.
The level 1 diagram would show how these sub-processes fit together within that single process called Agent Chooses Best
Policy. Each level 1 diagram might be further decomposed into level 2 diagrams, some of which would be even further
decomposed. The process ends when the lowest level diagrams are considered to contain primitive processes processes
that cant reasonably be broken down further. Deciding what is a primitive process is largely a matter of judgment on the
part of the analyst.
The purpose of this topic is not to make you a proficient systems analyst but to give you a managerial overview of the work
of analysts. You need to focus only on the two highest levels (context diagram and level 0 diagram) of data flow diagrams.
The mechanics of decomposition are beyond the scope of this module.

Rules for drawing data flow diagrams


A number of rules or conventions are used in drawing data flow diagrams, some of which have been covered in this module
already. Exhibit 4.3-2 summarizes the rules for data flow diagrams.
file:///F|/Courses/2010-11/CGA/MS2/06course/m04t03.htm (3 of 4) [20/08/2010 11:05:42 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t03.htm

Exhibit 4.3-2: Data flow diagram rules

Symbols
External entity

Closed rectangle

Process

Oval or rounded rectangle

Data store

Open-ended rectangle

Data flow

Arrow

Naming conventions
External entity

Noun (for example, Customer, Supplier)

Process

Verb (for example, Receive Application, Determine Rate), except in


the context diagram where the system name a noun is used

Data store

Noun (for example, Customer Listing, Back-ordered Product)

Data flow

Noun (for example, Application Request)

Rules
Process

Every process must have at least one input and one output.

Data flow

Every data flow must be connected to at least one process.


Every flow must be in a single direction (no double-headed arrows).

The distinction between logical and physical data flow diagrams can be seen in the way elements are named. In a logical
DFD, the names refer to what the element does only. In a physical DFD, the names refer to the current implementation of
that element (the how).
For example, the data flow Application Request could be considered a logical flow because it doesnt tell you how the request
is received. Application Request Form, on the other hand, would be a physical data flow because it refers to the fact that the
request is made on a particular form. For data stores, the distinction between logical and physical versions would involve
noting the current storage location or method in the name. Therefore, Customer Database in MS Access is a physical data
store because it provides current implementation details.
You only need to know the difference between physical and logical flows in order to see why particular names are used or
not used in diagrams. Your role as a manager is more likely to be in reading a DFD than in creating one. The fine points of
naming and some of the more subtle rules are beyond the scope of this module.

Steps in drawing data flow diagrams


The process by which DFDs are constructed is iterative, and there is no right way to proceed. It is easier, though, to follow
some fairly simple steps in constructing at least the first version.
1. Identify the external entities involved in the system. These are often the easiest to identify because they represent
known people or organizations with whom you share information.
2. Identify the scheduled inputs and outputs for the system, the inquiries, and on-demand requests. Scheduled outputs
often take the form of reports, the names and nature of which would have been collected during the requirementsgathering process. On-demand requests in Exhibit 4.3-1 would include things like new customer requests for
insurance.
3. Identify the data stores (files, databases, lists) and the points at which waiting occurs in the system.
4. Identify the main activities or processes the system has to undertake. Group these together to form about three to
seven main processes for the level 0 diagram.
5. Draw a first version of the context diagram and level 0 diagram. Compare these against the documentation from
requirements gathering to determine completeness, and then revise them as needed.
6. After the diagrams are deemed reasonably complete, confirm them with other analysts and users to ensure they are
correct. A walkthrough is often used to assess the accuracy of DFDs. This requires tracing the flow of data through
the system and ensuring that what has been drawn matches the actual flow. You need to communicate with users to
clarify points from the requirements gathering.
file:///F|/Courses/2010-11/CGA/MS2/06course/m04t03.htm (4 of 4) [20/08/2010 11:05:42 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t03sol1.htm

Activity 4.3-1 solution


The four data flows not directly in the description are

Open Application data flow, linking process 1.0 to the data store Pending Applications

Application with Completed Documentation data flow, linking the Pending Applications data store to process 2.0

Current Policy data flow, linking the Current Policies data store to process 3.0

Policy Update data flow, linking process 4.0 to the Current Policies data store

The first two data flows show that there is (or might be) a period of time from when the two requests are made to the time
when they are received. Were these requests filled instantaneously, the data flow could be shown as directly linking process
1.0 and 2.0.
The second two were added to show how fee statements are generated for customers and how records are updated on
receipt of those fees. Without adding these data flows, the two processes would be incomplete. Such errors are common in
data flow diagrams, and show the need for care in determining requirements.
For process 3.0, without adding the Current Policy data flow, it would appear as though fee statements were generated with
no information about customers or their policies. This error is referred to as a miracle in data flow diagrams, where data
flows out of, but not into a process.
For process 4.0, without adding the Policy Update data flow, it would appear that once fee stubs are received, they are
simply discarded (or worse, disappear). This error is referred to as a black hole in data flow diagrams, where data flows
into, but not out of a process. A third error, a grey hole, exists when there are at least some data flows into a process, but
they are not sufficient to produce the outputs of the process.

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t03sol1.htm [20/08/2010 11:05:43 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t03sol2.htm

Activity 4.3-2 solution

Notice that none of the data stores are present in this diagram. All of the data flows that lead to or come from external
entities are shown, but none of the others are represented. The process is shown with the system name at the core of the
system, and contains all of the other elements (data stores, processes, internal data flows).

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t03sol2.htm [20/08/2010 11:05:43 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t04.htm

4.4 Data modelling


Learning objectives

Interpret the way entity relationship (ER) diagrams can be used in data modelling. (Level 1)
Draw a simple entity relationship diagram. (Level 1)

Required reading

Review Chapter 6, Section 6.2, The Database Approach to Data Management (subsection on "Designing Databases")

LEVEL 1

In previous courses, you learned about databases. The text reading for this topic reviews the concepts of databases and their
structure. The first element of the requirements-structuring process is process modelling (Topic 4.3). The second element,
data modelling, is concerned with documenting the conceptual data model that underlies the system. A conceptual data
model describes what data are recorded by the system and how the data are related. The most common tool used for data
modelling is the entity relationship (ER) diagram.
Data models, such as ER diagrams, complement DFDs by detailing the things the system stores data about (the entities, their
attributes, and their relationships to each other).
Understanding the two sets of models together, and determining the extent to which they are consistent, is as important to
requirements structuring as the construction of each specific model.

What the ER diagram shows


Any system requires information about a variety of entities such as customers, orders, products, and suppliers. ER diagrams
show the people, places, things, or events about which you want to record data (the entities) and then describe how these
entities relate to one another.
Activity 4.4-1: Determining entities in an educational context

What would be the entities involved in an educational context? Think about the sorts of things you would want to record
information about. What relationships would you be interested in?
Solution
How ER diagrams can be implemented

ER diagrams are logical data models in that they are not tied to any specific implementation of the database. The same ER
diagram could ultimately be implemented using a hierarchical, network, relational, or object-oriented database. It could also
be implemented using flat files. An ER diagram, as with all logical models, describes the "what" rather than the "how" of the
data in your system.
Components of an ER diagram

Exhibit 4.4-1 shows an ER diagram describing how parts are ordered from suppliers. This is similar to the diagram used in the
textbook, but it adopts a more formal notation for ER diagrams.
Exhibit 4.4-1:

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t04.htm (1 of 3) [20/08/2010 11:05:44 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t04.htm

Relevant attributes

The middle of the ER diagram shows that the firm wants to record data about the PARTs it uses. For each part, it is
important to store a Part_Number (for example, 472J), Part_Description (for example, widget), and Unit_Price (either the
purchase price or the selling price, though the latter is more likely). There might well be other attributes of PART that would
need to be recorded (for example, colour and size). You would determine the required attributes during requirements
gathering. Looking at existing reports and forms is particularly helpful in identifying relevant attributes.
Parts are ordered from SUPPLIERs, a second entity. For each supplier, the firm stores an identification number
(Supplier_Number), name (Supplier_Name), and an address (Supplier_Address). Again, although there may be other relevant
attributes, these are the ones that have been identified.
Relationship between entities

The diamond shape and the connecting lines that link PARTs to SUPPLIERs describe the relationship between these two
entities. The diamond describes the nature of the relationship. Relationships are read in sentence format. Each PART can
have a SUPPLIER. Notice that the sentence description talks about each part and its relationship to individual suppliers, not
parts and suppliers in general. The actual number of instances (examples of individual parts or suppliers) of one entity that
relate to the other are described in the 1s and Ms that appear on the lines linking the entities together.
In the diagram, each PART can be ordered from (can "have") one and only one SUPPLIER (there is a 1 at the end of the
connection closest to SUPPLIER). Each SUPPLIER, on the other hand, can supply more than one PART. The term for this in
ER diagrams is "many," and it is represented by the M at the PART end of the connection. The relationship between the
entities SUPPLIER and PART is one-to-many.
This particular rule about parts and suppliers is not the case with all businesses. In many businesses, each part would be
obtained from multiple suppliers as a way of managing risk. However, according to this diagram, the rule in this business is
that each part comes from one and only one supplier. Determining the nature of these relationships is part of the purpose of
requirements gathering.
The diagram also shows that PARTs can have ORDERs (or ORDERs can have PARTs). Here the relationship is modeled as
many to many. Each ORDER can be for one or more PARTs, and each PART can be included on one or more ORDERs.
The relationship between PART and ORDER is a special type. This relationship is shown as a diamond within a square,
indicating that it is a relationship that has attributes you want to capture; it is technically called an associative entity.
Part_Amount refers to the quantity of a particular part that is ordered on a particular order. It is not really an attribute of just
the ORDER or just the PART. Therefore, it shows up in the middle.
file:///F|/Courses/2010-11/CGA/MS2/06course/m04t04.htm (2 of 3) [20/08/2010 11:05:44 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t04.htm

As you can see, ER diagrams are complex. They contain a lot of information, and there are some specific rules about how
they should be drawn. As a manager, you most likely do not have to draw many ER diagrams. But it will be important for you
to work with IS staff to be able to read them and determine whether they correctly describe the data in your system.

Creating ER diagrams
ER diagrams, like DFDs, are drawn iteratively. Typically, you begin with a description of the system derived from the
requirements-gathering phase. For example, a user describes some aspect of how the system works or a report shows what
a customer order looks like. These descriptions or implied descriptions are used to determine the main entities in the system.
The attributes of these entities are noted from the various inputs and outputs of the system (some of these will come from
DFDs).
Relationships are determined by analyzing business rules (for example, each part comes from one and only one supplier) that
are either stated formally or, more often than not, are implied in how current processes operate. Implied rules are
dangerous, because if you are creating a new system you may not want to be bound by old rules. This is especially true
when the goal of the system is to reengineer existing processes.
As with DFDs, walkthroughs with other analysts and with users are important to ensure that the model accurately captures
the reality of the situation.
Example 4.4-1 describes the main entities for a video store and has an accompanying ER diagram.
Example 4.4-1: Video store ER diagram

In a video store, customers rent DVDs. DVDs record specific movies that customers want to see. If you go to your local video
a new release on the shelf. If one is
store, you might see multiple copies of Super Hit III
in stock, you can rent it for a set price and for a predetermined period of time.
Suppose you were trying to create an information system to track rentals. What would be the entities you would have to
include in your system? What are the likely attributes (based on your experience) for these entities? How do they relate?
What would the ER diagram showing this data look like?
Solution and commentary
Because each data model represents specific rules that may differ across companies, there is no such thing as a single
correct solution to an ER problem. The quality of an ER diagram is reflected in the degree to which it conforms to the rules of
drawing ER diagrams (symbols, conventions, and so on) and the degree to which it accurately conveys the reality that it was
designed to model. This is frustrating when youre learning about ER diagrams, because there is a tendency to want "right
answers." But it also points out one of the reasons why systems so often fail.
If the requirements can be modeled in different ways and these differences have implications for what the system will
ultimately be able to do, then these differences in how analysts understand a system at an early stage can have a direct
bearing on the ability of the system to fill specific needs. If the needs are not articulated clearly by users or understood by
analysts, the design may not support these needs.

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t04.htm (3 of 3) [20/08/2010 11:05:44 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t04sol1.htm

Activity 4.4-1 solution


Entities in an educational context would include students, courses, instructors, sections (or, specific offerings of a particular
course in particular year), programs (which are made up of courses) and so on.
Relationships are the other key component of an ER diagram. They show the ways in which the entities interact. So, for
orders, or customers buy
products.
example, customers place

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t04sol1.htm [20/08/2010 11:05:44 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t04sol2.htm

Example 4.4-1 solution and commentary


There are three main entities described: CUSTOMER, MOVIE, and DVD. The distinction between MOVIE and DVD is a
somewhat subtle one. But as you look at the attributes, you will see why it is important to separate them. Some additional
entities come up as you work through the logic of the system.
For the CUSTOMER entity, the system should store attributes such as name, address, phone number, and age (to determine
if a customer can rent restricted movies). An ID number would likely be assigned by the video store for easier tracking of
customers, and a credit card number might be recorded to deal with late charges or lost DVDs. A customer type (such as
preferred and family) might also be recorded.
There are probably other attributes. The important thing to consider when deciding if they are appropriate is whether they
describe this specific entity (a customer) and whether they are necessary for some aspect of the processing that the system
will do. The necessity of an attribute can be determined from DFDs. Each DFD shows the data entered into various processes
in the system. Every data flow on the DFD must somehow be represented in the ER diagram. Attribute necessity would also
be supported by logic models (see the next topic). Part of the process of requirements structuring is establishing the
consistency between different types of models.
For the MOVIE entity, the system would likely store attributes such as title and genre (horror, action, and so on). Other
details, such as director and actor, might be considered as attributes of the entity MOVIE, or they might be considered as
entities in their own right. This would be beneficial for providing help to customers. Suppose a customer comes in and wants
to see a movie by a particular actor. If the database is set up with ACTOR as an entity, then it would be easy to search for all
the movies in which a specific actor appears. A small video store might not have the need for this kind of sophistication, but a
larger operation would want to provide this service. The Internet Movie Database (www.imdb.com) is one example of a
sophisticated system that links people (actors, directors, writers) with roles in movies or TV shows. You can engage in very
powerful querying of this database to find characters, obscure roles, release dates of new movies, and so on.
The DVD entity represents a specific copy of a movie. This is of less interest to customers than the MOVIE entity. Customers
typically care about the attributes of MOVIE. But when it comes to managing the inventory of the business, the DVD entity is
important. Its attributes would likely include things such as inventory tag number, date purchased, and perhaps shelf location.
In addition to CUSTOMER, MOVIE, and DVD, it is important to have an entity called MOVIE TYPE (or something similar). The
rental period and rental price of movies is determined not by the MOVIE itself but by the category of the movie within the
, for example, is a new release, which means it has a one- or two-day rental
store. Super Hit III
period and a higher rental price than a movie that has been available for many months or years. For the MOVIE_TYPE, it
would be important to capture a description of the type (new release, kids' movie, older new release, and standard, assuming
each of these types had different rental periods and/or prices), the rental period, and the rental price.
This entity is important when you consider the process of setting rates. Suppose the business decides, a year after the
system is created, to change the rental period for new releases from one day to two days. If rental period is stored as an
attribute of MOVIE_TYPE, it will be easy to update the system with only one change that would need to be made. But if
rental period is stored as an attribute of MOVIE (or DVD), a change will have to be made to each and every MOVIE (or DVD)
record in the database. This is a much more time consuming process.
The final ER diagram would look something like Exhibit 4.4-2.
Exhibit 4.4-2:

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t04sol2.htm (1 of 2) [20/08/2010 11:05:44 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t04sol2.htm

Exhibit 4.4-2 shows a slightly different way of writing the relationships than the earlier example. There are two wordings for
each relationship to facilitate reading the relationship in both directions. The relationship between customer and DVD is
shown as "is rented by/rents." This means that a DVD "is rented by" a CUSTOMER or that a CUSTOMER "rents" a DVD. Either
approach is acceptable.

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t04sol2.htm (2 of 2) [20/08/2010 11:05:44 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t05.htm

4.5 Logic modelling


Learning objectives

Represent processing flow using Structured English. (Level 2)


Construct decision tables to document the processing logic of a set of procedures. (Level 2)

No required reading
LEVEL 2

Logic modelling is the final component of the requirements-structuring process. Logic models are used in combination with
process models and data models to describe the elements of a system.
The main function of logic models is to provide further documentation of the process activities shown in the data flow
diagrams. They are a way of breaking open the "black box" that is a process in a DFD. Logic models focus on describing two
aspects of the processes:

data-to-information transformations (the steps in a process) Structured English is a common tool used to describe
data-to-information transformations.
decisions (the logic behind how certain processing decisions are made) Decision tables are a tool used to describe
the decision logic.

Structured English
Structured English is a tool that describes data-to-information transformations in a more systematic way than using natural
English. It resembles a programming language in that it is more restrictive than natural English, but the similarities end there.
Structured English is based on three basic constructs: sequence, decision, and repetition. A combination of these constructs
is used, depending on the procedures being described.
Sequence construct

The sequence construct is simply putting precise, descriptive instruction statements together, one following another.
For example, the following sequence calculates the price, taxes (GST and PST at 5% and 8% respectively), and total amount:
Calculate TOTAL_AMT using the formulas
PRICE = UNIT_COST 1.5
GST = PRICE 0.05
PST = PRICE 0.08
TOTAL_AMT = PRICE + GST + PST
The name chosen to represent each variable is not important. For example, the GST and PST could just as easily be called
TAX1 and TAX2. What is important is that the variable name is used consistently throughout the model to refer to the same
element and the logical relationships between variables are accurate. Also, other terms such as "Derive" or "Compute" could
be used instead of the term "Calculate," based on preference. You should not use terms that would potentially confuse other
people who will be looking at the model.
Decision construct

The decision construct, also known as the selection construct, permits these two formats to specify branches to the sequence
of instructions:

if-then-else format

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t05.htm (1 of 6) [20/08/2010 11:05:45 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t05.htm

case format

If-then-else format
The if-then-else construct is the most common. It provides a binary selection. For example, the following decision construct
calculates the selling price for two types of merchandise. If the item is of the type coded 100, the selling price is 1.5 times
the cost. If the item is a type other than 100, the selling price is 2 times the cost:
If ITEM_TYPE = 100
then,
Calculate PRICE using the formula
PRICE = UNIT_COST 1.5
else,
Calculate PRICE using the formula
PRICE = UNIT_COST 2.0
Note that it is possible to have a sequence construct embedded in a decision construct. For example, here is a calculation of
the total amount for an item coded 100 (with a markup of 1.5 and subject to GST and PST) and for an item with a type code
other than 100 (with a markup of 2 and not subject to GST).
If ITEM_TYPE = 100
then,
Calculate TOTAL_AMT using the following formulas:
PRICE = UNIT_COST 1.5
GST = PRICE 0.05
PST = PRICE 0.08
TOTAL_AMT = PRICE + GST + PST
else,
Calculate TOTAL_AMT using the following formulas:
PRICE = UNIT_COST 2.0
PST = PRICE 0.08
TOTAL_AMT = PRICE + PST

Case construct
The case construct is used to handle situations where there are three or more choices. For example, in the following
situation, the products are priced differently depending on the type code.
Select the appropriate case:
Case 1: TYPE = 100
Calculate PRICE using the formula
PRICE = UNIT_COST 1.5
Case 2: TYPE = 200
Calculate PRICE using the formula
PRICE = UNIT_COST 1.75
Case 3: TYPE = 300

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t05.htm (2 of 6) [20/08/2010 11:05:45 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t05.htm

Calculate PRICE using the formula


PRICE = UNIT_COST 2.00
Case 4: TYPE = 400
Calculate PRICE using the formula
PRICE = UNIT_COST 2.25
Repetition construct

The repetition construct, also known as the iteration or looping construct, has two variations:

do-while construct
repeat-until construct

Do-while construct
The do-while construct follows a set of instructions if a condition is true. This is a zero-or-more construct. The instructions
may not be executed at all if the condition is not true when first tested.
This example calculates the sick leave costs for department 10:
While DEPARTMENT = 10, do the following steps:
For each employee, calculate SICK_LEAVE_COST
using the following formula:
SICK_LEAVE_COST = SICK_LEAVE_HOURS PAY_RATE
This example calculates income assistance for persons with taxable income of less than $10,000 by topping up income to
$10,000 and providing a rental aid of $250:
For each person with INCOME < 10,000,
calculate TOTAL_ASSISTANCE using the following formulas:
SUPPLEMENT = 10,000 INCOME
RENTAL_AID = 250
TOTAL_ASSISTANCE = SUPPLEMENT + RENTAL AID

Repeat-until construct
The repeat-until construct repeats a set of instructions based on the value of a condition. This is a one or more construct.
The set of actions must execute at least once.
This example calculates the wage expense for employees who are entitled to vacation (8% of wages) and pension benefits
(6% of wages). Employees must submit a timesheet for each pay period:
For each employee timesheet, calculate
WAGES_EXPENSE using the following formulas:
WAGES = HOURS PAY RATE
VACATION = WAGES 0.08
PENSION = WAGES 0.06
WAGES_EXPENSE = WAGES + VACATION + PENSION
Report WAGES_EXPENSE
until all timesheets have been processed.

Decision tables
file:///F|/Courses/2010-11/CGA/MS2/06course/m04t05.htm (3 of 6) [20/08/2010 11:05:45 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t05.htm

While Structured English is used to describe procedures with simple conditions, other processes require complex
combinations of conditions. They are typically found in business policies. While it is still possible to use nested "if-then-else"
statements in Structured English, decision tables are ideal for describing business policies where a set of rules is used to
describe each possible combination of events.
Exhibit 4.5-1: Decision table

Decision tables appear complicated at first, but they are very powerful tools for communicating system logic. A decision table
consists of three parts as shown in Exhibit 4.5-1:

Condition stub a list of all possible factors that affect the decision. Condition stubs are shown in the top half of the
first column of the decision table.
Action stub a list of all the decision processes (for example, outcomes) for the decision table. Action stubs are
shown in the bottom half of the first column of the decision table.
Decision rules actions that are to be taken under a specific combination of decision conditions. Decision rules make
up the columns of the table.

Example 4.5-1 describes the business policies for Knowledgeware Inc. and the decision table created to illustrate it.
Example 4.5-1: Knowledgeware Inc. and the decision table

Knowledgeware Inc. is a training firm that provides information systems training to business and professional end-users.
People can register for training as individuals or can be registered by their companies. The cost for an individual registrant is
$150 per day. However, people who book training for three to five courses at one time get a 10% discount; if they book for
six or more courses (a certificate program), they get a 20% discount.
The corporate rate for training is more than the individual rate ($175/day). Corporate clients also get volume discounts when
they book employees into more than two courses, the same as for individuals. A second type of volume discount, available
only to corporate clients, is the multi-student discount. Corporate clients who book three or more students into the same
course are given a 15% discount.
Exhibit 4.5-2 shows the decision table to represent the combination of conditions. Note that the table is not in its simplest
form. This issue will be addressed in step 7 in "Basic steps for building a decision table."
Exhibit 4.5-2: Decision table for Knowledgeware Inc. training costs

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t05.htm (4 of 6) [20/08/2010 11:05:45 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t05.htm

The above exhibit shows the full, exhaustive table which considers every possible combination. In this case, student
enrolment will always be "1" for individual clients, so columns 7, 9, and 11 will be gone in the final, simplified table.
Condition stub

Condition stubs are "tests" of possible conditions. In Exhibit 4.5-2, the condition stubs are type of client (individual or
corporate), course enrolment (number of courses being booked at one time provides some level of discount), and student
enrolment (companies that book for many students also get a discount).
Action stub

In Exhibit 4.5-2, there are two different daily rates for training, plus three levels of discounts. The policy determines which
combination of these conditions applies.
Decision rules

In the top half of the table, the different combinations of conditions are detailed. Then the actions are marked in the same
column below with Xs. Column 1 of the table in Exhibit 4.5-2 suggests that for an individual client who books two or fewer
classes at one time and books only for themselves, the daily rate would be $150.
Activity 4.5-1: Decision rule

Refer to Exhibit 4.5-2. What does the rule in column 8 mean? What about column 12?
Solution

Basic steps for building a decision table


Now that you have seen what a decision table looks like, here are the procedures for creating one. Example 4.5-1 and Exhibit
4.5-2 will be used to explain the steps.
1. Identify the conditions and values. In Example 4.5-1, three conditions are described in the policy: type of client
(individual or corporate), number of courses taken by one student (1-2, 3-5, 6+), and number of students taking
each course (1-2, 3+).
2. Identify the possible action stubs for the decision or policy. In Example 4.5-1, the possible actions are

$150 daily rate

$175 daily rate

10% discount

15% discount

20% discount
It would be possible to work out specific rates for each of these outcomes (for example, $150 with a 10% discount =
$135 per day). But the process is actually clearer if the outcomes are shown as rates and discount levels. Moreover,
this is what the programmers will actually work with; leaving the decision table at this level is preferred from a
developers perspective.
3. Determine the maximum number of decision rules by multiplying the number of values for each of the condition stubs
by each other. This calculation yields the number of unique permutations of all the decision conditions. In Example
4.5-1, the maximum number of decision rules is 12 (2 x 3 x 2) that is, type of client has two values, number of
courses has three, and number of students has two. The actual number of decision rules may be less than the
maximum, as will be explained in step 7.
4. Enter all possible decision rules by taking each condition in turn and laying out all its possible values. Each unique
file:///F|/Courses/2010-11/CGA/MS2/06course/m04t05.htm (5 of 6) [20/08/2010 11:05:45 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t05.htm

combination of conditions forms a possible decision rule. For example, there are two types of client (I or C), three
types of course discounts (1-2, 3-5, 6+ students), and two types of student enrolments (1-2, 3+ students).
5. Define the actions for each rule. The possible actions for Knowledgeware are shown by the Xs in the lower half of the
table.
6. Verify that each of the decision rules is correct and not contradictory.
7. Simplify the decision table. The last step in drawing a decision table is to look for opportunities to simplify the table.
If the outcomes do not differ for all of the levels of one of the conditions, that condition can be said to be
"indifferent." In this case, the rules can be collapsed.
In Example 4.5-1, you can see that there is no difference for an individual client who books for more than two students or
less than two students. This makes sense because individuals are, by definition, booking for themselves. Thus, student
enrolment is an indifferent condition for individual customers. Columns 1 and 7 can be collapsed, as can columns 3 and 9,
and 5 and 11. When columns are collapsed like this, a dash () is used to show that the response to the particular condition
stub is not relevant.
Applying these steps to the decision table from Example 4.5-1 would result in the following table.
Exhibit 4.5-3: Decision table in its simplest form

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t05.htm (6 of 6) [20/08/2010 11:05:45 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t05sol.htm

Activity 4.5-1 solution


Column 8 suggests that corporate clients (C) who book one to two courses for three or more students at a time obtain a daily
rate of $175, with a 15% discount.
Column 12 suggests that corporate clients who book three or more students for certificate programs (six or more courses)
obtain the $175 corporate rate, a 20% discount, and an additional 15% discount.

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t05sol.htm [20/08/2010 11:05:45 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t06.htm

4.6 Use case analysis


Learning objective

Design a simple use case to support systems design (Level 2)

Required reading

Review Chapter 9, Section 9.2, (subsection on "Modelling and Designing Systems: Structured and Object-Oriented
Methodologies")

LEVEL 2

The three methods described above were developed as part of the structured analysis method for systems design. Recently,
some organizations have been pursuing an alternative approach the object-oriented approach to systems development.
In object-oriented systems, data and processes are attached to "objects" in the system. Rather than separating and
distinguishing between data and process, object-oriented systems combine the two based upon the event being described.
While the models, techniques, and underlying applications of the object-oriented and structured approaches are quite
different, from a managerial viewpoint, their aims are the same. Both approaches require gathering and structuring
information from users.
The object-oriented approach begins with the specification of important events in the application and documents "use cases"
for each event. These are descriptions of specific activities carried out by users of the system (actors). Use cases are part of
the unified modelling language (UML) that forms the core of object-oriented analysis and design.
Use cases are less formal and less technical than more traditional structured modelling. A use case is basically a narrative of
a business process; it describes a specific event or process that produces an output, and has four basic elements:
1. Basic descriptive information (name, description, number and so on)
2. Trigger (the event or timing that initiates the process)
3. Inputs and outputs (sources and destinations of information)
4. Details (the steps required to complete the process, information needed, and the direction of information flows)
A use case describes the reaction of the system to a specific action or trigger. These triggers can be external (a customer
placing an order) or temporal (the passing of a due date or automatic billing date). The use case describes these events from
the point of view of a single user or role, for example, the check-out clerk at a library. The creation of a use case is iterative
and may include role playing and scenario modelling to produce a complete description. A use case is the intermediate step
between gathering requirements and process and data modelling.
There are a number of ways to represent a use case, including the common text-based method illustrated in Exhibit 4.6-1,
which describes a use case with an external trigger. Here, the procedure for changing an appointment at a dentists office is
described from the point of view of the receptionist. The use case captures only the major steps and information needed to
complete the activity. It does not make any mention of technology or user interface.
Exhibit 4.6-1: Re-scheduling a dentist appointment

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t06.htm (1 of 3) [20/08/2010 11:05:46 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t06.htm

Exhibit 4.6-2 uses a temporal trigger. Again it is not tied to a specific technology or particular way of doing the activity; you
could contact the patient in any number of ways. You are trying to model the basic process and identify the information
required to complete the process.
Exhibit 4.6-2: Appointment reminders

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t06.htm (2 of 3) [20/08/2010 11:05:46 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t06.htm

If you were developing a new patient and appointment system for a dentists office, you would create a use case for every
major activity in that office. You would work closely with the users to establish what those activities are. The key things to
look for are triggers and outputs. Most major activities will have some sort of data transformation.
Activity 4.6-1: Collecting new patient information

Using the use case template, create a use case for collecting new patient information when patients come in for their first
appointment.
Solution

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t06.htm (3 of 3) [20/08/2010 11:05:46 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t06sol.htm

Activity 4.6-1 solution

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t06sol.htm [20/08/2010 11:05:46 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t07.htm

4.7 Systems design


Learning objectives

Analyze the primary decisions and activities in the systems design phase. (Level 2)
Evaluate and discuss user interface in terms of design. (Level 2)

No required reading
LEVEL 2

As youve seen in Topics 4.1 to 4.6, the systems analysis


phase of the SDLC is focused on establishing
the functional requirements of the system, or what the system is supposed to do. The systems design
phase
focuses on translating those requirements into a specific implementation, or how
the system will do what it is
supposed to do.

Design strategy decisions


It is important to note that the development and comparison of alternative design strategies is the final phase of systems
analysis, and must take place before systems design can begin. It is being considered here as part of your study of the
design phase because the decisions relate to the concepts of design. A design strategy includes three main decisions:

system functionality
hardware and software platform
method of acquisition

System functionality

The decision about system functionality focuses on whether to build the minimum acceptable system, the high-end
alternative with all of the "bells and whistles," or some middle ground alternative. This decision takes into consideration
factors such as cost, project risk, and complexity.
Hardware and software platform

The decision about the hardware and software platform takes into consideration both the needs of the system under
development and the constraints imposed by systems currently in place.
Method of acquisition

The method of acquisition focuses on who is going to do the work. Will development be done in-house by consultants hired
for this system? Will an existing system be acquired and, if necessary, customized? This decision was the focus of Topic 3.3.
Ideally, the decision about whether to make or buy a system is made at this point, once the analysis phase is complete.

System design activities


Other activities to perform during the system design phase are

file and database design turning the conceptual data model into a specific database format (for example,
hierarchical, network, or relational database)

program design determining the modules in a system that need to be created and the linkages between them

network design deciding on how multi-user systems will be implemented (distribution of processing tasks and data)

user-interface design designing screens and reports for the system (the inputs and outputs)

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t07.htm (1 of 3) [20/08/2010 11:05:47 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t07.htm

design of internal controls determining how best to secure the system against intentional and unintentional threats

The design of internal controls is explained as part of the discussions on security in Modules 7, 8, and 9. Each of the other
aspects is briefly reviewed here.
File and database design

The analysis phase focuses on the conceptual design of data in the system. An ER diagram, as you learned in Topic 4.4, is
independent of any specific database model. This is important at the analysis stage because the ultimate structure of the
system should not be driven or constrained by a technological choice, but rather by the requirements of the system.
However, given this focus in the analysis phase, one of the steps in design is to take the conceptual data model a logical
model and turn it into a design specific to a particular technology a physical design.
The details of these processes are beyond the scope of this course. As a manager, you are unlikely to participate directly in
these activities, and the details of how they are conducted are quite technical.
Program design

Any large system contains multiple modules that make up its overall functionality. Each module implements part of the
functionality of the system. Modular design is an important characteristic in professional programming. The quality of the
design of modules has an enormous impact on the maintainability of the programs. Because maintenance is a large
component of the total cost of a system, design and development approaches that provide for better maintainability are
highly desirable from a long-run cost and effectiveness point of view.
Network design

Most systems in large businesses are directly used by multiple people in the organization and are accessed through an
internal (or external) network. The performance of these systems is significantly influenced by how well the network design is
created. Various decisions must be made about the network architecture, which you will learn about in Module 8.
User-interface design

The design of user interfaces (forms, reports, and screens) is one of the most crucial determiners of the successful use of the
system after implementation. From the users standpoint, the interface is
the system, because the interface is the only
part of the system he or she sees. If it is not clear, the users interactions with the system will be frustrating and difficult.
Worse, it is likely that errors will result from this lack of clarity. For example, if the name of a field in a form is not clear,
users may enter incorrect information into the field. This will create problems later in terms of data integrity and usefulness.
User-interface design rules

User interface design is very difficult. There are endless rules for how interfaces should be designed, including those related
to size and type of font used, flow of material on screens and in reports, amount of information to present on a page, design
of help systems and menus, use of graphs and tables for presenting information, options for user input and output, and the
appropriate use of colour.
Many of these rules are intended to decrease the cognitive load on the user. Designing menus so that they are consistent in
their use of specific names and appear consistently throughout the application is important to ensure that users dont have to
think about the system. Rather, they can think about what they are trying to do with the system. Similarly, graphs and tables
have different strengths and weaknesses for presenting specific kinds of information graphs are better at showing trends
with little cognitive processing on the part of the user.
User considerations in interface design

One limitation to the ability to design effective interfaces has to do with the wide range of abilities and preferences of
different system users. Colour has different meanings in different cultures. The use of colour in a system interface must be
file:///F|/Courses/2010-11/CGA/MS2/06course/m04t07.htm (2 of 3) [20/08/2010 11:05:47 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t07.htm

consistent with such meanings. But regardless of these issues, users who are colour blind (about 7% of men) cannot process
the signals implied by colour. Users also differ in their reading ability and their understanding of specific jargon.
Thus, interfaces must be designed with sensitivity to who the specific users of the system are going to be. Are they
employees of the firm or customers? What type of employees are they? Senior managers, shop floor workers, or human
resource employees? Understanding who the specific users of the system will be allows the interfaces to be designed using
terminology relevant to those users and layouts consistent with the way the users work through the system processes.

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t07.htm (3 of 3) [20/08/2010 11:05:47 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t08.htm

4.8 Systems analysis and design in smaller organizations


Learning objective

Differentiate between the systems analysis and design phases of small and large projects. (Level 2)

No required reading
LEVEL 2

What about smaller organizations that have no real IS staff, yet need to develop applications. Do the concepts of systems
analysis and design translate to them? If so, how?
Suppose a small professional accounting firm needs a new customer tracking system. To what extent do the concepts in this
module apply? For that matter, the same question can be asked by individuals in larger organizations who are involved in
relatively small systems development projects.
There are a number of differences between larger and smaller organizations that affect the systems development process:

Smaller firms have fewer IS staff and likely do not have the range of specialists of a larger firm. Thus, the same
person might be responsible for database and network design, whereas in a larger firm these would be two distinct
roles.
Smaller firms have substantially fewer financial resources to deal with information systems problems and
opportunities. Moreover, the consequences of a systems failure can be much greater for a small firm because of the
limited financial resources.
The scope and complexity of the system is likely to be smaller because smaller firms typically have not developed
their processes to the same extent as their larger counterparts.

Each of these differences influences the systems analysis and design process.

IS staff
Because small firms have fewer staff, and less-specialized staff, they tend to have less ability to deal with complex system
needs. They are likely to rely on contract personnel and consultants to a greater degree than larger firms, at least when
developing more complex systems. This reliance can create problems when supporting systems, as the expertise about the
system may not be resident in the firm. Purchasing systems is a way to address the lack of in-house expertise.

Financial resources and the consequences of failure


Small firms, with limited financial resources, have fewer options when building systems. Add to this the risk of failure and its
greater impact on a small firm, and you can see why it is difficult for a small firm to pursue leading edge, innovative
solutions. Small firms are more likely to pursue incremental projects, which provide immediately needed support to the
business operations. Of course, there are exceptions, and there are times when small firms are more capable of innovation
because of the lack of rigid bureaucracy and entrenched processes. However, for most IS development, the needs of small
businesses are smaller, more incremental, and simpler.

System scope and complexity


Many of the techniques described in Topics 4.3 to 4.7 are used partly to manage risk when building complex systems. For
example, drawing detailed data flow diagrams is an element of structured analysis. Structured analysis methods were
developed to ensure that the functionality of complex systems is thoroughly investigated before the process of building the
system begins.

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t08.htm (1 of 2) [20/08/2010 11:05:47 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t08.htm

It is more costly to fix mistakes when they are discovered during programming than when they are discovered working with
paper models of a system. The cost can be about six times higher in large and complex systems. For smaller systems, the
difference in cost is not as severe and the requirements may be significantly less complex. In this case, detailed drawings of
data flows may not be necessary. A simple description of an element of program logic may be all that is needed. The use of
Structured English or development of decision tables may be beyond what is useful.
It is important, however, to remember that the potential for failure is not just a function of the size of the system. Many
projects fail because they do not adequately define the need for and goals of the new system. Without attention to the
analysis process, the risk of missing objectives is much higher.
From a management standpoint, it is important to realize that the scale of the analysis and design effort (but not its presence
or absence) depends on the scope and complexity of the system. A highly complex system, to be used by many different
users across a wide range of functional areas of the firm, will require greater formalization in the analysis and design process
than a system that is to be used by a small number of users in a single functional area for a relatively straightforward task.
But in both cases, attention to the data, processes, and logic of the system are necessary to ensure that it is well understood.

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t08.htm (2 of 2) [20/08/2010 11:05:47 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t09.htm

4.9 Ethical issues in systems development


Learning objective

Assess the ethical issues of situations that arise during systems analysis and design. (Level 2)

No required reading
LEVEL 2

During systems development, you may encounter situations that require you to exercise your ethical judgment. For example,
you may learn trade secrets of the organization that may be worth a lot of money to its competitors. Or you may learn of
organizational practices that are abusive to the organizations employees or customers. Remember that being a CGA or CGA
student means that the CGA-Canada Code of Ethical
Principles and Rules of Conduct
(CEPROC)
applies to you, regardless of the industry youre working in. (See "Code of Ethics" under the Course Modules link.)

Taking things that do not belong to you


The knowledge you gain about the operation of the business belongs to the organization; you have no right to sell or disclose
such information to the organizations competitors or to use it for personal advantage. If you are an external consultant, this
can be a particularly thorny issue. What if, for example, you had learned information during a previous assignment that could
help your present client compete against your previous client? An example would be taking a customer contact list from a
previous client. In this case, you are ethically bound not to disclose information gained during systems analysis performed for
another organization. It would also be wrong for a manager to "pump" a new employee hired from a competitor for
confidential information acquired during previous employment.
Of course, there are also things that employees receive from previous employers that legitimately belong to the employee.
Included here would be skills and abilities acquired on the job. In other words, a distinction must be made between what
legitimately belongs to the employee and what is illegitimately taken by the employee from the employer. To make such a
distinction, it is important to turn to ethics.
Example 4.9-1: The Right Stuff

This episode of The Right Stuff


is a video illustration of ethical issues in a corporate
setting that allows you to exercise your ethical judgment. (This episode is approximately two minutes long.)
Print version

Organizational abuse
The discussion below refers to a five-step model of decision-making in Unit A8 of the Ethics
(ERH). Please note that the five-step approach has been
Readings Handbook
merged with the nine-step approach to case analysis in Unit A8 of the ERH. The original five steps are listed in the solution to
Activity 9.5-1.
What if you discover that the organization appears to have practices that are abusive to its employees, such as secretly
monitoring its employees and then using the results of this monitoring to discipline or fire employees? What should you do?
This is a difficult case because there appears to be a conflict between two important ethical considerations: loyalty to your
client (or employer) and fairness to the employees (or your co-workers).
Which consideration is the most important? In weighing competing ethical considerations, it is helpful to follow the decisionmaking process described in Unit A8 of the Ethics Reading Handbook. The fourth step in that process, "propose and test
possible resolutions," is the part that is most relevant here. For example, use a sensitivity analysis to ask what factors in the
file:///F|/Courses/2010-11/CGA/MS2/06course/m04t09.htm (1 of 2) [20/08/2010 11:05:48 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t09.htm

case would have to change to provide you with a situation where the choice seems clear.
Also, asking what a virtuous professional would do in such a situation is a good guide. In using these and the other tests
suggested in the fourth step of the decision-making guide, you would be led to considerations of fairness, in particular
whether secret monitoring of employees is fair and whether such monitoring treats employees with respect. Fairness and
respect are two principles discussed in Section A4 of the Ethics Reading Handbook.
Relevant to fairness is whether the monitoring is for cause or not for cause. That is, is the monitoring based on a reasonable
suspicion of an employees wrongdoing, or is the monitoring simply a "fishing expedition"? The latter is much harder to
ethically justify than the former. A second question to ask is whether the use of information from monitoring is fair and
respectful. It certainly would be unfair and disrespectful if employees have no opportunity to respond to any charges against
them.

Accessory to unethical acts


What if you discover during the course of systems analysis that employees in the organization have done something
unethical? What obligation do you have to disclose the unethical deed to the employer or even to legal authorities if the
actions in question are illegal as well as unethical?
The CGA-Canada Code of Ethical Principles and
provides some guidance in such situations. The Code defines a duty
Rules of Conduct
of trust that CGAs owe to clients and employers. You should decide if the unethical behaviour is work related. If it is, then it
should be reported to the employer. If the employees unethical behaviour is totally unrelated to the clients or employers
interests (such as drug use by an employee at home) there would normally be no duty to report. However, if you detect
activities that are serious threats to the safety or health of individuals, you have an ethical obligation to report it to
appropriate authorities.

file:///F|/Courses/2010-11/CGA/MS2/06course/m04t09.htm (2 of 2) [20/08/2010 11:05:48 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04summary.htm

Module 4 Summary
Systems analysis and design
Distinguish between logical and physical models.

Logical models describe what the system does


, without reference to
how this is currently
accomplished.
Physical models include details of the current physical implementation of a system (computer-based or not). That is,
they describe how
the system does what it does.

Elaborate on the steps in developing a system in particular, the phases of analysis and design.

The systems analysis phase includes three main activities:

gathering requirements

structuring requirements

generating and selecting alternative design strategies


Systems design follows systems analysis and implements the selected design strategy. It includes activities related to
the design of

files and databases

programs

network

user interfaces

internal controls

Plan the requirements-gathering phase of systems analysis.

All information systems must accomplish some task or meet some need in the organization.
It is this functionality that must be determined in order to develop a system.
Functionality is expressed by three types of information:

What is the system supposed to do and what are the business processes that are occurring?

What kind of information or data is required by the system and what kind of information or data is produced
by the system?

What are the policies and/or rules that need to be embedded in the system?

Assess situational factors and choose between the different approaches to requirements gathering.

There are a number of techniques that an organization can use to determine the requirements and information that a
potential system needs.
An essential technique of requirements analysis is interviewing. This helps to establish the expectations of the various
users and stakeholders of the new system.
Questionnaires are also used to determine certain kinds of requirements of a new system but they make follow up
difficult.
Observation can be used to determine system requirements, especially around processes and embedded rules.
Reviewing the existing documents, especially the documents that are the outputs of current systems, can help
determine information requirements.
Prototyping also helps to determine the requirements of a system since the review of the prototype will redefine the
requirements of the system.
JAD is a formal method of doing requirements analysis. It brings together both users and developers and uses a
facilitator to state the system requirements from both sides process requirements and technical requirements.

Explain process modelling.

Process modelling is used to document the activities or processes of a system.


A common technique for process modelling is to use data flow diagrams (DFDs).
DFDs are an attempt to model the reality of a system, so it is important to document how the system actually works,
as opposed to how you think it should work.
Process modelling helps determine how information flows in a system, but does not depict the physical components

file:///F|/Courses/2010-11/CGA/MS2/06course/m04summary.htm (1 of 3) [20/08/2010 11:05:48 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04summary.htm

of the system.
Draw a simple data flow diagram (DFD).

DFDs are drawn in sets. The first set is the context diagram that shows the main processes of the system (see Exhibit
4.3-1).
Each subsequent step models a single process in more detail and the sub-processes that make up that process.
There are rules used in constructing data flow diagrams based on the acceptable symbols, naming conventions, and
rules on how these are used (see Exhibit 4.3-2).
There is not a single correct technique for developing a DFD, but there are some steps that can be followed that will
add structure to the process:
1. Identify the external entities.
2. Identify the inputs and outputs.
3. Identify the data stores.
4. Identify the main processes or activities of the system.
5. Draw a Context and Level 0 diagram and compare them to the existing documentation of the system. Make
sure that there is no process in the Level 0 diagram that doesnt occur in the Context diagram.
6. Walk through the DFD with the analysts and users to confirm the accuracy.

Interpret the way entity relationship (ER) diagrams can be used in data modelling.

ER diagrams show the people, things, places, or events that you need to record data about.
ER diagrams also identify the attributes of an entity and show the relationship between entities.
Relationships in ER diagrams describe the rules or conventions of how entities interact with each another and are
particular to the specific organization.
ER diagrams are independent of any database software.

Draw a simple entity relationship diagram.

An ER diagram typically consists of three components:

a representation of two or more entities

arrows that represent the relationship between entities

a description of the attributes of the entities


Starting with a description of the process or system, you identify the entities that are required and then use attributes
to describe each entity.
Based on the rules of the system, you can establish the relationships between the various entities.

Represent processing flow using Structured English.

Structured English is based on three basic constructs: sequence, decision, and repetition. A combination of these
constructs is used, depending on the procedures being described.
The sequence construct is simply putting precise, descriptive, instruction statements together, one following another.
The decision construct, also known as the selection construct, permits two formats to specify branches to the
sequence of instructions.

The if-then-else
construct is the most common; it provides a binary selection.

The case
construct is used to handle situations where there are three or more choices.
The repetition construct, also known as the iteration or looping construct, has two variations:

The do-while
construct follows a set of instructions if a condition is true. This is a zero-ormore construct.

The repeat-until
construct: Repeat a set of instructions based on the value of
a condition. This is a one-or-more construct. The set of actions must be executed at least once.

Construct decision tables to document the processing logic of a set of procedures.

Decision tables are ideal for describing business policies where a set of rules is used to describe each possible
combination of events.
A decision table consists of three parts:

condition stub: a list of all the possible factors that affect the decision. This is shown in the first rows of the
decision table.

action stub: a list of all the decision processes (for example, outcomes) for the decision table. The action
stubs appear in the bottom half of the table.

decision rules: actions that are to be taken under a specific combination of decision conditions. Each decision
rule is a column in the table.
There are seven basic steps for building a decision table:

file:///F|/Courses/2010-11/CGA/MS2/06course/m04summary.htm (2 of 3) [20/08/2010 11:05:48 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04summary.htm

1.
2.
3.
4.
5.
6.
7.

Identify the conditions and values.


Determine the maximum number of decision rules.
Identify possible actions to be taken for each decision or policy.
Enter in all possible rules.
Form a possible decision rule for each unique combination of conditions.
Define the actions for each rule.
Simplify the decision table; if the outcomes dont differ at each level, then one rule can encompass them all.

Design a simple use case to support systems design.

Use cases describe the important "events" in an information system (the activities in the business processes that
require the system to take some action). Each use case is described using the following elements:

basic descriptive information: name, description, number, and so on

trigger: the event or timing that initiates the process

inputs and outputs: sources and destinations of information

details: the steps required to complete the process, information needed, and the direction of information flows

Analyze the primary decisions and activities in the systems design phase.

A design strategy includes three main decisions:

System functionality. How much functionality needs to be built into the system based upon factors such as
cost, risk, and complexity?

Hardware and software platform. Which hardware and software platforms should be used for the new
system? This can be constrained by the current system in place.

Method of acquisition. Who will do the work? This is the make versus buy decision.
Systems design phase activities:

File and database design: turning the conceptual data model into a specific database format (for example,
hierarchical, network, or relational database)

Program design: determining the system modules that need to be created and the linkages between them

Network design: deciding on how multi-user systems will be implemented (distribution of processing tasks
and data)

User interface design: designing screens and reports for the system (the inputs and outputs)

Design of internal controls: determining how best to secure the system against intentional or unintentional
threats

Evaluate and discuss user interface in terms of design.

User interface design is critical, because the interface is how users interact with the system. The effectiveness of the
system will be indicated by how easily users can accomplish their tasks.
Effective design aims to decrease the cognitive load on the user. This rule explains the myriad suggestions that are
given on all aspects of design (such as menu consistency, choice of tables and graphs, use of colour, and so on).

Differentiate between the systems analysis and design phases of small and large projects.

Smaller firms have fewer IS staff and fewer resources for systems development.
Smaller firms have more challenges around user capabilities and information systems.
Smaller firms have fewer financial resources, making the financial risks greater.
Scope and complexity are likely to be lower in smaller firms.
It is important to remember that even if the projects are smaller in scale and complexity, it is still critical to engage in
proper and appropriate systems analysis and design when dealing with smaller firms, especially if the consequences
of systems development failure could mean the failure of the business.

Assess the ethical issues of situations that arise during systems analysis and design.

Taking things that do not belong to you: The knowledge you gain about the operation of the business belongs to the
organization; you have no right to sell or disclose such information to the organizations competitors.
Organizational abuse: Organizational abuse occurs if an organization has practices that are abusive to its employees,
such as designing systems to secretly monitor the performance of employees and using unfair measures that
employees are unaware of and have no recourse to rectify.
Accessory to unethical acts: What if you discover during the course of systems analysis that employees in the
organization have done something unethical? Acting in support of an unethical act (by hiding it or not acting on it)
makes you equally responsible for the behaviour.

file:///F|/Courses/2010-11/CGA/MS2/06course/m04summary.htm (3 of 3) [20/08/2010 11:05:48 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04selftest.htm

Module 4 self test


1. You have been hired to conduct a requirements analysis for the development of a new student information system for
the CGA program. Your internal contact, the Director of Student Services, has asked you to outline a plan for
gathering system requirements for this system. Present your response in good form and ensure that you address the
following three questions:

What kind of information do you need to gather?


What sources of information and/or forms of information gathering would you use?
What are the key challenges in gathering information for this system?

Solution
2. Read the system description for the receiving function at Globe Appliances, and answer the questions that follow it.
Receiving function at Globe Appliances
Globe Appliances, a Montreal-based organization, markets household products, such as microwave ovens, food
processors, cooking ranges, mixers, juicers, and various other electrical and non-electrical appliances. It has 15
branch offices in Toronto, Ottawa, Vancouver, and other major Canadian cities.
For the past few months, Susan Greenspan, Vice-President of Operations, has been getting complaints from various
departments about the inefficient handling of receipt products by the warehouse. Susan has invited Keystone
Consultants, which specializes in corporate affairs, to assess the situation and provide some suggestions for
improvement. Richard Burn, the warehouse manager, describes the functioning of his department to Keystone
Consultants as follows.
A clerk at the warehouse receives copies of the purchase orders (POs) mailed to the vendors. The clerk sorts all the
POs by date and places them in the PO file pending receipt of the goods. The suppliers deliver the ordered products
along with packing slips (PSs) to the warehouse. The receiving clerk checks the PS for PO numbers and takes the
corresponding POs from the PO file. The clerk then compares the products received to the products ordered for any
discrepancy. If the goods are damaged or are not of the quality specified on the POs, they are sent back to the
supplier with the PS and a rejection letter explaining the reason. Otherwise, the PO and the PS are used to prepare a
"receiver" describing the discrepancies (if any) in terms of quantities or delivery dates.
The PO, the PS, and the receiver are sent to another clerk who updates the inventory file. For incomplete orders, a
copy of the PO, PS, and receiver are returned to the PO file. The receivers, POs, and PSs are then sent to the
purchasing department for further processing.
a.
b.
c.
d.

What are the external entities (sources/sinks) relevant to this system?


What are the inputs and outputs of the system?
What are the internal processes within the system?
Draw a context diagram and a level 0 logical DFD for the system.

Solution
3. As a systems analyst working on contract for the Ministry of Education, you have been gathering information about
the requirements for a new system. The purpose of the system is to track student scores on provincial tests
administered by the Ministry. The stated purpose of standardized testing in the province, and thus the goal of the
system, is to provide feedback to the students and aggregate reporting of scores by school district.
In the course of gathering requirements, several requests have been made to improve the system by integrating it
with other related databases. One analyst suggested linking the data with provincial health records to allow for
analysis of health and wellness influences on school performance. Another suggested linking it with the university
applications facility, so that standardized test score data could form part of the university admission decisions. Adding
these links would be fairly simple technically and would not add substantially to the cost of the project.
Identify and explain any ethical issues you see with these requests.
Solution

file:///F|/Courses/2010-11/CGA/MS2/06course/m04selftest.htm (1 of 2) [20/08/2010 11:05:49 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04selftest.htm

4. Why is it important to gather systems requirements? What makes gathering systems requirements so difficult?
Solution

file:///F|/Courses/2010-11/CGA/MS2/06course/m04selftest.htm (2 of 2) [20/08/2010 11:05:49 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04selftestsol1.htm

Module 4 review material


Question 1 solution
You will need to gather information about the data that are maintained in the system, the processes the system undertakes
(functions), and the logic of how processes are performed (these are the three kinds of modeling done in the analysis phase:
data, process, and logic modeling).
You should be able to identify a broad cross-section of stakeholders from whom you need to gather information (students,
lecturers, markers, tutors, CGA staff, potential employers, and so on).
You will need to gather information from users of the system, from users of the information, and from the other key
stakeholders (this relates to the purpose of the system).
Information could be gathered through questionnaires, interviews, observation, and document review. These four methods
should all be mentioned, with some reasons why each would or would not be used. In general, all would be used for this
system.
The key challenges are

Multiple stakeholders open up the possibility for differing views about what the system should do. This is particularly
true because all the stakeholder classes are widely spread geographically.
Questionnaires/Interviews: People dont always know what they need or are not always able to articulate how they
do things; therefore a key challenge is to really understand what is going on. This is why we need multiple
information sources and why observation and document review in particular are valuable.
Absence of good documentation on the existing system is possible.

file:///F|/Courses/2010-11/CGA/MS2/06course/m04selftestsol1.htm [20/08/2010 11:05:49 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04selftestsol2.htm

Module 4 review material


Question 2 solution
a. The external entities relevant to this system are suppliers and the purchasing department.
b. The inputs and outputs of the system are
Inputs: copy of purchase order, packing slip
Outputs: receiver, purchase order copy, packing slip, and rejection letter
c. The internal processes within the system are

Receive and sort purchase orders.


Receive packing slip and match to purchase order.
Check goods.
Prepare rejection letter.
Prepare receiver.
Update inventory file.
Re-file purchase order and packing slip for incomplete/non-matching shipments.
Send PO, PS, and receiver to purchasing.

d.

file:///F|/Courses/2010-11/CGA/MS2/06course/m04selftestsol2.htm [20/08/2010 11:05:49 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04selftestsol3.htm

Module 4 review material


Question 3 solution
Both requests have merit, but both raise ethical issues. The link to health data would allow for detailed research on health
and education to be conducted, which could have long-term implications for both sectors. On the other hand, the request is
quite vague and so the benefits are not very clear. The link to university admissions would be very useful for universities and
might allow for fairer admissions processes by allowing for decisions based on standardized tests. The primary ethical
problem is that of privacy individuals (students) provide test data for a specific stated purpose (feedback, aggregate
reporting). To begin to use that data for other purposes constitutes a breach of privacy. Also, the link to health data
potentially makes available very private information and thus it would be important to ensure that any identifying information
was removed from the records. In this case, you would simply be comparing anonymous health records with anonymous
school records. This would mitigate the privacy concerns somewhat.
Thus, any decision about whether to provide these features would require greater consultation with stakeholders (parents,
teachers, students) and careful attention to the privacy rights of those affected. If consent was given for one purpose, it does
not automatically apply to other situations.

file:///F|/Courses/2010-11/CGA/MS2/06course/m04selftestsol3.htm [20/08/2010 11:05:50 AM]

file:///F|/Courses/2010-11/CGA/MS2/06course/m04selftestsol4.htm

Module 4 review material


Question 4 solution
System requirements involve identifying who needs what information, where, when, and how. They define the objectives of
the new or modified system and contain a detailed description of the functions the new system must perform. Gathering
system requirements is perhaps the most difficult task of the systems analyst, and faulty requirements analysis is a leading
cause of systems failure and high systems development costs.
System requirements are difficult to determine because business functions can be very complex and/or poorly defined. A
manual system or a routine set of inputs and outputs may not exist. Procedures may vary from individual to individual, and
users may disagree on how things are or how they should be done. Defining system requirements is a laborious process,
requiring a great deal of research and often many reworkings by the analyst.
Source: M. Lisa Miller and Mary Elizabeth Brabston, Instructor's Manual
to Management Information Systems:
Managing the Digital Firm
Reproduced with the permission of Pearson Education Canada.

file:///F|/Courses/2010-11/CGA/MS2/06course/m04selftestsol4.htm [20/08/2010 11:05:50 AM]

, Second Canadian Edition, 2005.

Page 1 of 1

Module 4 online discussion


Updated Dec. 21/10, MS2-10-TU02
Website usability (20 marks)

Review the website Usability.gov. This is a U.S. government website which records an amazing amount of
material on the qualities of usability. It is focused on online systems, but much of the content relates to all
types of systems.
In about 200-250 words, post your response to the following:
1. Why is website usability so important in e-commerce?
2. What characteristics of the company or organization and what technological issues affect the usability
of a website?
3. Choose five e-commerce websites, and analyze them in terms of design and "user-friendliness." In your
posting, indicate the websites you visited. (Ensure the sites you visit are sites where business
transactions are conducted over the Internet.)
Prepare and post your first post to your discussion group as early in the week as possible, no later than noon,
local time, of the Saturday before the first assignment is due. (For the purpose of this course, the week starts
on Friday and ends on Thursday.)
Read and respond to the postings of at least two of your group members by Monday at noon, local time. If
you notice group members who have not yet received a response, direct at least one of your responses to
such students. Your responses should be designed to encourage discussion. For example, comment on how
other students' findings are similar to or different from yours, and ask questions to clarify their findings.
Respond to the questions and comments other students have posted regarding your postings by Thursday
(final date on the Course Schedule) at noon, local time.

Feedback
For feedback on your discussion postings, click the Gradebook link in your MS2 Assignment Submission/Group
Work section under the My CGA tab. You can tell the marker's feedback is ready when the Graded column
has been filled in and the feedback link is available.

file://F:\Courses\2010-11\CGA\MS2\06course\m04od.htm

12/20/2010

You might also like