Professional Documents
Culture Documents
htm
Identify the organizations IT needs to meet financial data processing, control, and reporting requirements.
file:///F|/Courses/2010-11/CGA/MS2/06course/m04intro.htm
file:///F|/Courses/2010-11/CGA/MS2/06course/m04t01.htm
Required reading
LEVEL 1
There are two phases in developing systems: the systems analysis phase and the design phase.
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
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.
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.
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/m04t02.htm
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 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.
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
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.
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.
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
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/m04t03.htm
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
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
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
file:///F|/Courses/2010-11/CGA/MS2/06course/m04t03.htm
Symbols
External entity
Closed rectangle
Process
Data store
Open-ended rectangle
Data flow
Arrow
Naming conventions
External entity
Process
Data store
Data flow
Rules
Process
Every process must have at least one input and one output.
Data flow
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.
file:///F|/Courses/2010-11/CGA/MS2/06course/m04t03sol1.htm
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/m04t03sol2.htm
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/m04t04.htm
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 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
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/m04t04sol1.htm
file:///F|/Courses/2010-11/CGA/MS2/06course/m04t04sol2.htm
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/m04t05.htm
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
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
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
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
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/m04t05sol.htm
file:///F|/Courses/2010-11/CGA/MS2/06course/m04t06.htm
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
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
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/m04t06sol.htm
file:///F|/Courses/2010-11/CGA/MS2/06course/m04t07.htm
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
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.
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
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/m04t08.htm
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.
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/m04t09.htm
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.)
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.
file:///F|/Courses/2010-11/CGA/MS2/06course/m04summary.htm
Module 4 Summary
Systems analysis and design
Distinguish between logical and physical models.
Elaborate on the steps in developing a system in particular, the phases of analysis and design.
gathering requirements
structuring requirements
programs
network
user interfaces
internal controls
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.
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.
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.
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
1.
2.
3.
4.
5.
6.
7.
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:
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.
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
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/m04selftest.htm
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.
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
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/m04selftestsol1.htm
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/m04selftestsol2.htm
d.
file:///F|/Courses/2010-11/CGA/MS2/06course/m04selftestsol3.htm
file:///F|/Courses/2010-11/CGA/MS2/06course/m04selftestsol4.htm
Page 1 of 1
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