Transcript CSIS3600 System Analysis and Design

CSIS3600 System Analysis and
Design
Lecture 7
Determining System Requirements
The Beginning of Analysis



Analysis begins once permission has been granted to
pursue the development of a new system.
Determining System Requirements begins the
Analysis Phase of Systems Development.
Analysis includes:




Requirements Determination
Requirements Structuring
Alternative Generation and Selection
Analysis is creative work.
The Work of Determining
System Requirements



System Requirements determination answers the question:
What is the system to do?
This type of analysis primarily consists of fact-finding activities.
Through this process, "the analyst learns about the vocabulary,
problems, opportunities, constraints, requirements and priorities
of a business and a system" (Whitten and Bentley, 1999).
The work of systems analysis is "to determine what information
and information processing services are needed to support
selected objectives and functions of the organization;
consequently, analysis is fundamentally an intelligence activity in
which analysts capture and structure information" (Hoffer, et al,
1999).
Key Ideas



The goal of the analysis phase is to truly
understand the requirements of the new
system and develop a system that addresses
them.
The first challenge is finding the right people to
participate.
The second challenge is collecting and
integrating the information
PowerPoint Presentation for Dennis, Wixom & Tegardem
Systems Analysis and Design
Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.
Pre-Requisite Understanding








The business objectives that drive what and how work is performed.
Information people need to know to do the job.
Data required to support the job.
When, how and by whom or what data are moved, transformed and
stored.
Sequence and other dependencies among data-handling activities.
Rules governing how data are handled and processed.
Policies and guidelines that describe the nature of the business and
the market and the environment in which it operates.
Key events affecting data value and when these events occur.
Characteristics
The characteristics of requirements
determination:





Impertinence - question everything
Impartiaility - find the best solution
Relax constraints - all things are feasible
Attention to detail - every fact fits with every
other fact
Reframing - look at the organization and the
problem in new ways
Questions to Ask
Much analysis focuses on the way work is performed. Hoffer, et
al (1999) lists questions that should be investigated:
 How does the current system function? Is the system
manual or automated?
 What data are necessary for proper functioning of the
supported business area?
 What kinds of reports are generated?
 How do people use the system to perform their work?
 How should a new or replacement system function?
 What data would be needed for it to operate smoothly?
 How would a new system alter employees' jobs?
 What new or improved information services are needed to
support the future organizational goals, objectives,
strategies, and functions?
If you don’t ask the right questions, you won’t get the right
answers.
Collecting Information


In order to properly assess the appropriate
requirements for the system, information should be
gathered from as many sources as possible including
system players (owners, users, etc.), observing users,
from reports, forms, and other pertinent
documentation and procedures used to carry out the
work.
There are several techniques for collecting
information. Analysts use a variety of these in any
given project. Understanding their advantages and
disadvantages as well as which one to use when is
important for success in building information
systems.
Traditional Approaches
Traditional approaches to fact finding:
 Reviewing and evaluating the current system/similar
systems including analyzing existing procedures
 Interviewing
 Questionnaires
 Direct observation of the work environment and end
users
 Analyzing existing documentation, forms and databases
 Analyzing existing procedures
 Research
Sampling
Once you synthesize what I just said, you are probably
thinking this isn't feasible. The amount of information
that one could collect can be quite large and the time it
takes to collect that information might be quite
extensive. You run into another problem as well. Too
much information is sometimes no more useful than too
little information and too much analysis is not
productive ("analysis paralysis").
Sampling continued





It is not practical to collect information from every
system users and to purview every piece of relevant
documentation.
Sampling is the process of systematically selecting
representative elements of a population.
Sampling requires assessing who (or what) makes up
the total population and then determining what
would be an appropriate sample size for that
population.
Using samples enhances the fact finding mission of
systems analysts, making the process less time
consuming and more productive.
Sampling can be employed for all types of fact finding
techniques as outlined later on in these notes.
Current System/Similar
Systems
The first place to look for information is with the current system - be it
a computerized, automated or manual system.
Ways to evaluate the current/similar systems:

Model the system

Identify cause-effect relationships among system activities

Identify any business event or input to which the system
responds

Identify special business policies ,processing or decisions that
must be made to respond to the input

Identify normal business outputs or responses to
aforementioned events or inputs

Identify any information that must be produced or made
available
Note on Current System
Evaluation

It was once popular to perform a detailed and
thorough analysis of the current system –
that is no longer advocated due to the
dynamic changes in technology but it is still
important to identify the data, information
and business processes served by the current
system.
Sampling and Current
System/Similar System

