CHAPTER THREE

SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES

Introduction
Documentation encompasses the narratives (written descriptions), flowcharts, diagrams, and other
written materials that explain how a system works. This information covers who, what, when, where,
why, and how of data entry, processing, storage, information output, and system controls.
Popular means of documenting a system include diagrams, flowcharts, tables, and other graphical
representations of information. These are supplemented by a narrative description of the system, a
written step-by-step explanation of system components and interactions.
How do accountants use documentation?
 At a minimum, they have to read documentation to understand how a system works.

 They may need to evaluate the strengths and weaknesses of an entity’s internal controls.

• Requires heavy reliance on documentation.

 They may peruse documentation to determine if a proposed system meets the needs of its users.

 They may prepare documentation to:

• Demonstrate how a proposed system would work

• Demonstrate their understanding of a system of internal controls
In this chapter, we discuss two of the most common documentation tools:
1. Data flow diagrams (DFD), a graphical description of the sources and destinations of data that
shows data flow within an organization, the processes performed on the data, and how data are
stored. They show:
 Where data comes from

 How it flows

 The processes performed on it

 Where it goes

2. Flowcharts
Include three types:
a. Document flowchart, a graphical description of the flow of documents and information
between departments or areas of responsibility within an organization.
b. System flowchart, a graphical description of the relationship among the input, processing,
and output in an information system.
c. Program flowchart, a graphical description of the sequence of logical operations that a
computer performs as it executes a program.

Compiled by Benol.M Page 1

 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES
Documentation techniques are necessary tools for accountants:
 Statements on Auditing Standards (SAS) 94, ― The effect of information technology on
the auditor`s consideration of internal control in a financial statement audit,‖ requires that
independent auditors understand the automated and manual internal control procedures an
entity uses. This understanding can be gleaned through documenting the internal control
system—a process that effectively exposes strengths and weaknesses of the system.
 SOX (2002) effectively require that publicly-traded corporations and their auditors
document and test the company’s internal controls.
 Auditing Standard No. 2 promulgated by the PCAOB requires that the external auditor
express an opinion on the clients system of internal controls.
Documentation tools help accountants by:
 Organizing very complicated systems into a form that can be more readily understood
 Helping new team members understand a pre-existing system
DATA FLOW DIAGRAMS
A data flow diagram (DFD) graphically describes the flow of data within an organization. It is
used to document existing systems and to plan and design new ones. There is no black-and-white
approach to developing a DFD. i.e., there is no ideal way to develop a DFD, because different
problems call for different methods.
Elements in a Data Flow Diagram
A data flow diagram composed of four basic elements:
 Data sources and destinations
 Data flows
 Transformation processes and
 Data stores
Each is represented on a DFD by one of the symbols:
Symbol Name Explanation
Data sources and The people and organizations that send data to and receive
destinations data from the system are represented by square boxes. Data
destinations are also referred to as data sinks.
Data flows The flow of the data into or out of a process is represented by
curved or straight lines with arrows.
Transformation The processes that transform data from inputs to outputs are
Processes represented by circles. They are often referred to as bubbles.
Data stores The storage of data is represented by two horizontal lines.

Compiled by Benol.M Page 2

 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES

These four symbols are combined to show how data are processed.
1. Data sources and destinations

A source or destination symbol on the DFD represents an organization or individual that sends or
receives data that the system uses or produces. Data sources and data destinations are represented
by squares.
An entity/item can be both a source and a destination
2. Data flows

 Appear as arrows
 Represent the flow of data between sources and destinations, processes, and data stores.
3. Processes

 Appear as circles

 Represent the transformation of data

4. Data stores

 Appear as two horizontal lines

 Represent a temporary or permanent repository of data. DFDs do not show the physical
storage medium (such as disks and paper) used to store the data. As with the other DFDs
elements, data store names should be descriptive.
Subdividing the DFD
DFDs are subdivided into successively lower levels to provide increasing amounts of detail,
because few systems can be fully diagrammed on one sheet of paper. Users have needs, so a
variety of levels can better satisfy these requirements.
The highest level DFD is called a context diagram. A context diagram provides the reader with a
summary-level view of the system. It depicts a data processing system and the external entities that
are: the sources and destinations of the system`s inputs and outputs.
Guidelines for Drawing a DFD

