Module 4: Systems analysis and design

Overview
In Module 3 you were introduced to the process(es) by which systems are acquired in organizations. You
learned about the challenges of managing IS projects, the different approaches to acquiring systems, and
the factors that tend to result in successful systems projects.
Module 4 covers the more technical aspects of systems analysis and design. You may think that as a non-
IS professional or manager you will not have to deal with this level of technical detail. In many cases,
that would be right. But as a financial manager who must understand how a system calculates data that
is used in the creation of financial statements, this is information you want to know.
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, from requirements gathering to system design.
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
applicable, to some degree, for purchased systems. The design and code phases of a development
project will not be written in-house when software is purchased, however, users still need to understand
how data in the purchased system gets created. The requirements phase is still applicable; since the
information collected here helps you decide which vendor software offers the closest fit to your particular
system requirements.
The technical competencies you will develop in this module include selecting and using appropriate
business technology tools in the workplace; collecting, selecting, verifying, and evaluating information
relevant to the problem; and anticipating and meeting the needs and expectations of internal and
external stakeholders.
4.1 Analysis and design overview
4.2 Systems analysis: Requirements gathering
4.3 Process modelling: Data flow diagrams
4.4 Data modelling: Entity relationship diagrams
4.5 Logic modelling: Structured English
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
Print this module
4.1 Analysis and design overview
Learning objectives
Distinguish between logical and physical models. (Level 1)
Evaluate 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
Module scenario: Documents to nowhere
The last seven months have been tough on one of your legacy systems: the old VAX paint process
application. First the network connection failed and it took you two days to source a replacement card.
Next the temperature sensor forced a shutdown of the machine, and a $2500 maintenance bill to bring it
back up. You have said it needs to be replaced, that its just a matter of time before it shuts down for
good, but no one is taking it on. The paint department sees it as your issue. Last week you asked one of
your analysts to look over the VAX documentation, and tell you whats good, bad, and just plain missing.
If were going to replace the Paint process application, you said, wed better know what weve got. The
analyst confirmed your worst fears.
We have notes, he said. Handwritten notes about the VAX and the paint process app. Nothing to build
a replacement system on. Its going to take me two months to put something legible together.
You thank him and add that he has three weeks to do it. You explain that the correct documentation is
critical to the companys operations. You tell him you need a full-scale set of documents: data flow
diagrams, entity relationship diagrams, logic models, and decision models you need it all. This
application is critical. Create the documents and have them to me in three weeks.
As he leaves your office, you yell after him, Whatever system we go with next time will include UML as
the program modelling standard or we dont touch it.
LEVEL 1
As we discussed in Module 3, in the SDLC there are two informational phases in developing systems: the
systems analysis phase and the design phase. Together, the two provide a comprehensive view of
development: system analysis is the top of the funnel where all the information is gathered, sorted, and
evaluated, but the design is the narrow part of the funnel, where that information is combined and
reduced to program specifications for the developers.
Here is a basic cross-functional flowchart detailing the processes and output for the next few topics in
this module, and how they relate to the business process flow, a key component of the analysis and
design phase.
Exhibit 4.1-1: Cross-functional flowchart

