Introduction to Information
Systems Analysis
Information Systems Development
Fact Finding Techniques
INFO 503
Glenn Booker
INFO 503
Lecture #2
1
System Development Life Cycle
• A System Development Life Cycle is the
process used for developing a system
• A life cycle is a management tool for
planning, conducting, and controlling
an activity
• Software and System life cycles are similar,
differing in the details of each activity
INFO 503
Lecture #2
2
Methodology
• A methodology, such as FAST, implements
a life cycle by defining activities
• Each activity has roles and responsibilities,
creates work products, and uses tools
and techniques
– Major recurring theme in the text
• Methodology should cover entire life cycle
INFO 503
Lecture #2
3
Capability Maturity Model
• Level 1 = Initial chaos – no
consistent processes
• Level 2 = Repeatable processes for a project
• Level 3 = Defined processes across
an organization
• Level 4 = Quantitatively Managed projects
• Level 5 = Processes Optimized continuously
INFO 503
Lecture #2
4
Groundwork
• Any system development should first define
its general scope
– What kind of product will be created?
– What order of magnitude for time frame and
number of resources are available for this
effort? (e.g. week, month, year, or $10k, $1M)
– What is the current state of similar products?
– What will make this product special?
INFO 503
Lecture #2
5
Ten Principles of System
Development
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Get the system users involved
Use a problem-solving approach
Establish phases and activities
Document throughout Development
Establish standards
Manage the Process and Projects
Justify systems as capital investments
Don’t be afraid to cancel or revise scope
Divide and conquer
Design systems for growth and change
INFO 503
Lecture #2
6
1. Get the System Users Involved
• Encourage owners, users, and developers to
work cooperatively and collaborate
• Get everyone involved in defining
requirements and discussing changes
• Document decisions well
• Education of owners and users can help
overcome biases and fears
INFO 503
Lecture #2
7
2. Use a Problem-Solving
Approach
• The methodology (life cycle) is an approach
–
–
–
–
–
Study the problem and its context
Define the requirements of a solution
Identify possible solutions and pick one
Design and implement the solution
Observe the solution’s impact, and refine it
• Don’t skip steps!
INFO 503
Lecture #2
8
p. 89 (75)
3. Establish Phases and Activities
• Major FAST phases are:
– Scope Definition (led by system owners)
– Problem and Requirements Analysis (users)
– Logical Design and Decision
Analysis (designers)
– Physical Design and Integration (builders)
– Construction and Testing
– Installation and Delivery
INFO 503
Lecture #2
9
3. Establish Phases and Activities
• Higher levels are business-driven; lower are
technology-driven
• Each phase is broken down into activities
and tasks to make them manageable
• Development is often iterative, with
frequent back-tracking to refine
requirements and the design
• Be sure not to get stuck in iteration!
INFO 503
Lecture #2
10
4. Document throughout Development
• In order for large projects to succeed,
programs need to be documented and
agreed upon before they’re developed
• Necessary for coordination across
stakeholders, and to leave a comprehensible
legacy for maintenance
INFO 503
Lecture #2
11
5. Establish Standards
• Standards should be used for both creation
of the information system itself, and for the
processes used to create the system
• Records assumptions and measure progress
• May include document style standards, file
and variable naming conventions, and file
organization conventions…
INFO 503
Lecture #2
12
5. Establish Standards
• System development standards may
describe, for every phase of the life cycle:
– Activities (what happened?)
– Responsibilities (who did it and why?)
– Documentation requirements (tailor from
corporate standard templates)
– Quality checks (peer review, defect prevention)
INFO 503
Lecture #2
13
6. Manage the Process and Projects
• Deliberate process and project management
ensures that your organization 1) has
defined processes, and 2) they are actually
used, and 3) you can determine how to
improve them
• Benefits not only this program, but others
in the future too
INFO 503
Lecture #2
14
7. Justify Systems as
Capital Investments
• Information systems often outlive many
projects, hence are capital investments
• Make sure alternatives are well investigated
(do you buy the first house you see?)
• Analyze the cost-effectiveness of all major
alternatives, including both development
and operational costs
• Manage risks during development
INFO 503
Lecture #2
15
8. Don’t be afraid to
Cancel or Revise Scope
• The iterative nature of development makes
it tempting to implement a not-good system
• Feature and schedule creep can sneak
up quietly, one good decision after another
• Avoid getting stuck by choosing creeping
commitment points during development
• At each, consider cancellation, projected
system cost, schedule, and feature scope
INFO 503
Lecture #2
16
9. Divide and Conquer
• Every system is part of a larger system
(supersystem) and most contain smaller
systems (subsystems)
• Interaction with supersystem can change
requirements during system development
• Defining subsystems can help make project
design more manageable
INFO 503
Lecture #2
17
10. Design Systems for
Growth and Change
• Business needs change over time
• During system maintenance (support),
maintenance cost grows as the system
requirements evolve and hardware wears
out; system becomes obsolete
• Hence need to design systems so that they
can be replaced some day
INFO 503
Lecture #2
18
FAST Methodology
• An information system project starts when:
– Problems keep your organization from reaching
its business goals or objectives
– Opportunities arise when a new capability is
identified (e.g. new features)
– Directives from outside your organization
mandate new features or requirements
(e.g. laws, regulations)
INFO 503
Lecture #2
19
PIECES Review Criteria
Assess new projects for their:
• Performance improvement potential
• Information or data improvement
• Economic or cost improvement
• Control or security improvement
• Efficiency improvement (people or process)
• Service to customer, supplier, staff, etc.
INFO 503
Lecture #2
20
FAST Phases
p. 96 (83)
key overview
1. Scope Definition [in 4th Ed.: Survey Phase]
(system owner)
2. Problem Analysis [Study Phase] (analyst)
3. Requirements Analysis [Definition
Phase] (analyst)
4. Logical Design [not separate in 4th Ed.]
5. Decision Analysis [Configuration
Phase] (designer)
INFO 503
Lecture #2
21
FAST Phases
Procurement Phase [Version 4 separate only;
or blend into other phases] (designer)
6. Physical Design & Integration [Design
Phase] (designer)
7. Construction & Testing [Construction
Phase] (builder)
8. Installation & Delivery [Delivery Phase]
(builder)
INFO 503
Lecture #2
22
1. Scope Definition
• This is a sanity check to see if the project
is worth looking at
• If so, define the project team, budget,
and schedule (very rough)
• Involves sponsors and managers, plus
user involvement
• Deliver a feasibility study and project plan
INFO 503
Lecture #2
23
2. Problem Analysis
• Study existing system (automated or not)
for problems and opportunities
• Is the new & improved system
worth having?
• Run by system analyst, with user and
owner involvement
• Define system objectives, and success
criteria for new system
INFO 503
Lecture #2
24
3. Requirements Analysis
• Now define and prioritize detailed system
and business requirements
• Consider also what it does NOT do
• Do NOT describe HOW it does anything
• System analyst and many users do this
• Create models of data, process, interface,
and geography perspectives…
INFO 503
Lecture #2
25
3. Requirements Analysis
• Might use prototyping to
verify requirements
• Present requirements and models in a
requirements statement
• “Time boxing” is placing requirements
into staged deliveries for implementation
(hence start to think of priorities)
INFO 503
Lecture #2
26
4. Logical Design
• The logical design phase is when various
models are developed to describe the logical
functions of the system
• This typically includes data, process, and/or
object models
– Beware of getting stuck in analysis paralysis
INFO 503
Lecture #2
27
5. Decision Analysis
• Identify candidate solutions, analyze them,
and recommend the best one
• Done by system analyst, with support from
all others, and maybe consultants
• May start before requirements are done
• May include make-or-buy decisions, and
define an application architecture…
INFO 503
Lecture #2
28
5. Decision Analysis
• Evaluate each solution for technical,
operational, economic, and
schedule feasibility
• Produce a system proposal for
owners’ approval
• Often includes procurement phase for
off-the-shelf applications
INFO 503
Lecture #2
29
Procurement Phase
• Major system components are often
acquired, not built from scratch
• See COTS tool reports (Commercial-OffThe-Shelf software) by the SEI, STSC
• Vendors “help” system analyst and users
• Study existing market & future trends, then
generate a RFP or RFI (see References)…
INFO 503
Lecture #2
30
Procurement Phase
• Evaluate vendors’ proposals; pick the
one that meets requirements and is most
cost effective
• Negotiate contractual and licensing needs to
obtain products, installation, training, etc.
INFO 503
Lecture #2
31
6. Physical Design & Integration
• Turn requirements into plans for the
builders, iteratively, until plans are complete
(Rapid Application Development)
• Analyst and specialists involved
• Database, program, human and system
interfaces are all designed using
iterative prototyping…
INFO 503
Lecture #2
32
6. Physical Design & Integration
• Iterate:
– Define base system
– Define database, load with data, and review
with users
– Define inputs, and review with users
– Define outputs, and review with users
– Define interfaces, and review with users
– Define other controls, and implement. Repeat.
INFO 503
Lecture #2
33
7. Construction & Testing
•
•
•
•
Now build the real system and its interfaces
System builders lead the team
Design specifications are main input
Write code, then conduct unit test, and
system test
• May deliver system in stages
INFO 503
Lecture #2
34
8. Installation & Delivery
• Install new system and place it
into operation
• May include data conversion and loading to
initialize system, and training of end users
• Users provide feedback (problem reports) to
identify initial support issues
INFO 503
Lecture #2
35
System Operation and Maintenance
• While system is in use:
–
–
–
–
INFO 503
Assist users (help desk)
Fix bugs
Recover system after failures
Adapt to new requirements
(implement new features)
Lecture #2
36
Cross Life Cycle Activities
• These may overlap many (or all) other
phases of development
• Fact-finding
– Help collect information about systems,
requirements, and user preferences;
– Most important early in life cycle
INFO 503
Lecture #2
37
Cross Life Cycle Activities
• Documentation is generated to record
the work accomplished so far, and plan
future activities
• Presentations are a formal packaging, in
writing or orally, of some documentation
– “Dog and pony shows” are presentations
made to upper management or sponsors
INFO 503
Lecture #2
38
Cross Life Cycle Activities
• Estimation and measurement are performed
throughout the life cycle (see INFO 630)
– Estimation is to predict the amount of time,
effort, cost, and benefits of some activity within
system development
– Measurement is to determine the actual amount
of what was estimated
– “Earned value” is one way of comparing them
INFO 503
Lecture #2
39
Cross Life Cycle Activities
• Feasibility analysis is performed early in a
project to determine its potential benefits
– Recall mention of technical, operational,
economic, and schedule feasibility
• Project management is the deliberate
planning and control of a project to achieve
the desired goal (creation of a product)
INFO 503
Lecture #2
40
Cross Life Cycle Activities
• Process management is the conscious
definition and management of the processes
used to conduct a project, using standards to
define typical work products (deliverables)
• Data and documents from all phases should
be stored, such as in a repository
INFO 503
Lecture #2
41
Methodology Options
p. 108 (n/a)
• Systems can be build from scratch,
purchased off-the-shelf, or some of both
• Methodologies can be very rigid
(prescriptive), or flexible (adaptive)
• Methodologies can be model-driven (draw
pictures first, e.g. FAST) or product-driven
(build something and see if it works)
INFO 503
Lecture #2
42
Model-Driven Development
• Most methods for analysis and design focus
on using models to capture thoughts
– Structured analysis focuses on processes, such
as the data flow diagram
– Information engineering focuses on data, such
as the entity relationship diagram
– Object oriented analysis and design blend data
and process into objects
INFO 503
Lecture #2
43
RAD and COTS
• Rapid Application Development (RAD)
focuses on iterative development of
prototypes with lots of user input
– Often uses time boxing to limit the effort on
each iteration
• Commercial Off The Shelf (COTS)
products can be used as the entire system,
or significant portions of a developed one
INFO 503
Lecture #2
44
CASE Tools
• Computer Assisted Software Engineering
(or Systems Engineering) tools use an
information system (customized database)
which is devoted to managing a system
development effort
• CASE tools may include compilers, design
and diagram tools, quality and document
management tools, and generate code
INFO 503
Lecture #2
45
CASE Tools
• Upper CASE Tools focus on early
development activities – requirements and
high level design phases; may also be able
to reverse engineer code
• Lower CASE Tools focus on (you guessed
it!) later development activities – detailed
design, construction (coding),
implementation, and perhaps support
INFO 503
Lecture #2
46
CASE and ADE Tools
• CASE Tools are noted for pretty graphical
capabilities - diagrams, flow charts, etc.
– They store projects in repositories
– Price is high in both $$$ and learning curve
• Compilers have evolved into Application
(or Integrated) Development Environments
(ADE or IDE) – may include debuggers and
interface tools, testing and version control
INFO 503
Lecture #2
47
Fact Finding and Information
Gathering
• Fact finding is the formal process of
using various techniques to collect
information about system requirements
and user preferences
• Facts are the basis for modeling
• Conclusions about the system are also
drawn from these facts
• So facts are, like, really important :)
INFO 503
Lecture #2
48
Fact Finding and Information
Gathering
• Fact finding is most important during the
planning and analysis phases, but still
useful during the rest of the life cycle
• Seven techniques to choose from; often
use several on any given project
• Fact finding may also discover business
rules – how does the system need to
respond under different conditions?
INFO 503
Lecture #2
49
Requirements
See also INFO627
• Fact finding may give info at various levels
of detail, depending on the audience
– Requirements capture what and/or how the
system needs to be able to support its users
– A requirement is more precise than a user need,
but more vague than a specification
• Defining requirements is a key output from
fact finding and information gathering
INFO 503
Lecture #2
50
Requirements
• A Need defines the basis for requirements, such as
“the system must support 20 simultaneous users”
• A Requirement defines what capability the system
must fulfill to meet the need, “the system must
handle 1000 tps from 20 simultaneous users”
• A Specification defines how to measure the
requirement, such as the protocol or test
conditions to be used
tps = transactions per second
INFO 503
Lecture #2
51
Requirements
• Many requirements are functional – they
describe what the system can do
• Non-functional requirements describe how
the system performs the functional req’ts
– Performance, cost, control (security), efficiency
(resource usage), and the “ilities” (reliability,
availability, maintainability, usability, etc.)
INFO 503
Lecture #2
52
Fact Finding and Information
Gathering
p. 243 (623)
• Techniques are:
–
–
–
–
–
–
INFO 503
Sampling
Research and Site Visits
Observation of the Work Environment
Questionnaires
Interviews
Prototyping
Lecture #2
53
Sampling
• Works well for study of an existing system
• Comes before interviews; may include:
–
–
–
–
–
INFO 503
Look for organization chart
Investigate project history
Look for high level mission or policies
Charters for each organization affected
Processes and procedures in use
Lecture #2
54
Sampling
• And study existing system documents
–
–
–
–
–
INFO 503
Inputs
Outputs
Program documentation
Data dictionaries
User and maintenance manuals
Lecture #2
55
Sampling
• If you know a lot about the consistency of
data, can use statistical sampling techniques
• A random sample should be truly random,
not just convenient
• A stratified sample may be used to avoid
important special cases
See also INFO 630
INFO 503
Lecture #2
56
Research and Site Visits
• Research may use various sources, such as:
– The Internet (e.g. for vendors)
– Trade and professional journals (AITP, AIS,
IEEE, ACM, etc.)
– Company-specific intranets
– Government agencies (SEI, STSC, etc.)
• Site visits are to see the existing system
INFO 503
Lecture #2
57
Observation of the Work Environment
• Participate in, or watch the existing system
being used
• Should determine what kind of data to
collect, when, and how (what forms)
• Should already understand the process
being observed somewhat
• Can use sampling for large numbers
of observations
INFO 503
Lecture #2
58
Observation of the Work Environment
•
•
•
•
•
•
•
Determine who, what, where, why, and how
Obtain permission from supervisor
Inform subject of reason for visit
Keep a low profile; don’t interrupt
Take copious notes, and review them
Focus on important activities
Don’t make assumptions
INFO 503
Lecture #2
59
Questionnaires
•
•
•
•
Can be efficient for large audiences
But hard to guarantee responses, or fairness
Can use free format, but hard to analyze
Fixed format may include:
– Multiple choice (Y/N or A/B/C/..)
– Rating (5-point from strongly agree to
strongly disagree)
– Ranking (importance, or % or time)
INFO 503
Lecture #2
60
Interviews
• Provide more personal information about
body language, inflection, tone, etc.
• Take a lot more time, but are often liked
• Can be structured or unstructured (rare)
• Structured tend to use open-ended questions
rather than closed-ended ones (yes/no)
• Need to be well prepared, take good notes
INFO 503
Lecture #2
61
Prototyping
• Prototyping, or discovery prototyping,
tends to use very specialized tools, and
may define and refine prototypes with
direct user involvement
– Can be part of a RAD development approach
– Highly iterative; helps clarify requirements
– Easy to omit quality and performance req’ts
INFO 503
Lecture #2
62
Ethics
• Many professional organizations, such as
the AITP, IEEE, the Computer Ethics
Institute, and ACM have defined standards
of professional conduct
• Such standards should be used for guidance
when dealing with information which may
be sensitive, such as pricing structure, profit
data, or employee personal data
INFO 503
Lecture #2
63