• RULE 1: Understand the system: To understand how the system works, observe the flow of
information through an organization and interview the individuals who use and process the data.
• RULE 2: Ignore control processes and control actions (e.g., error corrections). Only very critical
error paths should be included.

Compiled by Benol.M Page 3

 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES
• RULE 3: Determine the system boundaries where it starts and stops. If you’re not sure about
a process, include it for the time being.
• RULE 4: Draw the context diagram first, and then draw successively greater levels of detail.
• RULE 5: Identify and label all data flows. The only ones that do not have to be labeled are those
that go into or come out of data stores.
• RULE 6: Data flows that always flow together should be grouped together. Those that do not
flow together should be shown on separate lines.
• RULE 7: Show a process (circle) wherever a data flow is converted from one form to another.
Likewise, every process should have at least one incoming data flow and at least one outgoing
data flow.
• RULE 8: Transformation processes that are logically related or occur simultaneously can be
grouped in one bubble.
• RULE 9: Number each process sequentially. A process labeled 5.0 would be exploded at the next
level into processes numbered 5.1, 5.2, etc. A process labeled 5.2 would be exploded into 5.21,
5.22, etc.
• RULE 10: Process names should include action verbs, such as update, prepare, etc.
• RULE 11: Identify all files and data stores: Data are stored temporarily or permanently in most
systems. Each data repository, and each data flow into and out of it, should be identified.
• RULE 12: Identify and label all sources and destinations. An entity can be both a source and
destination. You may wish to include such items twice on the diagram, if needed, to avoid
excessive or crossing lines.
• RULE 13: As much as possible, organize the flow from top to bottom and left to right.
• RULE 14: You’re not likely to get it beautiful the first time, so plan to go through several
iterations of refinements.
• RULE 15: Prepare a final copy: Draw a final copy of the DFD. Do not allow data flow lines to
cross over each other; if necessary, repeat a data store or destination. Place the name of the DFD,
the date prepared, and the preparer’s name on each page.
FLOWCHARTS
A flowchart is an analytical technique that describes some aspect of an information system in a clear,
concise, and logical manner.
A flowchart is a graphical representation of a system that describes the physical relationships between its
Compiled by Benol.M Page 4
 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES
key entities. Flowcharts can be used to represent manual activities, computer processing activities, or both.
Flowcharts use a set of standard symbols to depict processing procedures and the flow of data.
Flowchart Symbols
Every shape on a flowchart depicts a unique operation, input, processing activity, or storage medium.
In the days of yore, flowcharts were commonly drawn with flowcharting template, a piece of hard, flexible
plastic on which the shapes of symbols have been die cut. Most flowcharts are now drawn using a
software program such as Visio, a drawing package based on the green plastic flowchart templates.
Flowcharts can also be drawn using Microsoft Word, Excel, and Power Point. The software uses pre-
drawn shapes, and the developer drags the shapes into the drawing.
There are four types of flowcharting symbols:
(1) Input/output symbols: represent devices or media that provide input to or records output
from a processing operations.

Compiled by Benol.M Page 5

 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES

(2) Processing symbols: either show what type of device is used to process data or indicate when
processing is performed manually.

Compiled by Benol.M Page 6

 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES

(3) Storage symbols: represent the device used to store data that the system is not currently using.

(4) Flow and miscellaneous symbols: indicate the flow of data and goods. They also represent
such operations as where flowcharts begin or end, where decisions are made, and when to
add explanatory note to flowcharts.

Compiled by Benol.M Page 7

 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES

A, DOCUMENT FLOWCHARTS
A document flowchart illustrates the flow of documents and information among areas of responsibility
within an organization. A document flowchart is used to depict the elements of a manual system,
including accounting records (documents, journals, ledgers, and files), organizational departments
involved in the process, and activities (both clerical and physical) that are performed in the departments.
Document flowcharts trace a document from its cradle to its grave. They show where each document
originates, its distribution, the purpose for which it is used, its ultimate disposition, and everything that
happens as it flows through the system.
 Internal control flowcharts are document flowcharts used to evaluate the adequacy of