Systems analysis phase
The systems analysis phase of the SDLC is concerned with identifying a systems functional requirements
in other words, what the system 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, through the
gap analysis determined by the comparison of current and future states. This process focuses on
analyzing the needs of the system.
It is important to recognize that system analysis takes time. Attempts to rush it, or impose arbitrary limits
on its process, can result in failed projects. If critical requirements are missed, your system design could
suffer, and in some cases be unusable. Three sub-phases make up the analysis phase:
1. Requirements gathering (Topic 4.2)
2. Requirements structuring process (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. In other words,
how to take all the information collected about what the new system should look like, and convert it into
program specifications that a developer can use to create the new system. With any system, there are
different ways to fulfill the requirements. Developers are concerned with the input-process-output model
of the requirements, including the screens, the buttons, and the process flow of data. If the goal of the
requirements phase is to arrive at a blueprint of the new system, the design phase is about determining
the materials to build it.
Consider, for example, the requirements of a new 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 as the functional requirements. You could build such a system by reusing tools
already embedded in MS Office (Excel for budgeting and Gantt charts, Outlook for allocating tasks, Word
for maintaining project documentation, and so on), and then add to these your own specifics to
customize the look and feel of the system. Or you could build it using custom-developed tools for each
requirement. Will it be built for one-person use (the project manager), or by multiple members of a
project team (simultaneous access to the file)? Will it be accessed from a website (using which
browsers), a PC (running which version of Windows, or Linux, or MAC OSX), a tablet (with touch
sensitivity), or even a smartphone (which versions, running which mobile operating systems)?
As you can see, there are many different design questions that must be answered before developers can
fulfill the information needs of a new system. 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, platform design, and user interface design.
Overview of modelling
Modelling plays a significant role in systems analysis and design. It provides developers the details they
need to understand how to interpret the requirements blueprints. System modelling can be used to study
the existing system, document the business requirements and detail design of the new system, and assist
in the creation of the gap analysis. In this module, the following three topics represent the modelling
components of the requirements structuring process. They are discussed in detail in Topics 4.3, 4.4, and
4.5:
1. Process modelling (Topic 4.3) This is a topic in systems engineering that uses data flow
diagrams (DFD) to express the flow of information across business processes. A business process
(the collection of activities that produce a specific good or service) creates a distinct trail of data as
it progresses toward completion, thus modelling that trail is important.
2. Data modelling (Topic 4.4) This is a topic in software engineering that uses entity relationship
diagrams (ER) to model the database structure and the flow of data within processes (that is,
within a DFD). Data modelling helps define the requirements that support process modelling, and
helps model data in a consistent, predictable, and manageable manner.
3. Logic modelling (Topic 4.5) This uses structured English in combination with DFD models and
ER data models to further describe the processes of a system from the view of enacting decision
tables, decision trees, and other techniques, because DFDs and ER models cannot represent the
complexity of a process.
Combining the above modelling processes helps to create a layered definition of a business process, as
seen through the activity of the process (process modelling), the data flow within the process (data
modelling), and the logic/decision structures (logic modelling) that accompany the data. Note too that
these system and software modelling tasks do not exist in isolation. Business process improvements,
using a choice of such tools as Six Sigma and Lean, work in conjunction with the system and software
modelling options. Companies choose a process improvement method, apply its tenets, and model the
process improvements in the accompanying data flow. Not all methods are used simultaneously; a
company adopts the tools best suited to the task.
It is important to position the structured analysis method (logic modelling) as an older methodology a
document-based approach to systems design, with a strict adherence to the waterfall method of systems
analysis. The issues with this approach are time and resources. The level of documentation in the
structured analysis method is overwhelming for many SMEs with limited budgets and timeframes.
Often the bare minimum of documentation is created, and system analysts and programmers are
required to do a fair amount of interpretation in the design phase instead of relying on well-described
requirements, as is often the method used in the traditional SDLC approach.
An alternative approach to SDLC, agile software development produces little process documentation.
Agile shortens the development life cycle by developing in short intervals, providing spiralling increments
of software projects that combine into the whole. It is best suited for development projects where the
requirements cannot be clearly defined. Various flavours of agile include Scrum, Extreme Programming,
and Lean Development. An agile approach to modelling shows that the ad hoc DFD approach is often
sufficient to describe and build a process model, as opposed to more exacting software modelling
approaches. As previously stated, time and resources are the key issues. The following exhibit is an
example of a hand-drawn DFD usage scenario describing the enrolment process in a university.
Exhibit 4.1-2: Agile modelling Enrolling in the university

Source: Scott Ambler & Associates, 2013, Data Flow Diagrams (DFD), 2003-2012 Scott W. Ambler.
Accessed on February 20, 2013: http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm
This is one example that shows the changing approach to process modelling, and that a hand-drawn DFD
is sufficient to document the business process. Time and resources are saved and better used in other
design areas.
Even large organizations struggle with the level of documentation specified in a structured analysis
method. It is still in use today, but be aware that replacement methods more in line with RAD
methodologies and object-oriented programming are more widely used today. These will be discussed
in Topic 4.6 (UML case diagrams). What is important to note is that organizations can compromise on the
level of detail required. Presented in this module is a full spectrum of the modelling diagrams that can be
deployed during system development.
Two important concepts apply to these model types: logical and physical models. Although the course
focuses on logical models, it is important to understand the difference.
Logical models
The three model types described above process, data, and logic are examples of logical models.
Logical models (not to be confused with the 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 like the operating system or type or design of a database. Instead, they show
the "what" of the new system, independent of the technical details. Logical models are mainly used to
document the business requirements of a proposed new system.
In the systems analysis phase, 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
direct creativity toward the requirements of the future system.
They reduce the risk of missing business requirements by better analyzing the requirement for
completeness, accuracy, and consistency.
They can be used as a form of non-technical communication between project team members and
management.
Physical models
Physical models are used to document the current system, including all implementation-specific
information (operating systems, databases, data types, program languages, program interfaces, etc.).
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 requirements phase. They can also be used to
visually present the approved design for a new system at the selection phase of systems development.
However, because 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. Whatever development methodology a systems
project may adopt (SDLC, prototyping, end-user, RAD), without a clear understanding of the
requirements, the design phase will be based on guesswork not a supported way to build a system.
Systems development is an iterative process, and one that cannot be locked into a rigid hierarchy of
process blocks or approved in contained segments without verification of what strategic issue the
requirements are supposed to solve. It is true that development projects must first be understood in
terms of their size and nature, to determine which methodology (such as SDLC, RAD or agile) will best
suit them. This is part of the analysis phase, and one where IS plays a key role.
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 continued
support for the new system. It is one thing to have financial backing for the project; it is another to have
user support. Both are needed for success, although user support includes the knowledge that a new
system means how things get done is going to change. The change management aspect of systems
development will be addressed in Module 10.
Information required What do we need to know?
For the SDLC approach, 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.
Five steps to determine system 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 involves 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. Performing a gap analysis between the objectives of the new system and the realities of the
current system
5. 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 and provide a number of
advantages to all team members. You cant improve a process if you dont know what its actually doing.
Here are three outcomes expected from documenting the current system:
1. A standard look and feel for abstract business processes
2. A document of processes that can be discussed openly by all team members
3. A way to visually represent both the old and new system. One for posterity, the other for the
developers to code the new system
Case diagrams, data flow diagrams, entity relationship diagrams, structured English, and decision tables
and trees are all useful modelling techniques that can be applied 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. The opportunities for improvement may come as an unplanned opportunity through the course
of normal business, or it may be a steering committee directive, part of an information system strategy,
or part of a business process redesign. Whichever area leads the directive, identifying the problems for
improvement is best approached through a problem-solving framework. A tool to help identify problem
areas is the PIECES framework, which is often used in information systems to help classify problems,
opportunities and directives. 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.
Note that some problems can fall into multiple categories. The key is to analyze and classify the
problems/opportunities correctly, so that the complexity of the problem is understood.
3. Establishing system improvement objectives and constraints
From 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. These objectives can be
part of a systems strategy, business improvement directive, or steering committee/governance directive.
The key is that there is a real business case explicitly behind them; an improvement that solves a
measurable problem or eliminates the risk of one. 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.
Objectives can include the specifics behind such goals as:
Integration with legacy systems
Back-office integration with e-commerce web
Ability to support a SOA framework
Improved customer service
Website/CRM integration
Constraints, which are likely to delay a project, fall into three categories: technological, resource, or
physical. From a scheduling perspective, constraints are generally restrictions in time or resource, and
can consist of some of the following factors:
Limit on implementation time (resource)
Allocated budget dollars (resource)
Access to needed resources (resource)
Restrictions on the sequencing of tasks (technological)
4. Perform a gap analysis between systems
When the documenting and modelling of the old system is complete, you will have a very thorough
picture of how the system works, and more importantly, where it doesnt work. This information, coupled
with the reasons why a new system is being considered, represent a method to metaphorically place the
new system documentation upon the old, and see the gaps between them. The gap analysis identifies
the differences between systems, which is the first step towards understanding what the new system
should look like.
Benchmarking, the process of comparing specific business practices to the industry or internal best
practices, is one way that a gap analysis can be conducted. How does a plan for process improvement
measure against industry standards? In systems development, benchmarking to discover the gaps in
areas of system service or program capability is essential to help identify baseline measures, which are
used to help measure the progress toward the future goals.
5. 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
with the users.
The document itself generally takes the shape of a structured report, where the following areas will be
affected by the gathering and analysis requirements:
An introduction stating the purpose and scope of the proposed system, listing any supporting
documents, specifying definitions and a glossary of terms, identifying the requirements, open
issues and assumptions, and identifying the client, customer and other stakeholders
An overview of the existing and the proposed new system outlining its mission, any constraints
revealed, and method of transition between the two
A document change record listing formal (ISO if certified) documents that will need to be
changed as a result of the analysis
A proposal of functional requirements (those sets of inputs, logic, and outputs) describing what
the new system must do (logic/behavioural), the data that is generated/manipulated by the
behaviour (data requirements), and how the user will interact with the system (user requirements)
A proposal of non-functional requirements describing those properties common across all
systems: usability, performance, security, legal, and operational.
Methods of data collection for requirements
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. As a whole,
these methods ensure a full study of requirements from multiple angles. A business analyst with a
systems analysis skill set is generally the type of person responsible for the data collection.
From an ethics perspective, you should be aware there are ethical issues regarding the gathering or
eliciting of information whether by interview, questionnaires, observation, or other means. Individuals
should be told if their input will be attributed to them or not. If the latter, efforts should be made to
remove identifying information from any reports or presentations.
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 often 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?" or "Are there any problems you have with how you do that
now?" the analyst can answer the overall question much more completely and effectively.
Interviewers also struggle with differentiating between tacit and explicit knowledge. Explicit or formal
knowledge they can witness through observation, and through indirect questions. Tacit knowledge,
however, is much more subtle and difficult to verbalize or write. It is more the experiential element that
becomes felt as a sense rather than a rule. Both forms of knowledge are essential to understanding a
persons job function.
Questionnaires
Questionnaires are useful for gathering strict and 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 reduced. Some web-based companies (such as surveymonkey.com, fluidsurveys.com, and
limesurvey.org) provide opportunities to web-enable questionnaires, all designed and presented through
a browser. Surveys can be embedded into websites, Facebook, blogs, e-mail free for a limited question
survey, but registration and fees may apply for more detailed questionnaires and response analysis.
Observation
Observation of users engaged in their work tasks is an important supplement to interviews and
questionnaires. Lean-based organizations use a Japanese term, genchi genbutsu, which means go see
for yourself, as a description of their insistence on observation. Often, when asked to explain parts of
their jobs, even with good questioning, users miss items. 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 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. Many opportunities are available today to convert
both internal and external documents (through scanning), into searchable text. This can assist greatly in
the document review process.
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. As
opposed to the individual interviewing technique described above, JAD attempts to accelerate the data
gathering through team-dynamics and consensus. Teams usually consist of eight 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. The difficulty of this method is actually bringing a team of eight to 10 people
together not just once but for a series of sessions.
4.3 Process modelling: Data flow diagrams
Learning objectives
Justify process modelling. (Level 1)
Design 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. They
show how a system fits together by linking the activities with the movement of data throughout a
process. Process models are the first element in the requirements-structuring process. They can take a
lot of work to develop, and the extent of their usefulness must be weighed against the time it takes to
create them. However, you can draw process models many ways. If your organization had taken part in
process re-engineering then you may already have access to completed process models. Or an
engineering team may have done them as part of a Six-Sigma exercise or part of lean value-stream
mapping.
One of the most common ways of documenting processes is using data flow diagrams (DFDs). Data flow
diagrams (DFDs) are process maps that show how information transfers between various compartments
of a system. DFDs are often used when designing a project plan because they are easily understood
visual aids for all members of a project team. Little training is required to understand them. 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. DFD can be created by hand, or a
number of software applications such as Microsoft Visio, SmartDraw, or Graphviz (open source), which all
have DFD stencils from which to build diagram elements.
DFDs are intended to represent the current system by creating a model which helps team members and
system analysts understand how processes work. Often analysts get into trouble developing systems by
assuming they know how the system should work, without bothering to reference the DFDs for
verification of how the system actually works.
Sets of data flow diagrams
DFDs are typically 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 and data stores.
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.
Example 4.3-1: Online Book Order System
This example is a simple description of receiving, processing, and storing a customer order. 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. In this example we show the top two levels of a
DFD: the context diagram, which shows the system boundaries, external entities, and main information
flows, and the level 0 diagram, which illustrates the major processes, data flows, and data stores. DFDs
are built in layers; as the level number of the DFD increases, the detail (level of abstraction) also
increases.
NewUsedBooks.com is a fictional online retailer that takes customer orders through its website.
Customers first search and select the books they want, and then complete an online form with their
shipping and payment details. NewUsedBooks.com is interested in modelling the order process from
order receipt, so that it can understand where to make improvements in its system.
Exhibit 4.3-1 shows the context data flow diagram for this online book order system. For the purposes of
this exercise, Microsoft Visio with the DFD stencil has been used.
Exhibit 4.3-1: Context flow diagram

One external entity is shown in the book order system, represented by the Customer rectangle (on the
left). Customers provide information to the system in the form of an order. They receive information from
the system in the form of a receipt, confirming an order received and a payment processed.
The system completes one main process Order System. This process (1.0) indicates where orders are
received and where documents to evaluate the order process are determined.
There are three data stores in the example: Customer, Inventory and Transaction. These are tables
within a single relational Order database. Data stores are shown in Exhibit 4.3-1 as open-ended
rectangles.
Data flows
Data flows are shown as arrows connecting the entities to the process to the data stores and vice-versa.
DFDs show the flows of data/information, rather than physical items.
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. In order for the order request to get into a pending order 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. 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. Customers do not simultaneously
group and place orders from different companies. However, the details of these information flows are
outside the scope of the context and level 0 diagrams, and are not depicted in this DFD example.
Purpose of the level 0 diagram
When more description of the process is required, the level 0 diagram is the next level down in the DFD
set. All the original connections showing the flow in the context diagram must be maintained. The level 0
diagram expands the boundaries of the context diagram, and shows all the main processes, data flows
and data stores. Exhibit 4.3-2 shows the level 0 data flow diagram for the online book order system.
Exhibit 4.3-2: Level 0 diagram

The CUSTOMER external entity still places the order at the beginning of the process, but now receives
confirmation of the order through a receipt, generated through the acceptance of the transaction. Notice
that the actual shipping of the order to the customer is not detailed in the level 0 diagram; that would be
expanded in the next level 1 diagram.
An order received must be processed twice:
the receipt of the order (which verifies the customer status with the company from the CUSTOMER
data store), which flows into the shipping of the books triggering an update of the inventory
record in the INVENTORY data store for the book shipped; and
an accounting transaction in the TRANSACTION data store, which triggers the generation of the
receipt.
The detail expressed in the level 0 diagram helps developers further understand the dynamics of the
system. Then they can explore ways to simplify or reduce the number of steps in the order process,
hopefully turning an easier customer experience into repeat business.
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-3 summarizes the rules for data flow diagrams.
Exhibit 4.3-3: Data flow diagram rules
Symbols
External entity
Closed rectangle
Process
Oval, rounded rectangle or square
Data store
Open-ended rectangle
Data flow Arrow
Naming conventions
External entity Noun (for example, Customer, Supplier)
Process Verb (for example, Receive Application, Determine Rate), except in
the context diagram where the system name a noun is used
Data store Noun (for example, Customer Listing, Back-ordered Product)
Data flow Noun (for example, Application Request)
Rules
Process Every process must have at least one input and one output.
Data flow Every data flow must be connected to at least one process.
Every flow must be in a single direction (no double-headed arrows).
Logical and physical data in flow diagrams
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 only what the element does. In a physical DFD, the names
refer to the current implementation of that element (the how). In other words, a physical DFD is derived
from the logical DFD.
For example, the data flow order information could be considered a logical flow because it doesnt tell
you how the request is received. A screen designed where the customer completes the order 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, in a particular way. For data stores, the distinction between logical and physical versions
would involve noting the current storage location or method in the name. Therefore, a customer table in
MS Access is a physical data store because it provides current implementation details within a larger
order processing database.
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 non-IT 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;
to follow some fairly simple steps in constructing at least the first version, usually done by hand before
moving to software.
1. Identify the external entities involved in the system. These are often the easiest to identify
because they represent known people or organizations with which 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.
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. Compare this against the documentation from
requirements gathering to determine completeness, and then revise it 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.
Although our example of a DFD is a simple one, it illustrates the value of DFDs as part of the
requirements gathering process. Without a visual model of the current state of a system (computerized or
manual), it is almost impossible to determine how to improve it. Data flow diagrams are one such
modelling tool to identify existing business processes.
4.4 Data modelling: Entity relationship diagrams
Learning objectives
Identify the way entity relationship (ER) diagrams can be used in data modelling. (Level 1)
Design 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 business
process modelling (Topic 4.3) through the creation of DFDs. DFDs provide a framework from which a
series of structured tasks can be studied and evaluated as to their purpose, value, strategy, and position
in the value chain.
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 used in the system and how the
data are related not only to each other, but to the DFD model of the business process. The most
common tool used for data modelling is the entity relationship (ER) diagram.
An entity-relationship diagram is a visual picture of the structure of a database, including entities,
relationships and attributes. All entities, primary keys, foreign keys, artificial keys and secondary keys are
described in an ER diagram. The ER diagram often maps a database, and helps programmers understand
the connections between process and data flow. As mentioned, there are three element types in an ER
diagram: entities, attributes and relationships. Entities are the items on which people seek information,
attributes are the data pertaining to the entities and relationships give a structure to the information.
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 an ER diagram is and how to interpret one
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. For example, entities in an
online ordering context would include customers, books, order processes and order shipping.
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. Exhibit 4.4-1 shows an
entity relationship diagram for the online book order system (created using Microsoft Visio).
Exhibit 4.4-1: Entity relationship diagram

There are many software applications that can construct ER diagrams. Visio presents one method and
one stencil. The entities in this diagram are data tables: Customer, Order, Inventory and Process. The
attributes are the fields within each table. For example, the CUSTOMERID and PASSWORD are PK
(primary Key) fields in the Customer table, followed by FirstName, LastName, Email, Street, etc. The
relationships between entities are shown as the arrowed connectors.
This exhibit uses the DFD from the previous topic, which described the context level business process for
an online book order system. The ER diagram describes the relational database tables in the DFD, and
shows the tables (entities), attributes (fields), and the relationships (connectors) between them.
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. An ER diagram, as with all logical models, describes the "what"
rather than the "how" of the data in your system. They are condensed diagrams of complex data models.
They contain a lot of information, and there are some specific rules about how they should be drawn.
As a non-IT manager, you most likely do not have to draw many ER diagrams. However, it will be
important for you to work with IS staff to be able to read them, so that you understand whether they
correctly describe the data in your system, which generates reports and financial statements.
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. They may arise from a DFD, or through a more informal
method. 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, 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. As it does for DFDs, Microsoft Visio also has stencils for
building ER diagrams, including all the database (table, field, key) attributes necessary.
Example 4.4-1 : Grocery store DVD rental ER diagram
Example 4.4-1 describes the main entities for DVD rentals from a grocery store, and has an
accompanying ER diagram.
In many grocery stores, customers can still rent DVDs from vending machines. 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 grocery store DVD 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. If the requirements
can be modelled in different ways, and these differences have implications for what the system will
ultimately be able to do, then the 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. This is frustrating when youre
learning about ER diagrams, because there is a tendency to want "right answers." But ER diagrams are
meant to be abstract representations, not blueprints.
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
date of birth (to determine if a customer can rent restricted movies). An ID number would likely be
assigned by the grocery store for easier tracking of customers (for example a customer card number),
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 wants to see a movie starring 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. 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. Super Hit III, for example, is a new release, which means it might have 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 grocery store
decides, a year after the system is created, to change the rental period for new releases from two days to
three 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:

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.
4.5 Logic modelling: Structured English
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. This type of model
borrows from programming language to better describe activities in the data flow and entity relationship
diagrams.
Logic models focus on describing data-to-information transformations (the steps in a process) with
Structured English.
Structured English
Structured English is a modified form of English used to specify the logic of information processes. It uses
a subset of English consisting of action verbs and noun phrases, resembling a programming language
that it is more restrictive than natural English. It is written as a series of blocks, which use indents and
capitals to represent the logic specifications. Structured English is based on three basic constructs:
sequence, decision, and repetition. Terms such as IF, THEN, ELSE, DO, REPEAT UNTIL, and many more
are part of the Structured English construction. 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.
The following sequence of constructs is an example of how to annotate specific logic issues in
programming, using Structured English. As a non-IT manager you would not create these, but it does
help if you can understand and interpret them, especially when you see how the assumptions in these
calculations are responsible for many figures in financial statements.
For example, in the ER diagram in Topic 4.4, a calculation that determines the total amount must be
coded so that it can be returned to the customer. The following construct identifies the calculation in
Structured English, where price, taxes (HST at 13%), and total amount are structured.
Calculate TOTALAMT using the formulas
PRICE = ORDERCOST + SHIPCOST
HSTRATE = 0.13
HST = PRICE HSTRATE
TOTAL_AMT = PRICE + GST + QST
The name chosen to represent each variable is not important. For example, HST could just as easily be
called TAX1. 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.
Websites such as Wikipedia provide a list of common keywords for Structured English.
1

Decision construct
The decision construct, also known as the selection construct, permits these two formats to specify
branches to the sequence of instructions above:
if-then-else format
case format
If-then-else format
The if-then-else construct is the most common. It provides a binary selection: if true do this, else do that.
For example, the following decision construct calculates the selling price for two types of merchandise. If
the SHIPTYPE is STANDARD, then the SHIPCOST is 4.50. If the SHIPTYPE is other than STANDARD, the
SHIPCOST is 14.50.
If SHIPTYPE = STANDARD
then: SHIPCOST = 4.50
else: SHIPCOST = 14.50
Case format
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 SHIPTYPE code.
Select the appropriate case:
Case 1: SHIPTYPE = STANDARD
Calculate SHIPCOST using
SHIPCOST = 4.50
Case 2: SHIPTYPE = EXPRESS
Calculate SHIPCOST using
SHIPCOST = 14.50
Case 3: SHIPTYPE = OVERNIGHT
Calculate SHIPCOST using
SHIPCOST = 18.50
Case 4: SHIPTYPE = PICKUP
Calculate SHIPCOST using
SHIPCOST = 0
These examples represent common uses of Structured English in programming logic models. The values
used are arbitrary for the purposes of the examples. However, in reality, values would likely be held in
databases that interface with the programs.
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 policy calculations where a set of rules is used to describe each possible combination of events.
A decision table is a matrix-like representation of the logic of a decision, which lists the possible
conditions for the decision and the resulting actions.
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.
Exhibit 4.5-1: Decision table for determining order discounts

If the ORDERTYPE is C (corporate), and the ORDERQTY is 1-2 books, then a 5% DISCOUNT is applied,
whereas an ORDERTYPE of I (individual) does not receive a 5% discount for 1-2 books, but for 3-5
books. The same decision logic applies to the other ORDERQTY conditions and DISCOUNT rules.

1
Structured English, http://en.wikipedia.org/wiki/Structured_English, accessed on February 26, 2013.
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 (process modelling, data modelling, and logic modelling) were
developed as part of the structured analysis method for systems design. This is a document-based
approach to systems design that generally has a strict adherence to the waterfall method of systems
analysis. The main issue with this approach is time and resources. The level of documentation in the
structured analysis method is overwhelming for many small to medium-sized enterprises (SMEs), who
have limited budgets and timeframes. Often the bare minimum of documentation is created, and system
analysts and programmers are required to do a fair amount of interpretation in the design phase instead
of relying on well-described requirements. However, even large organizations have struggled with the
level of documentation specified in a structured analysis method.
Many organizations pursue an alternative approach the object-oriented approach to systems
development. In object-oriented systems, both 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, and presenting it in a way that clearly
represents the requirements of the system from a users perspective. Often, structured tools are used
even when using an object-oriented approach. They are quick, easy and illustrative. We neednt create an
artificial barrier to their use.
The object-oriented (OO) approach to systems development
The object-oriented approach begins with the specification of important events in the application, and
lays out use cases for each event. These are descriptions of the specific activities that are 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 case diagrams represent a more behavioural model of a system than the three modelling methods
previously described.
They are informal and less technical than more traditional structured modelling. A use case is basically a
narrative of a business process; it is the primary form for gathering usage requirements for a new
software program or task to be done. 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 for example, a customer placing an order with an online bookstore. The use case describes
these events from the point of view of a single user or role for example, the customer interaction with
the screen (program) while ordering a book online. 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, but the most common method today is as a UML
use case.
Exhibit 4.6-1: Customer placing online order

Extending the scenario used through Topics 4.2 onward, the customer creates an online account at the
online bookstore and searches for books. The customer then places an order (in the Online Shopping
System), which triggers a check of the inventory (in the Order Fulfillment System), a verification of his or
her credit (by a financial credit officer), and then the creation of a system order. The system order is
assigned for fulfillment, and an order picker assigned to the order. The order is picked, packaged, and
shipped to the customer.
Although generic in its design, this use case diagram demonstrates the story element of the system in
object oriented development.
UML in system modelling
Unified modelling language (UML) is a set of modelling diagrams used in object-oriented languages to
specify, visualize, modify, construct and document the software architecture of systems. UML consists of
the following nine modelling diagrams:
Use case diagrams
Class diagrams
Object diagrams
Sequence diagrams
Collaboration diagrams
State chart diagrams
Activity diagrams
Component diagrams
Deployment diagrams
Although these diagrams, excluding use case diagrams, tend to be high-level for software development,
they represent a documentation and code execution method for object-oriented language developers.
Products such as IBMs Rational Rose, allow developers to visualize data designs and evolve them into an
applications specific logic. As a developer progresses through the UML modelling diagrams, the system
becomes more defined, and helps the developer to see the components of the system layered through
the various UML diagrams.
For non-IT managers, UML and its associated development environments represent a way to model and
prove the software components of newly designed systems, as part of the development process before
the systems go live. Developers coding systems in Java, Unix or Microsofts Visual Studio can use IBMs
Rational Rose developer software to assist in the UML modeling of systems development in these
platforms.
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 (which represents the second phase of the SDLC) 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, and a trade-off between all
three. The system decision must also be based on the feasibility of a justifiable business case and not
through a series of requirements. Functionality must be tied to solving a particular business or strategic
goal and not simply be a better system because it checks off more user requirements.
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. Since SaaS and
IaaS have become acceptable platform alternatives, organizations have a choice as to whether they have
the hardware/software installed and maintained centrally by IT, a SaaS model based off-site and licensed
through the vendor, or data stored off-site through an IaaS model. There are pros and cons to all three
solutions, and they must each be examined for cost, expertise, security, and sustainability.
Method of acquisition
The method of acquisition focuses on who is going to do the work. Will development be done in-house,
or by consultants hired for this system? Will an existing system be acquired and, if necessary,
customized? Or is SaaS or IaaS subscription the direction to follow? This decision was the focus of Topic
3.3. Ideally, the decision about whether to make, buy or subscribe to a system is made at this point,
once the analysis phase is complete.
System design activities
There are other activities to perform during the system design phase, most of which are developer tasks.
These may be discussed with the project team, but are often the domain of information systems, based
upon the information and models detailed after the requirements phase:
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 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 because it represents the data model
alone. 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 should emerge through 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 non-IT manager, you are
unlikely to participate directly in these technical activities, as they are usually left to the IS management
team. Many organizations are already standardized with a given relational database management system,
such as Microsoft SQL Server or Oracle.
Program design
Any large system contains multiple modules that make up its overall functionality. Each module
implements part of the functionality of the system, easily integrated to form an enterprise whole. 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. Still, design has
so many considerations today.
Organizations are exploring new ways of designing applications that were not available a decade ago.
Web services are an integral part of application development today, whereby many applications are
converted to web-applications through the creation or licensing of web services (such as Amazon Web
Services).
Program design used to be for single platforms. The basic web service platform is XML (extensible mark-
up language) and HTTP (hyper-text transport protocol), but organizations must understand many other
platform elements to take advantage of todays program design options. Today programmers must
consider multiple platforms the many versions of Windows, Linux, MAC OSX, as well as smartphone
platforms, tablets, and integration with the web. System design is an extremely complex task.
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 was designed and implemented. 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, screens, and buttons) 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. This will create problems later in terms of data integrity and usefulness.
The user-interface design for enterprise system modules is critical to system design, but so is web design.
Improper web design can lose customers, impact sales, and negatively affect the reputations of
organizations. It is important for non-IT managers to be aware of all design considerations, regardless of
platform, so that a perspective on the whole business persona both from internal and external
customers can be assessed and weighed against the costs of such designs.
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 itself, 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 and
consolidating data over a measureable timeframe, with little cognitive processing on the part of the user.
User considerations in interface design
One consideration in effective interface design 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. Furthermore, some 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 the specific users of the system. 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
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 still 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. Some of these are related to budget and resources; others are related to
competition and market. However, a new customer tracking system represents a project with a significant
investment regardless of organization size. Here, though, are some of the considerations:
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. The complex nature of IS means that a single person
cannot be a resource in all aspects. Smaller firms often look outside the organization for expertise
to guide them.
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. Where to invest capital in order to get
the best return is always a discussion point in companies, but more so when you may only afford
one investment per year.
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. New software
developments such as SaaS, PaaS, IaaS and cloud, are giving smaller firms access to the same
enterprise solutions as large organizations. When infrastructure and support for software suites is
handled outside the organization, a lot of opportunities emerge beyond the initial cost savings.
Infrastructure through cloud computing lets smaller companies use the web for backups, and
rather than invest in IT skill and servers, use tools like edge computing to handle web server
demands, or utility computing to assist with processing demands.
Each of these differences influences the systems analysis and design process. Decisions for smaller firms
are no longer based around doing it all alone. SalesForce, Microsoft, Oracle, Intuit and others all provide
SaaS solutions for customers, big and small.
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 a system may not be resident in the firm. The SaaS
model 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, but may not be strategic over a
longer time frame. 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 generally less
complex.
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,
and 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 the 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. When working with a contract
programmer, often the onus is on them to make sure that they understand the detailed requirements
before the coding begins.
Many companies today balance system projects between the traditional SDLC approach and a more agile
approach. Where the solution is clearly process-based and predictable, an SDLC method is generally
used. However, when the solution requires adaptability either because of response time or changing
requirements throughout the development process, then an agile approach is more often used. SDLC, as
a process-based approach, often relies on many of the modelling diagrams discussed in topics 4.2-4.6.
The agile approach is less formal, using hand-drawn models, and user stories instead of use case
diagrams. The end result for both is the same: a robust, working software solution.
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
As a CGA, you may be working for an accounting firm that contracts your professional business services
to assist companies in a variety of situations. With both accounting and IS knowledge, you could find
yourself helping an organization through the system analysis and design phases of a large software
project.
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" in the Reference library under the Resources tab; also
available in ERH, Unit C3.)
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.
Many organizations have external consultants sign non-disclosure agreements (NDA) or confidentiality
agreements (CA) as a safeguard against such events. This way, the consultant agrees to abide by the
rules of the company to which he or she is contracted, and acknowledges that information learned and
shared in the process of doing work is the ownership of the company, and not the consultant. There can
still be grey areas, but in the technology sector, NDAs are a common practice.
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. As a consultant, you
build experience working with various organizations. What you dont build is a repertory of trade secrets.
In other words, a distinction must be made between what legitimately belongs to the employee and what
the employee illegitimately takes from the employer. To make such a distinction, it is important to turn to
ethics.
Example 4.9-1: The Right Stuff -Lesley
This scenario provides an illustration of ethical issues in a corporate setting that allows you to exercise
your judgment.
Please note that this example refers to the CGA Code of Ethical Principles and Rules of Conduct Rule of
Conduct R205, which has been revised to Rule of Conduct R203 in the current version.
Organizational abuse
The discussion below refers to the nine-step approach to case analysis discussed in Unit A9 of the Ethics
Readings Handbook (ERH).
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 A9 of the Ethics Readings Handbook. The seventh
step in that process, Analyze and evaluate the alternatives, 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 seventh step of the nine-step approach to case analysis, 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 A5 of the ERH.
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 unless there is a clearly
announced policy that specific activities of employees (such as computer use) will be monitored. 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 if an employee brought in full requirements and design specifications from a
similar project she managed in a previous company? Or what if a developer pulled software from an
illegal torrent site on the Internet, and used that software in the development of the new system? What if
you discovered that an IT manager was buying stolen hardware at cut-rate prices, to deploy in the new
system? 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. If you find ethically questionable actions on the part of another CGA, you are first
expected to submit your criticism to the other CGA for an explanation (CEPROC R 105) and then, if
appropriate, to the professional association (R 104).
Module 4 self-test
1. You have been hired to conduct a requirements analysis for the development of a new student
information system for the CGA program. Your internal contact, the Director of Student Services,
has asked you to outline a plan for gathering system requirements for this system. Present your
response in good form and ensure that you address the following three questions:
What kind of information do you need to gather?
What sources of information and/or forms of information gathering would you use?
What are the key challenges in gathering information for this system?

