ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

Chapter Three
System Development and Documentation Techniques
Documentation Tools and Techniques
Documentation encompasses the narratives, flowcharts, diagrams, and other written material that
explain how the system works. This information covers the; who, what, when, where, why, and
how data entry, processing, storage, information output and system controls. One popular means
of documenting a system is to develop diagrams, flowcharts, tables, and other graphical
representations of information. These are then supplemented by a narrative description of the
system, which is a written step-by-step explanation of system components and interactions. The
two most common tools of system documentation; dataflow diagrams and flowcharts will be
discussed in this part. These tools save the organization both time and money. Depending on the
job function being performed, documentation tools are important on one or more of the
following levels:
1. At minimum, documentation is read to determine how the system works.
2. Internal control documentations are evaluated to identify control strengths and
weaknesses and to recommend improvements.
3. The greatest amount of skill is needed to prepare documentation.
An understanding of documentation tools is required regardless of the type of accounting career
chosen. For example, auditors are required to understand the client's system of internal controls
before conducting an audit.

Why documentation is important?

Depicting how the system works: Studying and reviewing written descriptions of the inputs,
processing steps, and outputs of the system make the job easier.
Training users: Documentation also includes the user guides, procedure manuals, and other
operating instructions that help people learn how the AIS operate.
Designing new systems: Documentation helps system designers develop new systems in much
the same way that blueprints help architects design buildings.
Controlling system development and maintenance costs: Good documentation helps system
designers develop object-oriented SW, that is, programs that contain modular, reusable code.

1
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

This object-orientation helps programmers avoid writing duplicate programs and facilities
changes when programs must be modified later.
Standardizing communications with others: Documentation techniques such as flowcharts and
data flow diagrams are standard industry tools, and they are more likely to be interpreted the
same way by all parties viewing them.
Auditing AISs: Documentation helps auditors determine the strengths and weaknesses of a
system’s controls.
Documenting business processes: By mapping the business processes, documentation helps
managers better understand the ways in which their businesses operate.
The basic documentation tools are:
1. Data flow diagram - a graphical description of the source and destination of data that
shows data flow within an organization, the processes performed on the data and how
data are stored.
2. Document flow chart - a graphical description of the flow of documents and information
between departments or areas of responsibility within an organization.
3. System flowchart - a graphical description of the relationship among the input,
processing, and output in an information system.
4. Program flowchart - a graphical description of the sequence of logical operations that a
computer performs as it executes a program.

These tools are used extensively in the system development process. Systems development is a
complex process and these tools are used to create order from chaos and complexity. In addition,
the team members who develop information systems projects often change and these
documentation tools help the new team members get up to speed quickly. Both DFDs and
flowcharts are easy to prepare and revise when one of the recently developed DFDs or
flowcharting software packages is used. They are easier to use than most word processors. Once
a few basic commands are mastered, users can quickly and easily prepare, store, revise, and print
presentation quality DFDs or flowcharts.

2
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

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 plan and design new ones. There is no ideal way to
develop a DFD, because different problems call for different methods. Some general guidelines
for developing DFDs are:
1. Understand the system - involves observing the flow of information through an
organization and interviewing the individuals who use and process the data.
2. Ignore certain aspects of the system - as DFD diagrams the origin, flow, transformation,
storage and destinations of data, all control actions and processes should be ignored.
3. Determine system boundaries - is determining what to include in and exclude form the
system. All relevant data elements shall be included in the DFD because excluded items
will not be considered during systems development. When in doubt about an element's
importance, include it until a definitive decision can be made to discard it.
4. Develop a context diagram - a context diagram is a good way of depicting system
boundaries. The diagram's center is a circle; inside of it, displays the system of concern.
The outside entities, with which the system interacts directly, are in boxes on either side,
connected by data flows depicting the data passed between them. DFDs are prepared, in
successively more detail, to depict data flows in the system.
5. Identify data flows - all data flows shall be identified entering or leaving the system's
boundary, including where the data originate and the final destination. Any significant
movement of information is usually a data flow. All data flows come from and go to
either a transformation process, a data store (file), or a data source or destination. As each
of this is identified, it should be connected to the appropriate data flow.
6. Group data flows - a data flow consists of one or more pieces of datum. Data elements
that always flow together should be grouped together and shown as one data flow until
they are separated. If the data elements do not always flow together, then they should be
shown as two separate data flows.
7. Identify transformation processes - this is by placing a circle wherever work is required
to transform one data flow into another. All transformation processes should have one or
more incoming or outgoing data flows.