internal controls, such as segregation of duties or internal checks.
 They can reveal weaknesses or inefficiencies such as:
• Inadequate communication flows
• Unnecessarily complex document flows
• Procedures that cause wasteful delays
 Document flowcharts are also prepared in the system design process.
GUIDELINES FOR PREPARING FLOWCHARTS
 Let’s step through some guidelines for preparing flowcharts:
1. Understand a system before flowcharting it. Interview users, developers, auditors, and
management, or have them complete a questionnaire. Read through a narrative description of
the system, or walk through systems transactions.
2. Identify the entities to be flowcharted, such as departments, job functions, or external parties
(the parties who ― do‖ things in the story). Identify documents or information flows in the
system, as well as the activities or processes performed on the data.
Compiled by Benol.M Page 8
 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES
(For example, when reading a description of the system, the preparer could draw a box around
the entities, a circle around the documents, and a line under the activities.)
3. Use separate columns for the activity of each entity.
• Example: If there are three different departments or functions that ― do‖ things in
the narrative, there would be three columns on the flowchart.
4. Flowchart only the normal course of operations, and identify exceptions with
annotations.
5. As much as possible, the flow should go from top to bottom and left to right.
2. Use the standard flowcharting symbols, and draw them with a template or a computer.
3. Clearly label all symbols. Write a description of the input, process, or output inside the
symbol. If the description will not fit, use the annotation symbol. Print neatly, rather than
writing in cursive.
Use annotations if necessary to provide adequate explanation.
– Give the flowchart a clear beginning and ending.
– Show where each document originated and its final disposition.
– One approach you can use is to read through the narrative and for each step define:
– What was (were) the input(s)
– What process was carried out
– What was (were) the output(s)
– Note on the next slide that the flow sequence is input -- process – output.
– Every manual process should have at least one input and at least one output.
Show all data entered into or retrieved from a computer file as passing through a processing operation (a
computer program) first.
– Do not show process symbols for:
1. Forwarding a document to another entity
2. Filing a document
– Do not connect two documents except when forwarding to another column.
• When a document is forwarded, show it in both locations.
– When using multiple copies of a document, place document numbers in the upper,
right- hand corner.
– Show on-page connectors and label them clearly to avoid excess flow lines.
– Use off-page connectors if the flow goes to another page.