Solution
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. What are the external entities (such as sources) relevant to this system?
b. What are the inputs and outputs of the system?
c. What are the internal processes of the system?

Solution
3. As a systems analyst working on contract for the Ministry of Education, you have been gathering
information about the requirements for a new system. The purpose of the system is to track
student scores on provincial tests administered by the Ministry. The stated purpose of standardized
testing in the province, and thus the goal of the system, is to provide feedback to the students and
aggregate reporting of scores by school district.

In the course of gathering requirements, several requests have been made to improve the system
by integrating it with other related databases. One analyst suggested linking the data with
provincial health records to allow for analysis of health and wellness influences on school
performance. Another suggested linking it with the university applications facility, so that
standardized test score data could form part of the university admission decisions. Adding these
links would be fairly simple technically and would not add substantially to the cost of the project.
Identify and explain any ethical issues you see with these requests.
Solution
4. Define information requirements and explain why they are difficult to determine correctly.

Source: Kenneth C. Laudon, Jane P. Laudon, and Mary Elizabeth Brabston, Management
Information Systems: Managing the Digital Firm, Fifth Canadian Edition (Toronto: Pearson Canada,
2011), page 305. Reproduced with permission from Pearson Canada.

Solution
Module 4 self-test solution
Question 1 solution
You will need to gather information about the data that are maintained in the system, the processes the
system undertakes (functions), and the logic of how processes are performed (these are the three kinds
of modelling done in the analysis phase: data, process, and logic modelling).
You should be able to identify a broad cross-section of stakeholders from whom you need to gather
information (students, lecturers, markers, tutors, CGA staff, potential employers, and so on).
You will need to gather information from users of the system, from users of the information, and from
the other key stakeholders (this relates to the purpose of the system).
Information could be gathered through questionnaires, interviews, observation, and document review.
These four methods should all be mentioned, with some reasons why each would or would not be used.
In general, all would be used for this system.
The key challenges are
Multiple stakeholders open up the possibility for differing views about what the system should do.
This is particularly true because all the stakeholder classes are widely spread geographically.
Questionnaires/Interviews: People dont always know what they need or are not always able to
articulate how they do things; therefore a key challenge is to really understand what is going on.
This is why we need multiple information sources and why observation and document review in
particular are valuable.
Absence of good documentation on the existing system is possible.
Module 4 self-test solution
Question 2 solution
a. The external entities relevant to this system are suppliers and the purchasing department.
b. The inputs and outputs of the system are
Inputs: copy of purchase order, packing slip
Outputs: receiver, purchase order copy, packing slip, and rejection letter