3
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

8. Group transformation processes - transformation processes that are logically related or

occur at the same time and place should be grouped together. Unrelated items shall never
be combined into a single transformation process. If data are not processed together, or
are sometimes processed differently, then, they shall be separate.
9. Identify all files or 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.
10. Identify all data sources and destinations - all sources and destinations of data should be
identified and included on the DFD.
11. Name all DFD elements - except for data flows into or out of data stores (data store is
sufficient to identify the data flow), data elements should be given unique and descriptive
names representing what is known about them. This makes DFD easier to read and
understand as it provides the reader with key information. Naming data flows first forces
the developer to concentrate on the all-important data flows, rather than on the processes
or stores. Once data flows have been labeled, naming the process and data stores is
usually easy, because they typically take their names from the data inflows or outflows.
Choosing active and descriptive names such as daily inventory update and validate
transaction, rather than input data or update process. Process names should include action
verbs such as update, edit, prepare, and record.
12. Subdivide the DFD - a cluttered DFD is hard to read and understand. If there are more
than five to seven processes on a single page, then, higher level and lower level DFDs
shall be used. The context diagram shall be decomposed into high level processes, and
then exploded into successively lower level processes.
13. Give each process a sequential number - in completed DFD, each process is given a
sequential number that helps readers move back and forth between different DFD levels.
Data flows should only go from lower numbered to higher numbered processes.
14. Repeat the process - DFD developers must work through organization data flows several
times. Each subsequent pass helps refine the diagram and identify the fine points. When
refining, the DFD shall be organized to flow from top to bottom and from left to right.
15. Prepare a final copy - the final copy of the DFD shall be drawn. Data flow lines shall be
allowed to cross over each other, if necessary, a data store or destination may be repeated.
The name of the DFD, the data prepared, and the preparer shall be placed on each page.
4
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

Elements in a Data Flow Diagram

A DFD is composed of four basic elements: data sources and destinations, data flows,
transformation processes, and data stores. Each represents in a DFD by a unique symbol.

Process

DataStores

Source/Destination
Entity

DataFlow
Demarco & Yourdon Gane & Sarson
Symbols Symbols

These four symbols are combined to show how data are processed. For example, in the diagram
below, the input to process C is data flow B, which comes from data source A. The outputs of
process C are data flows D and E. Data flow E is sent to data destination F.

Data Flow Diagrams

Data Data flow (B) Process Data flow (D)

source (C)
(A)
Data flow (E)
Data
destination
(F)

©2003 Prentice Hall Business Publishing, 6-15

Accounting Information Systems, 9/e, Romney/Steinbart

 A Data source or data destination symbol on the DFD represents an organization or

individual that sends or receives data that the system uses or produces. An entity can be
both a source and a destination. Data sources or destinations are represented by a square.
 A data flow represents the flow of data between processes, data stores and data sources
and destinations. Data that passes between data stores and either a data source or a
destination must go through some form of data processing (transformation process). Data
flow arrows are labeled to indicate the type of data being passed. A data flow can consist
of one or more pieces of datum. For example, data flow B (customer payment) in the
5
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

