module 04

Module 4: Systems analysis and designOverview

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

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]

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

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


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.


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.




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.



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.


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:




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



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.



Exhibit 4.3-2: Data flow diagram rules

SymbolsExternal entity Closed rectangle

Process Oval or rounded rectangle

Data store Open-ended rectangle

Data flow Arrow Naming conventionsExternal 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 usedData store Noun (for example, Customer Listing, Back-ordered Product)Data flow Noun (for example, Application Request)RulesProcess 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 requirements-gathering 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.


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

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


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).



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:




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.



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 store, you might see multiple copies of Super Hit III a new release on the shelf. If one is 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.



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 example, customers place orders, or customers buy products.



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 store. Super Hit III , for example, is a new release, which means it has a one- or two-day rental 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]


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]

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




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,


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


Case 2: TYPE = 200


Case 3: TYPE = 300




Case 4: TYPE = 400


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



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



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



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



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

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

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




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



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/m04t06sol.htm [20/08/2010 11:05:46 AM]

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)




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



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.


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.




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.


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 Readings Handbook (ERH). Please note that the five-step approach has been 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 decision-making 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




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 Rules of Conduct provides some guidance in such situations. The Code defines a duty 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.


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: m gathering requirementsm structuring requirementsm 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

m files and databasesm programsm networkm user interfacesm 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:

m What is the system supposed to do and what are the business processes that are occurring?m What kind of information or data is required by the system and what kind of information or data is produced

by the system?m 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

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

module 04

Documents

developing systems

systems design4

successful systems projects

phases of analysis

design phase

design level

design overview4

user requirements