A formal sampling process is not
necessary. The processing of selecting
similar systems to review includes
researching what systems exist and
choosing those that are in use in similar
environments.
Analyzing Documents
This can include most anything.
Documents that might describe the
problem:
Interoffice memos, minutes of meetings,
suggestion box notes, customer
complaints, reports, accounting records,
performance reviews, work measurement
reviews…
Analyzing Documents
continued
Documents that describe the business
functions:
Mission statement, strategic plan, organizational
and departmental objectives, policy manuals,
standard operating procedures, job descriptions,
task instructions, completed forms, manual and
computerized databases, manual and
computerized screens and reports…
Analyzing Documents
continued
Documentation of previous system
studies:
System diagrams, project repositories,
design documents, data model, program
documentation, user documentation,
computer operations manuals
Sampling Documents
Guidelines for sampling documents:
AVOID blank forms
 Study enough samples to identify all conditions
and exceptions
A simple Sample formula that has been cited to be
reliable:
Sample size = 0.25 * (certainty
factor/acceptable error)2
Certainty factor – statistical representation that
sample will not include variations not in the sample
(certainty values can be found in tables)
Acceptable error – user defined


Example of Sampling Formula
Suppose you want 90% certainty that a sample of
invoices will contain no unsampled variations:
SS = 0.25(1.645/0.1) 2 = 68
Certainty factors (from table)
95% 1.96
90% 1.645
80% 1.281
Acceptable error – 100% - acceptable % of
certainty (100-90) = 10% or .10
Additional Formula
Using .25 often results in a sample size larger than
necessary. You can use an additional formula:
n = (p(1-p)/ss2) + 1
where p is an estimate of the proportion of the
population containing a specified attribute
ss is the result of using the previous formula
Selecting the Sample
Two methods for choosing the document
sample:


Randomization – randomly selecting
documents without any predetermined
plan or pattern
Stratification – systematic sampling to
reduce variance by spreading out the
sample – for instance stratification by
department, by customer type, etc.
Collecting Information
from People
The input from many individuals (users, system owners,
etc) can be beneficial. This can be facilitated by
sampling. Sample types include the




convenience sample – those that are there and willing to
be interviewed
purposive sample – selecting people who satisfy certain
criteria
simple random sample - randomly picking people
stratified sample – identifying categories of people and
then taking random samples from each category
Interviewing
Interviewing is a primary way to gather information
Steps in Interviewing:
Plan the Interview
Read Background Material
Establish Interview Objectives
Decide Whom to Interview
Prepare the Interviewee
Decide on Question Types and Structure
Interviewing Steps continued
Conduct the Interview
 Use audio recording or develop good note taking skills
 Shake the interviewee’s hand
 Begin with general, non-threatening questions
 Let your interviewee know what kind of detail you are
expecting
 Don’t go beyond an hour
 Listen – reflect back or summarize what the
interviewee said
 End with – "Is there anything else we haven’t
discussed you feel is important for me to know?
Interviewing Steps continued
Report on the Interview

Write it as soon as possible after the interview

Identify main points