diagram below consists of two parts: a payment and remittance data. Process (process
payment) splits these two data elements and sends them in different directions. The
remittance data (D) flows to another process, where it is used to update accounts
receivable records, and the payment (E) is sent to the bank with a deposit slip. Because
data flows may consist of more than one data element, the designer must determine the
number of lines to show. For example; customers may send inquiries about the
processing of their payments with payments or separately.
 A transformation process represents the transformations of data. The diagram below
shows that process payment (C) takes customer payment and splits into the remittance
data and the deposit (which includes the checks and deposit slip created within process
payment). The updating receivables (F) process takes the remittance data (D) and the
accounts receivables (F) data, producing updated receivables record and sending
receivables information to the credit manager.
 A data store is a temporary or permanent repository of data. DFDs do not show the
physical storage medium such as disks, and paper, used to store data. As with other DFD
elements, data store names should be descriptive. Data stores are represented by
horizontal lines, with respective name recorded inside.
 A data dictionary contains description of all the elements, stores, and flows in a system.
Data flows and data stores are typically collections of data elements. Typically, a master
copy of the data dictionary is maintained to ensure consistency and accuracy throughout
the development process.

Data Flow Diagrams

Accounts
Customer Remittance data receivable
payment (B) (D) (H)
Customer Process
(A) payment (G)
(C) Receivables
Deposit (E) information
Update (I) Credit
receivables manager
(F) (K)
Bank
(J)
©2003 Prentice Hall Business Publishing, 6-18
Accounting Information Systems, 9/e, Romney/Steinbart

©2003 Prentice Hall Business Publishing, 6-17

Accounting Information Systems, 9/e, Romney/Steinbart

6
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

Subdividing the DFD

Data flow diagrams are subdivided into successively lower levels in order to provide ever-
increasing amounts of detail because few systems can be diagrammed on one sheet of paper.
Users have differing needs, so a variety of levels can better satisfy these requirements. The
highest-level DFD is referred to as 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. For example, the
following can be considered as the context diagram of payroll processing procedures for a certain
company. It shows that the payroll processing system receives time card data from different
departments and employees' data from HR department. When these data are processed, the
system produces:
1. Tax reports and payments for governmental agencies
2. Employee payments
3. A deposit in the payroll account at the bank, and
4. Payroll data for management.

Tax reports and payments Government

Time
cards Agencies
Departments
Payroll Employee Employees
Processing paychecks
S
Payroll
y
check Bank
Human
resources
s
Employee t
Payroll report Management
data
e
m
Flowcharts
A flowchart is an analytical technique used to describe some aspect of an information system in a
clear, concise, and logical manner. Flowcharts use a standard set of symbols to pictorially
describe transaction processing procedures. The following are general guidelines for preparing
flowcharts that are readable, clear, concise, consistent, and understandable.

7
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

1. Understanding a system before flowcharting it by interviewing users, developers,

auditors, and management or having them complete a questionnaire as well as by reading
through a narrative description of the system, or walking through system transactions.
2. Identifying the entities to be flowcharted such as departments, job functions, or external
parties as well as identifying documents and information flows in the system and the
activities or processes performed on the data, for instance drawing a box around the
entities, a circle around the documents and a line around the activities.
3. Dividing the flowchart into columns when several entities such as departments and
functions need to be shown on the flowchart with a label for each followed by
flowcharting the activities of each entity in its respective columns.
4. Flowcharting only the normal flow of operations, ensuring that all procedures and
processes are in proper order and identifying exception procedures by using an annotation
symbol.
5. Designing the flowchart so that flow proceeds from top to bottom and from left to right.
6. Giving the flowchart a clear beginning and ending by designing where the document
originated and showing the final disposition of all documents so there are no loose ends
that leave the reader dangling.
7. Using the standard flowcharting symbols and drawing them with a template or a
computer
8. Clearing labeling all symbols by writing a description of the input, process, or output
inside the symbol. If description may not fit, annotation symbol shall be used.
9. Placing document numbers in the top right hand corner of the symbol when using
multiple copies of a document. The document numbers should accompany the symbols as
it moves through the system.
10. Having an input and output for each manual processing symbol. Two documents shall not
be connected directly except when moving from one column to another column.
11. Using on page connectors to avoid excess flow lines, which results in a neat looking page
as well as using off-page connectors to move from one flowchart page to another. All
connectors shall be clearly labeled to avoid confusion.
12. Using arrowheads on all flow lines and not assuming that the reader will know the
direction of the flow.
8
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