– If a flowchart takes more than one page, label the pages as 1 of 5, 2 of 5, 3 of 5, etc.
– Show documents or reports first in the column where they are
created. Start with a rough draft; then
18. Redesign the flowchart to avoid clutter and a large number of crossed lines.
19. Verify the flowchart`s accuracy by reviewing it with the people familiar with the system.
Be sure all uses of flowcharting conventions are consistent.
20. Draw a final copy of the flowchart. Place the name of the flowchart, the date, and the
preparer’ s name on each page of the final copy.

Compiled by Benol.M Page 9

 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES
B.SYSTEM FLOWCHARTS
System flowchart depicts the relationship among the inputs, processes, and outputs of an AIS. System
flowcharts portray the computer aspects of a system. They depict the relationships between input (source)
data, transaction files, computer programs, master files, and output reports produced by the system.

System flowcharts also describe the type of media being used in the system, such as magnetic tape,
magnetic disks, and terminals.
A system flowchart begins by identifying the inputs that enter the system and their origins. The input can
be new data entering the system, data stored for future use, or both. The input is followed by the
processing portion of the flowchart, i.e., the steps performed on the data. The logic the computer use(s) to
perform the processing task is shown a program flowchart. The resulting new information is the output
component, which can be stored for later use, displayed on a screen, or printed on paper. In many
instances, the output from one process is an input to another. In other words, it’ s the same basic input –
process – output pattern that we saw in the document flowchart.
System flowcharts are an important system analysis, design, and evaluation tool. They are universally
employed in systems work and provide an immediate form of communication among workers.
The system flowchart is an excellent vehicle for describing information flows and procedures within
AIS.
C. PROGRAM FLOWCHARTS
Program flowcharts illustrate the sequence of logical operations performed by a computer in executing a
program. A program flowchart describes the specific logic to perform a process shown on a system
flowchart. They also follow an input – process – output pattern. Once designed and approved, the
program flowchart serves as the blueprint for coding the computer program.
FLOWCHARTS versus DFDs
 Now that we’ve examined both flowcharts and DFDs, it may be useful to discuss the
differences again.
 DFDs place a heavy emphasis on the logical aspects of a system.

 Flowcharts place more emphasis on the physical characteristics of the system.

 An example may be useful.

For example, the registrar’s office of a small college receives paper enrollment forms from students. They
sort these records alphabetically and then update the student record file to show the new classes. They also
prepare class lists from the same data. The sorted enrollment forms are forwarded to the bursar’s office for
billing purposes. Class lists are mailed to faculty members.

Compiled by Benol.M Page 10

 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES
Here’s a DFD that goes with the story.

Here’s a flowchart that goes with the story

Introduction to Systems Development and Systems Analysis

Because we live in a highly competitive and ever-changing world, organizations continually face the need
for new, faster, and more reliable ways of obtaining information. To meet this need, an information
system must continually undergo changes, ranging from minor adjustments to major overhauls.
Occasionally, the needed changes are so drastic that the old system is scrapped and replaced by an
entirely new one.

Compiled by Benol.M Page 11

 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES
Companies change their systems for one of the following reasons:
 Changes in user or business needs: Increased competition, business growth or consolidation,
mergers and divestitures, new regulations, or changes in regional and global relationships can alter
an organization`s structure and purpose. To remain responsive to company needs, the system must
change as well.
 Technology changes (i.e., to take advantage of or respond to technology changes): As
technology advances and becomes less costly, an organization can make use of the new
capabilities or existing ones that were previously too expensive.
 Improved business processes (i.e., to accommodate improvements in their business
process):Many companies have inefficient business processes that require updating.
 Competitive advantage (i.e., to gain a competitive advantage and/or lower costs): Increased
quality, quantity, and speed of information can result in an improved product or service and may
help lower costs.
 Productivity gains (i.e., to increase productivity): Computers automate clerical and repetitive
tasks and significantly decrease the performance time of other tasks. Information systems can
also place specialized knowledge at the disposal of many company employees.
 To accommodate growth (Growth): Companies outgrow their systems and must either
upgrade or replace them entirely.
 Downsizing (i.e., to accommodate downsizing or distribute decision making): Companies
often move from centralized mainframes to net-worked PCs or to Internet-based systems to
place decision making and its corresponding information as far down the organizational chart
as possible.
 Systems integration (i.e., to integrate incompatible systems): Organizations often have many
adequate and serviceable systems that are incompatible—that is, they do not communicate well
with each other because they were developed over many years using different technologies and
data formats. These systems often are rewritten to remove the incompatibilities and consolidate
databases.
 Systems age and need to be replaced (i.e., to replace a system that is aged and unstable):
As systems age and are repaired numerous times, they become less stable and eventually need to
be replaced.

Compiled by Benol.M Page 12

 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES

Developing quality, error-free software is a difficult, expensive, and time-consuming task. In fact, it is
almost always the cases that software development projects deliver less than one expects and take more
time and money to develop than one expects. To make matters worse, most companies that want to
implement a new system want it immediately. As developers feel the pressure to perform system
miracles, they begin skipping systems development steps and just start writing code. Omitting basic
systems development steps only leads to disaster, as developers create well-structured systems that fail to
meet user needs or solve any of their business problems.
For example, a KPMG survey found that 35% of all major information systems projects were classified as
runaways hopelessly incomplete and over budget.
 Major cause of runaways: Skipping or skimping on systems development processes. Runaways can
consume a great deal of time and money and in the end produce no usable results.
Systems Development
Whether systems changes are major or minor, most companies go through a systems development life
cycle. The steps in that cycle and the people involved in systems development are discussed in this
section.
The Systems Development Life Cycle (SDLC)