The internal processes of the system are:
Receive and sort purchase orders.
Receive packing slip and match to purchase order.
Check goods.
Prepare rejection letter.
Prepare receiver.
Update inventory file.
Re-file purchase order and packing slip for incomplete/non-matching shipments.
Send PO, PS, and receiver to purchasing.
Module 4 self-test solution
Question 3 solution
Both requests have merit, but both raise ethical issues. The link to health data would allow for detailed
research on health and education to be conducted, which could have long-term implications for both
sectors. On the other hand, the request is quite vague and so the benefits are not very clear. The link to
university admissions would be very useful for universities and might allow for fairer admissions
processes by allowing for decisions based on standardized tests. The primary ethical problem is that of
privacy individuals (students) provide test data for a specific stated purpose (feedback, aggregate
reporting). To begin to use that data for other purposes constitutes a breach of privacy. Also, the link to
health data potentially makes available very private information and thus it would be important to ensure
any identifying information was removed from the records, so that appropriate data stewardship involving
highly restricted access to identifying information, as well as strong encryption practices, are in place. In
this case, you would simply be comparing anonymous health records with anonymous school records.
This would mitigate the privacy concerns somewhat.
It is also important to know that the Personal Information Protection and Electronic Documents Act
(PIPEDA) does not support the linking of these separate databases without clear approval from users and
without a clear indication of what the data would be used for. Because linking databases may, in the
future, provide valuable information, is not a valid or acceptable reason.
Thus, any decision about whether to provide these features would require greater consultation with
stakeholders (parents, teachers, students) and careful attention to the privacy rights of those affected.
Consent that is given to collect data for one purpose does not automatically apply to other situations.
Module 4 self-test solution
Question 4 solution
Information requirements involve identifying who needs what information, where, when, and how. They
define the objectives of the new or modified system and contain a detailed description of the functions
the new system must perform. Gathering information requirements is perhaps the most difficult task of
the systems analyst, and faulty requirements analysis is a leading cause of systems failure and high
systems development costs. Some problems require adjustments in management, additional training, or
refinement of existing organizational procedures, rather than an IS solution.
Source: Adapted from Dale Foster, Instructors Manual to accompany Management Information Systems:
Managing the Digital Firm, Fifth Canadian edition, Pearson Canada, 2011, Chapter 9, page 343.
Reproduced with the permission of Pearson Canada.
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.
Evaluate the steps in developing a system in particular, the phases of analysis and design.
The systems analysis phase includes three main activities:
o gathering requirements
o structuring requirements
o 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
o files and databases
o programs
o network
o user interfaces
o 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:
o What is the system supposed to do and what are the business processes that are occurring?
o What kind of information or data is required by the system and what kind of information or
data is produced by the system?
o 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.
Justify process modelling.
Process modelling is used to document the activities or processes of a system.
In information systems, it is about modelling the flow of information through 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 of the system.
Design 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 diagram and compare them to the existing documentation of the system.
6. Walk through the DFD with the analysts and users to confirm the accuracy.
Identify 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, but they identify the structure of the data
from tables to fields.
Design a simple entity relationship diagram.
An ER diagram typically consists of three components:
o a representation of two or more entities
o arrows that represent the relationship between entities
o a description of the attributes of the entities
Starting with a description of the process or system, you identify the entities that are required and
then use attributes to describe each entity.
Based on the rules of the system, you can establish the relationships between the various entities.
Represent processing flow using Structured English.
Structured English defines the logic between the system and its data.
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.
o The if-then-else construct is the most common; it provides a binary selection.
o 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:
o The do-while construct follows a set of instructions if a condition is true. This is a zero-or-
more construct.
o The repeat-until construct: Repeat a set of instructions based on the value of a condition.
This is a one-or-more construct. The set of actions must be executed at least once.
Construct decision tables to document the processing logic of a set of procedures.
Decision tables are ideal for describing business policies where a set of rules is used to describe
each possible combination of events.
With structured English, decision tables define the logic of system choices.
A decision table consists of three parts:
o condition stub: a list of all the possible factors that affect the decision. This is shown in the
first rows of the decision table.
o 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.
o 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:
1. Identify the conditions and values.
2. Determine the maximum number of decision rules.
3. Identify possible actions to be taken for each decision or policy.
4. Enter in all possible rules.
5. Form a possible decision rule for each unique combination of conditions.
6. Define the actions for each rule.
7. Simplify the decision table; if the outcomes dont differ at each level, then one rule can
encompass them all.
Design a simple use case to support systems design.
Use cases describe the important "events" in an information system (the activities in the business
processes that require the system to take some action). Each use case is described using the
following elements:
o Basic descriptive information: name, description, number, and so on
o Trigger: the event or timing that initiates the process
o Inputs and outputs: sources and destinations of information
o Details: the steps required to complete the process, information needed, and the direction
of information flows
Analyze the primary decisions and activities in the systems design phase.
A design strategy includes three main decisions:
o System functionality. How much functionality needs to be built into the system based upon
factors such as cost, risk, and complexity?
o 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.
o Method of acquisition. Who will do the work? This is the make versus buy decision.
Systems design phase activities:
o File and database design: turning the conceptual data model into a specific database format
(for example, hierarchical, network, or relational database)
o Program design: determining the system modules that need to be created and the linkages
between them
o Network design: deciding on how multi-user systems will be implemented (distribution of
processing tasks and data)
o User interface design: designing screens and reports for the system (the inputs and
outputs)
o Design of internal controls: determining how best to secure the system against intentional
or unintentional threats
Evaluate and discuss user interface in terms of design.
User interface design is critical, because the interface is how users interact with the system. The
effectiveness of the system will be indicated by how easily users can accomplish their tasks.
Effective design aims to decrease the cognitive load on the user. This rule explains the myriad
suggestions that are given on all aspects of design (such as menu consistency, choice of tables
and graphs, use of colour, and so on).
Differentiate between the systems analysis and design phases of small and large projects.
Smaller firms have fewer IS staff and fewer resources for systems development.
Smaller firms have more challenges around user capabilities and information systems.
Smaller firms have fewer financial resources, making the financial risks greater.
Smaller firms often contract out IS services on an as needed basis.
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? You should decide if the unethical
behavior is work-related. If it is, then it should be reported to the employer.