13. Clearly labeling the pages 1 of 3, 2 of 3 etc if a flowchart cannot fit into a single page.
14. Showing documents or reports first in the column in which they are created and then
moving to another column for further processing. A manual process is not needed to
show documents being flowcharted.
15. Showing all data entered into or retrieved from a computer file as passing through a
processing operation (a computer program) first.
16. Drawing a line from the document to a file to indicate that it is being filed. A manual
process is not needed to show a document entering a file.
17. Drawing a rough sketch of the flowchart as a first effort. Concern shall be with capturing
content than perfect drawing. Few systems can be flowcharted in a single draft.
18. Redesigning the flowchart to avoid clutter and a large number of crossed lines.
19. Verifying the flowchart's accuracy by reviewing it with the people familiar with the
system. It shall be assured that all uses of flowchart conventions are consistent.
20. Drawing the final copy of the flowchart, placing the name of the flowchart, the date, and
the preparer's name on each page.

Flowchart Symbols
There are various types of symbols used to create flowcharts. Each symbol has a special meaning
that is easily conveyed by its shape. The shape indicates and describes the operation performed
and the input, processing, output, and storage media employed. The symbols are drawn by a
software program or with a flowcharting template. Flowcharting symbols can be divided into the
following four categories:
1. Input/output symbols - represent devices or media that provide input to or record output
from processing operations.
2. Processing symbols - either show what type of device is used to process data or indicate
when processing is completed manually.
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 and end, where decisions are made,
and when to add explanatory notes to flowcharts.

9
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

Flowchart Symbols:
Document

Online keying

Display

Input/output; journal/ledger

Magnetic disk

Magnetic tape

Document or processing flow

Manual operations On-page connector

Off-page connector
Computer processing
Terminal
Decision
Auxiliary operation

Document Flowcharts
A document flowchart illustrates the flow of documents and information among areas of
responsibility within an organization. They trace a document from its cradle to its grave. They
show where a document originates, its distribution, the purpose for which it is used, its ultimate
disposition, and everything that happens as it flows through the system. A document flowchart is
particularly useful in analyzing the adequacy of control procedures in a system, such as internal
checks and segregation of duties. Flowcharts that describe and evaluate internal controls are
often referred to as internal control flowcharts. The document flowchart can reveal weaknesses
or inefficiencies in a system such as inadequate communication flows, unnecessary complexity
in document flows, or procedures responsible for causing wasteful delays. They also can be
prepared as part of the system design process and should be included in the documentation of an
information system.
Following is a typical example of how a document flowchart can be designed:

Major flowchart symbols are available from EXCEL. To view the Drawing Toolbar of MS10
EXCEL, select the following options from the main menu: In EXCEL,
“Insert/Toolbar/Drawing” or you can also click directly on the Drawing icon in the
Standard Toolbar. After the Drawing Toolbar appears, select “Auto shapes/Flowchart”.
You can observe approximately 28 symbols.
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

System Flowcharts
System flowcharts depict the relationship among the input, processing, and output of AIS. A
system flowchart begins by identifying both the inputs that enter the system and their origins.
The input is followed by the processing portion of the flowchart. The input is followed by
processing portion of the flowchart that is the steps performed on the data. The logic the

11
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

computer uses to perform the processing task is shown on 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. System flowcharts are an important systems 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.

An illustration of how a system flowchart works is shown below:

Program Flowcharts
A program flowchart illustrates the sequence of logical operations performed by a computer in
executing a program. It describes the specific logic to perform a process shown on a systems
flowchart. A flow line connects the symbols and indicates the sequence of operations. The
processing symbol represents a data movement or arithmetic calculation. Once designed and
approved, the program flowchart serves as the blueprint for coding the computer program.

12
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

Enter
Start sales
Input order
Reject
Approved No
Order
for credit?
Storage Yes
Process No
Back-
Inventory Order
available?
Yes

Output Fill order Stop

 The input/output symbol represents either reading of input or writing of output.

 The decision symbol represents a comparison of one or more variables and the transfer of
flow to alternative logic paths.
 All points where the flow begins or ends are represented by the terminal symbol.
Following is another example of a program flowchart for master file updating process.

13
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

Differences between DFDs and Flowcharts

- DFDs emphasize the flow of data and what is happening in a system, whereas a
flowchart emphasizes the flow of documents or records containing data.
- A DFD represents the logical flow of data, whereas a flowchart represents the
physical flow of data.
- Flowcharts are used primarily to document existing systems. DFDs, in contrast,
are primarily used in the design of new systems and do not concern themselves
with the physical devices used to process, store, and transform data.
- DFDs make use of only four symbols. Flowcharts use many symbols and thus
can show more detail.

14
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

Systems Development Process

Because the environment is competitive and ever changing, 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. Companies change their systems for a variety of reasons:
– To respond to changes in user needs or business needs
– To take advantage of or respond to technology changes
– To accommodate improvements in their business process
– To gain a competitive advantage and/or lower costs
– To increase productivity
– To accommodate growth
– To accommodate downsizing or distribute decision making
– To replace a system that is aged and unstable

Important questions in designing a system are:

1. What process must the company go through to obtain and implement a new
system?
2. What types of planning are necessary to ensure the system’s success?
3. How will employees react to a new system?
4. How should the new system be justified and sold to top management?
5. How can expected costs and benefits be quantified to determine whether the new
system will indeed be cost-effective?

The Systems Development Life Cycle

Whether systems changes are major or minor, most companies go through a systems
development life cycle. The systems development life cycle (SDLC) is a conceptual model used
in project management that describes the stages involved in an information system development
project, from an initial feasibility study through maintenance of the completed application. It is a
logical process by which systems analysts, software engineers, programmers and end-users build
information systems and computer applications to solve business problems and needs. Systems
development methodology can be used as a synonym for the life cycle. Systems development

15
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

methodology is a very formal and precise system development process that defines a set of
activities, methods, best practices, deliverables, and automated tools that system developers and
project managers are to use to develop and maintain information systems and software.

Frequently, several models are combined into some sort of hybrid methodology. Documentation
is crucial regardless of the type of model chosen or devised for any application, and is usually
done in parallel with the development process. Some methods work better for specific types of
projects, but in the final analysis, the most important factor for the success of a project may be
how closely the particular plan was followed. In general, an SDLC methodology follows the
following steps:
1. The existing system is evaluated - deficiencies are identified. This can be done by
interviewing users of the system and consulting with support personnel.
2. The new system requirements are defined - in particular, the deficiencies in the existing
system must be addressed with specific proposals for improvement.
3. The proposed system is designed - plans are laid out concerning the physical
construction, hardware, operating systems, programming, communications, and security
issues.
4. The new system is developed - the new components and programs must be obtained and
installed. Users of the system must be trained in its use, and all aspects of performance
must be tested. If necessary, adjustments must be made at this stage.
5. The system is put into use - this can be done in various ways. The new system can
phased in, according to application or location, and the old system gradually replaced. In
some cases, it may be more cost-effective to shut down the old system and implement the
new system all at once.
6. Once the new system is up and running for a while, it should be exhaustively evaluated.
Maintenance must be kept up rigorously at all times. Users of the system should be kept
up-to-date concerning the latest modifications and procedures.