The five stages in the systems development life cycle are:

1) System Analysis 4) Implementation and Conversation
2) Conceptual Design 5) Operations and Maintenance
3) Physical Design

Compiled by Benol.M Page 13

 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES

1) Systems analysis
As organizations grow and change, management and employees recognize the need for more or better
information and request a new or improved information system. The first step in systems development is
systems analysis. When a new or improved system is needed, a written request for systems
development is prepared. The request describes:
 The current system’s problems.
 The reasons for the proposed changes.
 The proposed systems goals and objectives, as well as its anticipated benefits and costs.

The project development team conducts the analysis. The five steps in system analysis phases include:
(1) Initial investigation: Involves gathering the information needed to buy/purchase or develop a new
system and determining whether it is a priority. An initial investigation is conducted to screen projects.
The person conducting an initial investigation must:
 Gain a clear picture of the problem or need

 Determine the projects viability and expected costs and payoffs

 Evaluate the project`s scope and nature of the new AIS

 Recommend whether the development project should be initiated as proposed,

modified, or abandoned.
During the initial investigation, the exact nature of the problem(s) under review must be
determined. In some instances, what is thought to the cause of the problem is not the real source. For
example, a government accountant once asked a consultant to develop an AIS to produce the information
he needed to fund expenditures and available funds. Further investigation showed that the agency`s system
already provided the information. The accountant simply did not understand the reports he was receiving.
The project`s scope (what it should and should not seek to accomplish) also must be determined. A
new AIS is useful when problems are a result of lack of information, inaccessibility of data, and inefficient
data processing. However, new AIS is not the answer to organizational problems, such as the controller
managing too many employees. Likewise, if a manager lacks organizational skills or if a failure to enforce
existing procedures causes control problems, new AIS is not the answer.
If a project is approved, a proposal to conduct system analysis is prepared. It is assigned a priority and
added to the master plan, and the development team begins the survey of the existing AIS. As the
investigation progresses, the proposal will be modified as more information becomes available.
(2) Systems survey: During the systems survey, an extensive study of the current AIS is undertaken. This
survey may take weeks or months, depending on the complexity and scope of the system. The objectives
of a systems survey are as follows:
Gain a thorough understanding of company operations, policies, and procedures; data and

Compiled by Benol.M Page 14

 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES
information flow; AIS strengths and weaknesses; and available hardware, software, and
personnel.
Make preliminary assessments of current and future processing needs, and determine the extent
and nature of changes needed.
Develop working relationships with users and build support for the AIS.
Collect data that identify user needs, conduct a feasibility analysis, and make recommendations
to management.
Data about the current AIS can be gathered internally from employees, as well as from documentation
such as organizational charts and procedures manuals. External sources include consultants, customers
and suppliers, industry associations, and government agencies.
Four common methods of gathering data are:
– Interviews
– Questionnaires
– Observation
– System documentation
(3) Feasibility study: Involves an in-depth study of the proposed system to determine whether it’s
feasible. At this point in systems analysis, a more thorough feasibility analysis is conducted to
determine the project`s viability. The feasibility analysis is updated regularly as the project proceeds
and costs and benefits become clearer.
A feasibility study (also called a business case) is prepared during the systems analysis and updated
as necessary during the remaining steps in the SDLC. The extent of these studies varies, depending
on the size and nature of the system. For example, the study for a large-scale system is generally
quite extensive, whereas one for a desktop system might be conducted informally. The
feasibility team should include management, accountants skilled in controls and auditing, systems
personnel, and users. At major decision points, the steering committee uses the study to decide
whether to terminate a project, proceed unconditionally, or proceed if specific problems are
resolved. Although a project can be terminated at any time, the early go/no-go decisions are
particularly important as each subsequent SDLC step requires more time and monetary
commitments. As the project proceeds, the study is updated and the project`s viability is reassessed.
The further along a development project is, the less likely it is to be canceled if a project
feasibility study has been prepared and updated.
Five important aspects to be considered during a feasibility study are as follows:
1) Economic feasibility: Will system benefits justify the time, money, and other resources
required to implement it? (i.e., Will the benefits exceed the costs?)
2) Technical feasibility: Can the planned system be developed and implemented using existing
technology? (i.e., Is the technology there to do it?)
3) Legal feasibility: Does the system comply with all applicable federal and state laws and
statutes, administrative agency regulations, and the company`s contractual obligations?
4) Scheduling feasibility: Can the system be developed and implemented in the time allotted? If
not, it will have to be modified, postponed, or replaced by an alternative selection.
5) Operational feasibility: Do the organization have access to people who can design,