Identify your opinions versus interviewee’s
opinions
Review the report with the interviewee
Types of Interview
Questions
Open ended ("What do you think about putting all
managers on an intranet?")

Benefits:

Puts interviewee at ease

Provide for richness of detail

Allow more spontaneity


Allow interviewer to pick up on interviewee
vocabulary
Pitfalls:

May result in too much irrelevant detail

Chance to lose control of the interviewee

Allow for responses that take too much time and
glean too little information
Interview Questions
continued
Closed Questions ("How many subordinates do you have?")


Benefits:

Limit responses (Y/N, How many, etc)

Saves time

Gets to the point quickly

Keeps control of the interview
Pitfalls:

Can be boring

Fails to obtain rich detail

Chance to miss main idea or underlying reasons

Fails to build rapport
Interview Questions continued
Probe Questions ("Will you elaborate on that for me?")
 Asks why and often ask for examples
 Goes beyond the initial answer to get more
meaning, to clarify and to draw out and expand
on interviewee’s point
 Important to probe to get beyond superficial
answers
 May seem intrusive but if built on responses
given by the interviewee is a result of listening.
Listening is respected.
Surveys/Questionnaires
Questionnaires facilitate information gathering from
many people
Guidelines on whether to use questionnaires:
 People who need to be questioned are widely
dispersed.
 Large number of people are involved in the project
and it is meaningful to know what portion of the
group approves or disapproves of a particular
feature of the proposed system.
 You are doing an exploratory study and want to
gauge overall opinion to set a specific direction.
 You wish to be certain that problems with current
system are identified.
Steps in Using a
Questionnaire



Identify objectives
Write the questions
 Carefully choose wording
 Make questions simple, short, specific, free of
bias, technically accurate
Decide on type of questions and measurement
techniques
 Quantitative scales assign numbers to response
values (strongly agree = 5, etc.)
 Open ended questions require qualitative analysis
where responses are reviewed for patterns
Using a Questionnaire
continued



Test questions on a small sample of respondents.
 Make edits based on their recommendations.
Develop a plan for administering questionnaire
 Convene all people together at one time
 Personally hand out blank questionnaires and
received completed ones
 Mail questionnaire
 Provide access to it electronically
Evaluate and interpret responses
Types of Questionnaire
Questions

Free-format – open ended questions

Fixed Format – require specific responses

Multiple choice

Rating questions


On a scale of 1-5 (5 being the highest) rate the
following
Ranking questions

Put the following in order of importance
Direct Observation
Steps to Observation
 Decide what is to be observed
 Work tasks
 Physical space
 Environmental dynamics (body language, etc).
 Decide at what level or concreteness activities are
to be observed
 Create categories that adequately capture key
activities
 Brainstorm and prepare lists of activities that
might be observed
Direct Observation continued

Prepare appropriate materials for observation

Adjective pairs
 Listing of adjectives and opposites
 During the observation the characteristic
observed is circled

Playscript
 Prepared listing of activities expected to be
observed
 Each time the activity occurs, it is marked

Checklist
 Prepared checklist of expected observations using
a scale (1-5). When activity occurs, a value is
selected.

Anecdotal list
 Short phrases on ongoing activities is
documented.
Direct Observation continued

Decide when to observe

Time and event sampling


Time sampling occurs at specific intervals
Event sampling includes observing an
entire event
Things to remember about
people and their work




People don't always have a completely
accurate appreciation of what they do or how
they do it
People cannot always interpret their own
actions
People may change their behavior when
observed
Direct observation can be used to validate
information obtained using other methods
Summing up Traditional
Methods





Individually interview people informed about the
operation and issues of the current system and needs
for systems in future organizational activities
Survey people via questionnaires to discover issues and
requirements
Interview groups of people with diverse needs to find
synergies and constrasts among system requirements
Observe workers at selected times to see how data are
handled and what information people need to do their
jobs
Study Business documents to discover reported issues,
policies, rules and directions as well as concrete
examples of the use of data and information in the
organization.
Selecting the Appropriate
Techniques
Interviews
JAD
Questionnaires
Document
Analysis
Observation
Type of
Information
As-Is
Improve.
To-Be
As-Is
As-Is
Improve. Improve.
To-Be
As-Is
As-Is
Depth of
Information
High
High
Medium
Low
Low
Breadth of
Information
Low
Medium
High
High
Low
Integration
of Info.
Low
High
Low
Low
Low
User
Medium
Involvement
High
Low
Low
Low
Cost
LowMedium
Medium
Low
Low
LowMedium
PowerPoint Presentation for Dennis, Wixom & Tegardem
Systems Analysis and Design
Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.
New Approaches

New approaches to fact finding include
JAD, GSS, and prototyping.
JAD




The buzz these days is JAD or Joint Application
Development (or Design if you prefer).
IBM is credited with starting JAD in the late 1970s.
The main idea behind JAD is to bring together key
users, system owners, systems analysts and IS staff
to assess desired system requirements.
The primary purpose of JAD is to collect systems
requirements simultaneously from the key people
involved with the system
JAD continued




JAD sessions are structured.
JAD sessions follow an agenda and the intent is to
keep the sessions focused and moving forward.
Much planning goes into these sessions and the
questions to be asked are prepared well in advance.
Facilitator is assigned to monitor the session:
 Keep session on track
 Help with technical terms and jargon
 Record group input
 Help resolve issues
JAD continued


JAD is a formal process. JAD sessions occur in a
short period of time - anywhere between 1 day
and 2 weeks (all meeting times are consecutive).
It is recommended that JAD sessions be held offsite to elicit the full concentration of all
participants.
The main disadvantage attributed to JAD centers
around the fact that JAD sessions include so
many players who have diverse perspectives.
Therefore JAD leaders are often trained in conflict
resolution.
JAD Meeting Room
JPEG Figure 5-5 Goes Here
PowerPoint Presentation for Dennis, Wixom & Tegardem
Systems Analysis and Design
Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.
GSS





GSS are systems designed to support group work.
Such applications as Lotus Notes and Microsoft
NetMeeting are often considered groupware.
These applications provide services to that facilitate
group meetings and group sharing of information.
Actually, it has been suggested that GSS be
considered as mechanism to facilitate JAD.
GSSs were designed to alleviate some of the
problems associated with group meetings. For
instance, most GSSs support the entry of anonymous
comments. Anonymity helps those who fear reprisal
from voicing their opinion.
Prototyping



Prototyping is another hot topic in the area of
systems development and simple prototypes can be
used effectively to determine system requirements.
Prototyping is the building of a small-scale working
model of an information system.
Prototyping, as used in system requirement
determination, is an iterative process whereby the
working model is presented to end users for input,
changes are made based on their input, and the cycle
continues until a final version is agreed upon. The
main consideration is that you must have a model of
a working system so you would have to, at least, go
through some initial fact finding activities.
Prototyping Guidelines
The chances are good that by using prototyping in an
iterative fashion, you will end up with a system more
reflective of user requirements.
A couple of words of caution.
 First, you must remember that the goal of using
prototyping in the determination o f system
requirements is to develop specifications for the
final system, not to build the ultimate system.
 At this stage of the analysis process, you should
be more focused on deciding what the system will
do, not so much on how it will do it.
Prototyping Guidelines
continued


The use of prototyping at the requirements
stage appears to be most effective when
the desired outcomes of the system are
not easy to define.
Prototyping may be better used during the
design phase of the development process
and used to validate articulated system
requirements
Defining the Requirements
– The Structured Way


Once fact finding is completed, system
requirements need to be formalized.
Requirements are cited in a report known as
the requirements document. The complete
requirements document would include
specification and definition of requirements
and models of the system (these will we
investigate in the next lectures). Some
organizations subdivide the document
including a section just for "Functional
Requirements."
Defining Requirements
continued


Another method is to develop a requirements
definition and a requirements specification. The
requirements definition describes system functions in
natural language with associated listings or diagrams
of required services. The intended audience is system
users.
The requirements specification outlines system
services and is usually written as a contract between
the developer and the user. This can be very detailed
but when completed really assist system designers in
completing their work.
Examples from a
Requirements Document
Example of a Requirements Definition:
1. The software must provide a means of
representing and accessing external files
created by other tools.
Example of Requirements
Specification
Example of a Requirements Specification:
1.1 The user should be provided with facilities to define the
type of external files.
1.2 Each external file type may have an associated tool which
may be applied to the file.
1.3 Each external file type may be represented as a specific
icon on the user's display.
1.4 Facilities should be provided for the icon representing an
external file type to be defined by the user.
1.5 When a user selects an icon representing an external file,
the effect of that selection is to apply the tool associated
with the type of the external file to the file represented by
the selected icon.
Additional Examples


Below are links to some examples of Functional Requirements
Documents that should give you a broader view on how different
organizations approach this process:
The link, Functional Requirements Example, points you to a
completed Functional Requirements document from an actual
systems development project. Even though you do not have
contextual knowledge about the project, the document serves as
an example of how one company completes this process. The
format of the document is specified in the systems methodology
employed by this software development company. Note that the
document includes: an Introduction, Objectives of the System,
Assumptions, Description of Functions and Limitations of the
System.
Additional Examples continued



Functional Requirements Document for Uniform Resource
Names from Xerox Corporation: http://www.cis.ohiostate.edu/htbin/rfc/rfc1737.html
Functional Requirements document for the PARTNERS Project,
a multi-state initiative to develop and implement a smartcardbased delivery system to meet the client services needs of a
variety of public health and human service programs :
http://www.newenglandpartners.com/Files/RFP%20Flies/Attachments%20A%20%20F%20&%20I.pdf beginning on page 15
Functional Requirements for the People & Resources
Identification for Distributed Environments (PRIDE) project to
enable access via a single point to a global range of information
resources within the library:
http://www.ukoln.ac.uk/metadata/pride/wp2/d221/
Evolving Requirements






The specification of system requirements is the primary activity
of the analysis phase of systems development.
It results in a description of what the proposed system is to
accomplish.
It provides the input used in the design of the physical system.
The initial development of system requirements is not an ending
point.
Requirements must be validated and reviewed.
Requirements always evolve as a better understanding of user
needs is developed and as the organization's objectives change.
Requirements Validation
It is essential to plan for change in the requirements as the system
is being developed (and used). Validation checks of system
requirements throughout the process include asking the following
questions:

Does the system provide the functions which best
support the customer's needs?

Are there any requirements conflicts?

Are all functions required by the customer included?

Can the requirements be implemented given available
budget and technology?
Next Week

Another Way to Specify User
Requirements USE CASE ANALYSIS
Quotes of the Week


Systems designers and end users will always live on
different planets. This is one of those immutable laws
of nature.
By the time any one individual has the knowledge and
skills to write a complex software system, he/she - or
the organization - will no longer be capable of
understanding how little end users really know, or
want to know, about the underlying technology .
Gantz, "The More Things Change in IT..." in Computerworld,
33(51), December 20, 1999, pg. 32).