16
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

Romney and Steinhart identified the following five as the components of SDLC.
1. Systems analysis 4. Implementation and conversion
2. Conceptual design 5. Operations and maintenance
3. Physical design

Systems analysis is the first step in SDLC where in-depth understanding about a system starts. At
this stage, the information needed to purchase or develop a new system is gathered. Since
analysis is too costly (in terms of time, effort, money, etc), it is mostly started after the project is
approved and green light is obtained from the management. When a new or improved system is
needed, a written request for systems development is prepared. The request describes the current
system’s problems, why the change is needed, and the proposed system’s goals and objectives. It
also describes the anticipated benefits and costs.
System analysis is the stage of:
- Studying the current business system
- Understanding how the existing system works
- Determining the weakness and strength of the existing system

17
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

- Defining the business needs and requirements (user requirement determination and
system requirement determination independent of technology issues), et

There are five steps in the analysis phase:

 Initial investigation - is conducted to screen projects. At this stage, the following are
essential:
 Gaining a clear picture of the problem or need
 Determining the project's viability and expected costs and payoffs
 Evaluating the project's scope and the nature of the new AIS, and
 Recommending whether the development project should be initiated as
proposed, modified or abandoned.
At this stage the exact nature of the problems under review must be determined. 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.

 Systems survey - at this stage, an extensive study of the current AIS is undertaken. It may
take weeks or months depending on the complexity and the scope of the system. The
objectives of a system survey include:
– Gain a thorough understanding of the company operations, policies, and procedures; data and
information flows; AIS strengths and weaknesses; and available hardware, software, and
personnel.
– Make preliminary assessment of current and future processing needs, and determine the
extent and nature of the 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.
Finally, the findings are documented, the existing system is modeled and analyzed and a survey
report is prepared.
Feasibility study - a more thorough feasibility analysis is conducted to determine the project's
viability. Especially important is economic feasibility. The feasibility analysis is updated as the
project proceeds and costs and benefits become clearer.

18
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

Information needs and systems requirements - once a project is deemed to be feasible, the
company identifies the information needs of the AIS users and documents system requirements.
the strategies for determining requirements include the following:
 Ask users what they need; Analyze existing system; Examine existing system
use; & Create a prototype
Systems analysis report - is the conclusion of the system analysis phase. It is used to summarize
and document the analysis activities and serve as a repository of data from which system
designers can draw. A go-no-go decision is generally made three times during system analysis:
 During the initial investigation - to determine whether to conduct a feasibility
survey
 At the end of the feasibility study - whether to proceed to the information
requirements phase
 At the completions of the analysis phase - to decide whether to proceed to the
next phase.

Requirements determination tries to collect information on what system should do from

many sources like users, reports, forms, etc. Characteristics for gathering requirements are:
1. Impertinence—question everything
2. Impartiality—finds the best organizational solution and don’t try to justify the
importance of your suggestions at any cost.
3. Relaxation of constraints--assume that anything is possible
4. Attention to detail—due consideration should be given to facts (information)
5. Reframing—analysis is a creative process. Try to address situations in a new way.
Don’t jump to conclusions thinking you have done the same thing before

System Design: System design is the evaluation of alternative solutions and the specification
and construction of a detailed computer based solution. It is also called physical design as it
deals with implementation issues. Systems analysis depends more on the logical aspect,
implementation-independent aspects of a system /the requirements. Systems design
concentrates on the physical or implementation-dependent aspects of a system (the systems
technical specifications).

19
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

Conceptual design: In the conceptual systems design phase, a general framework is

developed for implementing user requirements and solving problems identified in the
analysis phase. What are the three steps in conceptual design?
1. Evaluate design alternatives
2. Prepare design specifications
3. Prepare conceptual systems design report.

The Systems Development Life Cycle:

Conceptual Design