Compiled by Benol.M Page 15

 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES
implement, and operate the proposed system? Can people use the system, and will they use it?
Economic feasibility is the most important and frequently analyzed of the five aspects.
(4) Information needs and systems requirements
Once a project is deemed feasible, the company identifies the information needs of AIS users and
documents systems requirements.
Systems objectives and constraints
Many organizations take a systems approach to determining information needs and systems requirements.
Problems and alternatives are viewed from the standpoint of the entire organization, rather than from any
single department or interest group.
It is important to determine system objectives so that analysts and users can focus on those elements most
vital to the AIS`s success, however, it is difficult for a system to satisfy every objective. For example,
designing adequate internal controls must be viewed as a trade-off between the objectives of economy
and reliability. Similarly, cutting clerical costs must balance the objectives of capacity, flexibility, and
customer service.
A system`s success often depends on the project team’ s ability to cope with constraints the organization
faces. Common constraints include governmental agency requirements, managerial policies and
guidelines, lack of sufficiently qualified staff, the capabilities and attitudes of system users, available
technology, and limited financial resources.
To maximize system performance, the effects of these constraints on system design must be minimized.
Strategies for Determining Requirements:
One or more of the following four strategies are used to determine AIS requirements:

1. Ask users what they need: Though this is the simplest and fastest strategy, many people do not
realize or understand their true needs. Although they may know how to do their jobs, they may not
be able to break them down into the individual information elements they use. It is sometimes better
to ask users questions pertaining to what decisions they make and what processes they are involved
in and then help them design systems to address their answers. Users must think beyond their current
information needs so that new systems do not simply replicate the current information in new and
improved formats.
2. Analyze existing systems: Both internal and external systems should be analyzed. A partial solution
may already exist, thus eliminating the problem of reinventing the wheel.
3. Examine existing system use: This strategy differs from the previous one by taking into account
that certain modules may not be used as intended, may be augmented by manual tasks, or may be
avoided altogether. This approach helps determine if a system can be modified or must be replaced.

Compiled by Benol.M Page 16

 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES
4. Create a model: When it is difficult to identify a usable set of requirements, a developer can quickly
rough out a system for users to critique. Once users see something on the screen, they can begin to
identify what they like and dislike and request changes. This iterative process of looking at what is
developed and then improving it continues until users agree on their needs.
Documentation and approval of user requirements
Detailed requirements for the new AIS that explain exactly what the system must produce should be
created and documented. How to produce the required features is determined during the design phases of
the SDLC. The requirements list should be supported by sample input and output forms, as well as charts,
to make it easier for readers to conceptualize the system. A nontechnical summary that captures important
user requirements and development efforts to date is often prepared for management.
When user requirements have been determined and documented, the project team meets with users,
explains the requirements, and obtains their agreement and approval. When an agreement is reached, user
management should sign the appropriate system requirements documents to indicate approval.

(5) Systems analysis report

System analysis is concluded by preparing a systems analysis report to summarize and document the
analysis activities and serve as a repository of data from which designers can draw. The reports show the
new system`s goals and objectives, the scope of the project and the new system, how the new system fits
into the company’s master plan, the user`s processing requirements and information needs, the feasibility
analysis, and recommendations for the new system. The project development team is responsible for
preparing a systems analysis report.
A go/no-go decision may be made up to three times during systems analysis:
 During the initial investigation, to determine whether to conduct a systems survey.
 At the end of the feasibility study, to determine whether to proceed to the information
requirements phase; and
 At the completions of the analysis phase, to decide whether to proceed to the next phase