Conceptual Design
Identify and evaluate
design alternatives
Develop design specifications Physical
Design
Deliver conceptual design
requirements

©2003 Prentice Hall Business Publishing, 16-13

Accounting Information Systems, 9/e, Romney/Steinbart

The system analysis phase is related to the conceptual design phase based on the diagram shown
below:

Conceptual Systems Design

Systems
analysis

Prepare
Evaluate Prepare
conceptual
design design
systems
alternatives specifications
design report
©2003 Prentice Hall Business Publishing, 18-10
Accounting Information Systems, 9/e, Romney/Steinbart

 Evaluate design alternatives:

 The design team should identify and evaluate design alternatives using the following
criteria:
1. How well it meets organizational and system objectives
2. How well it meets users’ needs
3. Whether it is economically feasible
4. Its advantages and disadvantages
 Prepare design specifications:

20
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

 Once a design alternative has been selected, the team develops the conceptual design
specifications for the following elements: Input, Data storage, Processing procedures and
operations, and Outputs.
 Prepare conceptual systems design report:
 At the end of the conceptual design a conceptual systems design report is developed and
submitted.
1. To guide physical systems design activities
2. To communicate how management and user information needs will be met
3. To help assess systems’ feasibility

Physical design

The Systems Development

Life Cycle: Physical Design
Physical Design
Design output
Design database
Implementation
Design input and Conversion
Develop programs
Develop procedures
Design controls
Deliver developed system
©2003 Prentice Hall Business Publishing, 16-14
Accounting Information Systems, 9/e, Romney/Steinbart

The above activities will come as a series of steps as shown by the diagram below:

Physical Systems Design

Output Program
design design

File and data Procedures

base design design

Input Controls
design design
©2003 Prentice Hall Business Publishing, 18-16
Accounting Information Systems, 9/e, Romney/Steinbart

Physical Systems Design: Output Design

 The objective of output design is to determine the characteristics of reports, documents,
and screen displays.

21
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

Physical Systems Design

 Physical design translates the broad,

user-oriented AIS requirements of
conceptual design into detailed
specifications that are used to code
and test the computer program.

Conceptual Physical
systems design systems design

©2003 Prentice Hall Business Publishing, 18-15

Accounting Information Systems, 9/e, Romney/Steinbart

Physical Systems Design: File and Database Design, Input Design, Procedures Design, and
Control Design
What are some control design considerations?
 Validity  Authorization Audit Control
 Accuracy  Security
 Numerical Control  Availability
 Maintainability  Integrity

Physical Systems Design Report

 At the end of physical design phase the team prepares a physical systems design report.
 This report becomes the basis for management’s decision whether to proceed to the
implementation phase.

Implementation and conversion: Systems implementation is the process of installing hardware

and software and getting the AIS up and running. It includes the following activities.
The Systems Development
Life Cycle: Implementation and
Conversion
Implementation and Conversion
Develop plan
Install hardware and software
Train personnel, test the system
Operation
Complete documentation
and
Convert from old to new system Maintenance
Fine-tune and review
Deliver operational system

©2003 Prentice Hall Business Publishing, 16-15

Accounting Information Systems, 9/e, Romney/Steinbart

22
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

The relationship of the items in this phase and the conversion process (next phase) will be as
shown below in a series of activities.

Systems Implementation
Implementation planning

Develop and Prepare site; Select

test software install and and train
programs test hardware personnel

Complete Test system

documentation

Conversion
©2003 Prentice Hall Business Publishing, 18-27
Accounting Information Systems, 9/e, Romney/Steinbart

Systems Implementation: Implementation Planning

 An implementation plan consists of implementation tasks, expected completion dates,
cost estimates, and the person or persons responsible for each task.
 Planning should include adjustments to the company’s organizational structure.
Systems Implementation: Develop and test software programs
Systems Implementation: Site Preparation
Systems Implementation: Select and train personnel
Systems Implementation: Complete Documentation
Systems Implementation: Test the System
Systems Implementation: Conversion
 There are four conversion approaches.
1. Direct conversion 3. Parallel conversion
2. Phase-in conversion 4. Pilot conversion
Operations and maintenance

23
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

The Systems Development

Life Cycle: Operation and
Maintenance
Feasibility analysis
Operation and Maintenance and decision points:
Operate system Economic
Feasibility
Modify system
Do ongoing maintenance Technical Feasibility

Deliver improved system Legal Feasibility

Scheduling
Feasibility
Systems
Operational
Analysis Feasibility

©2003 Prentice Hall Business Publishing, 16-16

Accounting Information Systems, 9/e, Romney/Steinbart

Operation and Maintenance

 The final step in the SDLC is to

operate and maintain the new system.
 A postimplementation review should
be conducted on a newly installed
system.

Implementation Operation and

and conversion maintenance

©2003 Prentice Hall Business Publishing, 18-41

Accounting Information Systems, 9/e, Romney/Steinbart

The key Players in System Development Process

The Players refer to who are the people involved in developing and implementing AIS?
 Management
 Accountants
 Information systems steering committee
 Project development team
 Systems analysts and programmers
 External players
What are top management’s roles?
o providing support and encouragement
o establishing system goals and objectives
o determine information requirements
What are accountants’ roles?
– determine their information needs
– may be members of the project development team
– play an active role in designing system controls
What are the steering committee’s roles?
24
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

– set policies that govern the AIS

– ensures top-management participation
– guidance and control
– facilitates coordination and integration of IS activities
What are the project development team’s roles?
– plan each project
– monitor project
– make sure proper consideration is given to the human element
What are the system analyst’s and programmer’s roles?
– study existing systems
– design new systems and prepare specifications
– write computer programs
Why is planning an important step in systems development?
– consistency
– efficiency
– cutting edge
– lower costs
– adaptability
What types of systems development plans are needed?
– project development plan
– master plan
Planning Techniques
 Two techniques for scheduling and monitoring systems development activities are:
a. PERT (program evaluation and review technique): PERT requires that all
activities and the precedent and subsequent relationships among them be
identified.
b. Gantt chart: A bar chart with project activities listed on the left-hand side and
units of time across the top

25
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

Feasibility Analysis
 Systems analysis is the first step in the systems development life cycle (SDLC).
 A feasibility study (also called a business case) is prepared during systems analysis and
updated as necessary during the remaining steps in the SDLC.
 The steering committee uses the study to decide whether to terminate a project, proceed
unconditionally, or proceed conditionally.
 What five important aspects need to be considered during a feasibility study?
 Technical feasibility
 Operational feasibility
 Legal feasibility
 Scheduling feasibility
 Economic feasibility
 Economic feasibility is the most frequently analyzed of the five aspects.
 What is the basic framework for feasibility analysis?
 capital budgeting model
 What are some capital budgeting techniques?
 Payback period
 Net present value (NPV)
 Internal rate of return (IRR)
Behavioral Aspects of Change
 Individuals involved in systems development are agents of change who are continually
confronted by people’s reaction and resistance to change.
 The best system will fail without the support of the people it serves.
 Why do behavioral problems occur?
 personal characteristics and background
 manner in which change is introduced
 experience with prior changes
 communication
 disruptive nature of the change process
 fear

26
ACCOUNTING INFORMATION SYSTEM_DU HAND OUT_ABEL D.

 How do people resist AIS changes?

 aggression  projection
 avoidance
 How can behavioral problems be overcome?
 meet needs of the users
 keep communication lines open
 maintain a safe and open atmosphere
 obtain management support
 allay fears
 solicit user participation
 make sure users understand the system
 provide honest feedback
 humanize the system
 describe new challenges and opportunities
 reexamine performance evaluation
 test the system’s integrity
 avoid emotionalism

27