(conceptual design).
After systems analysis is completed, the projects developed using the SDLC approach move to
the conceptual design phase and then to physical design, implementation and conversion, and
operation and maintenance.
2) Conceptual design
During conceptual design, the company decides how to meet user needs. The first task is to identify and
evaluate appropriate design alternatives. There are many different ways to obtain a new system,
including buying software, developing it in-house, or outsourcing system development someone else.
Detailed specifications outlining what the system is to accomplish and how it is to be controlled must
be developed. This phase is complete when conceptual design requirements are communicated to the
information systems steering committee.
3) Physical design

Compiled by Benol.M Page 17

 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES
During the physical systems design phase, the company determines how the conceptual AIS design is to
be implemented. Physical design translates the broad, user-oriented AIS requirements of conceptual
design into detailed specifications that are used by programmers to code and test the computer programs.
Input and output documents are designed, computer programs are written, files and databases are created,
procedures are developed, and controls are built into the new system. This phase is complete when
physical system design results are communicated to the information systems steering committee.

i. Output design: The objective of output design is to determine the nature, format, content, and timing
of printed reports, documents, and screen displays. Tailoring the output to user needs requires
cooperation between users and designers.
Outputs usually fit into one of the following four categories:
Scheduled reports: Have a pre-specified content and format and are prepared on a regular
basis. Examples include monthly performance reports, weekly sales analyses, and annual
financial statements.
Special-purpose analysis reports: Have no pre-specified content and format and are not on a
regular schedule. They are prepared in response to a management request to evaluate an issue,
such as which of three new products would provide the highest profits. Example: Analysis of
impact of a government mandate on profitability
Triggered exception reports: Have pre-specified content and format but are prepared only in
response to abnormal conditions. Excessive absenteeism, cost overruns, inventory shortages,
and situations requiring immediate corrective action trigger such reports.
Demand reports: Have a pre-specified content and format but are prepared only on request.
Both triggered exception reports and demand reports can be used effectively to facilitate the
management process.
ii. File and database design
iii. Input design
iv. Program design
v. Procedures design
vi. Controls design

4) Implementation and conversion

System implementation is the process of installing hardware and software and getting the AIS up and
running. This process generally consists of developing a plan, preparing the site, installing and testing
hardware and software, selecting and training personnel, completing the documentation, and testing the
system. Conversion is the process of changing from the old to the new AIS. Many elements must be
converted: hardware, software, data files, and procedures. The process is complete when the new AIS has
become a routine, ongoing part of the system.
Conversion Approaches
Four conversion approaches are used to change from an old to a new system:

Compiled by Benol.M Page 18

 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES
• Direct conversion
• Parallel conversion
• Phase-in conversion
• Pilot conversion

Direct conversion immediately terminates the old AIS when the new one is introduced. Direct
conversation is appropriate when the old AIS has no value or the new one is so different that comparisons
between the two are meaningless. The approach is inexpensive, but it provides no backup AIS. Unless a
system has been carefully developed and tested, therefore, direct conversation carries a high risk of
failure.

Parallel conversion operates the old and new systems simultaneously for a period of time.
– You can process transactions with both systems, compare output, reconcile differences, and make
corrections to the new AIS.
– Parallel processing protects the company from errors, but it is costly and stressful for employees to
process all transactions twice. However, because companies often experience problems during
conversion, parallel processing has gained widespread popularity.
Phase-in conversion gradually replaces elements of the old AIS with the new one.
– The new system is often phased in a module at a time.
These gradual changes mean that data processing resources can be acquired over time. The
disadvantages are the cost of creating the temporary interfaces between the old and the new AIS and
the time required to make the gradual changeover (complete conversion).
Pilot conversion implements a system in just one part of the organization, such as a branch office or a
single store. When problems with the system are resolved, the new system could be implemented at the
remaining locations. This approach localizes conversion problems and allows training in a live
environment. The disadvantages are the long conversion time and the need for interfaces between the old
and the new systems, which coexist until all locations have been converted.
Implementation and conversation constitute the capstone phase during which all the elements and
activities of the system come together. Because of the complexity and importance of this phase, an
implementation and conversion plan is developed and followed. As part of implementation, any new
hardware and software is installed and tested. New employees may need to be hired and trained, or
existing employees relocated. New processing procedures must be tested and perhaps modified. Standards
and controls for the new system must be established and system documentation completed. The
Compiled by Benol.M Page 19
 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES
organization must convert to the new system and dismantle the old one. After the system is up and
running, any fine-tuning adjustments needed are made and a post-implementation review is conducted to
detect and correct any design deficiencies. The final step in this phase is to deliver the operational system
to the organization, at which time the development of the new system is complete. A final report is
prepared and sent to the information systems steering committee.
5) Operation and maintenance
The final step in the SDLC is to operate and maintain the new system. Once the system is up and
running, operations and monitoring continue.
• Tasks include:
– Fine-tune/adjust and do post-implementation review.
– Operate the system.
– Periodically, review and modify the system.
– Do ongoing maintenance.
– Deliver improved system.
Eventually, a major modification or system replacement is necessary and the SDLC begins again.
In addition to these five phases, three activities (planning, managing the behavioral reactions to
change, and assessing the ongoing feasibility of the project) are performed throughout the life cycle.
THE PLAYERS
Many people are involved in developing and successfully implementing AIS, including:
a) Top management: One of the most effective ways to generate systems development support is a clear
signal from top management that user involvement is important. With respect to systems development,
top management’s most important roles are:
 Providing support and encouragement for development projects and aligning
information systems with corporate strategies.
 Establishing system goals and objectives.

 Reviewing the performance and leadership of the information system department.

 Establishing policies for project selection and organizational structure.

 Participating in important system decisions.

The principal roles of user management are:

 To determine information requirements for departmental projects.

Compiled by Benol.M Page 20

 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES
 To assist systems analysts with project cost and benefit estimates.

 To assign key staff members to development projects.

 To allocate appropriate funds to support systems development and operation.

b) Accountants
Accountants may play three roles during systems design:
– First, as AIS users, they must determine their information needs and system requirements
and communicate them to system developers.
– Second, as members of a project development teams or information systems steering
committee, they help manage systems development.
– Third, accountants should take an active role in designing system controls and periodically
monitoring and testing the system to verify that the controls are implemented and
functioning properly. All systems should contain sufficient controls to ensure the accurate
and complete processing of data. The system also should be easy to audit. If addressed at
the start of development, auditability and control concerns can be minimized. Trying to
achieve them after a system has been designed is inefficient, time-consuming, and costly.
c) Information systems steering committee
Because AIS development spans functional and divisional boundaries, organizations usually establish
an executive-level information systems steering committee to plan and oversee the information system
function. The committee often consists of high-level management people, such as the controller and
the systems and user-department management. The steering committee sets policies that govern the
AIS and ensures top-management participation, guidance, and control. The steering committee also
facilitates the coordination and integration of information systems activities to increase goal
congruence and reduce goal conflict.
d) Project development team
Each development project has a team of systems specialists, managers, accountants and auditors, and
users that guides development. Team members plan each project, monitor it to ensure timely and cost-
effective completion, make sure proper consideration is given to human element, and communicate
project status to top management and the steering committee. They should communicate frequently
with users and hold regular meetings to consider ideas and discuss progress so there are no surprises
upon project completion. A team approach usually produces more effective results and facilitates user
acceptance of the implemented system.

Compiled by Benol.M Page 21

 CHAPTER THREE
SYSTEM DEVELOPMENT AND DOCUMENTATION TECHNIQUES
e) Systems analysts
Systems analysts study existing systems, design new ones, and prepare specifications that are used by
computer programmers. Analysts interact with information technology and systems employees
throughout the organization to successfully bridge the gap between the user and technology. Analysts
are responsible for ensuring that the system meets user needs.
f) Computer programmers
Computer programmers write the computer programs, using the specifications developed by the systems
analysts. They also modify and maintaining existing computer programs.
g) External players

Many people outside an organization play a role in systems development, including customers, vendors,
auditors, and governmental entities. Their needs must also be met in systems development.

Compiled by Benol.M Page 22