Determining system requirements
Introduction
We have traditional requirements determination methods, like: interviewing, using
questionnaires, observing users in their work environment, and collecting procedures and
other written documents. And we have modern methods for collecting system requirements
(computer aided ones), like: joint requirements planning (JRP), group support systems, CASE
tools, discovery prototyping.
Performing requirements determination
Information on what the new system should do is gathered from as many sources as possible:
users of current system, from observing users, from the reports, forms and procedures. All this
is documented and made ready for structuring.
Main characteristics of a good systems analyst:
-
impertinence (ask questions about everything that exists and also about what may exist in
the future),
-
impartiality (find the best solution to a business problem or opportunity – consider issues
raised by all parties),
-
relax constraints (eliminate unfeasibility, assume that anything is possible, traditions may
not always be reasonable),
-
attention to details (everything must fit together so that the system works properly),
-
reframing (every system is different and needs a new creative approach).
The primary deliverables from requirements determination are various forms of information
gathered during the determination process: transcripts of interviews, notes from observations
and analysis of documents, analyzed responses from questionnaires, sets of forms, reports, job
descriptions, or computer-generated output such as system prototypes. We could group all this
information in three groups:
-
info collected from conversations with or observations of users (interview transcripts,
notes form observations etc.)
1
Information Systems Analysis
Karolina Muszyńska
-
existing written information (business mission or strategy, forms, reports, training
manuals, flow charts and documentation of existing system etc.)
-
computer-based information (results from JRP sessions, CASE repository contents)
Traditional methods for determining requirements
List of traditional methods:
1. individual interviews (listening) – open-ended and closed-ended questions (pros and
cons), interview guidelines (no good or bad answers, listen carefully and take notes or
record, organize notes within 48 h, don’t promise anything about the system if it is not
sure, make variety of perspectives from the interviews). Pros of interviews: effective way
of communicating and obtaining info. Cons: expensive and time-consuming, limited
number of questions and people can be covered.
2. questionnaires – choosing respondents (convenient, random, purposeful, stratified
sample); designing questionnaires. Pros of questionnaires: not expensive, gathering info
from many people in relatively short time and less biased in interpretation of the results.
Cons: passive and have lower depth of understanding, no follow-up questions are
possible, no additional opportunity to judge the responses (body language, eye contact,
etc.).
3. group interviews – advantages: more effective use of time than individual interviews,
possibility of confrontation and discussion between interviewees (makes it easy to find
agreement and diversity areas). Disadvantages: difficult to schedule (video conferences
solve much). Group interviews are the core of JRP process.
4. workers’ observation – pros: more accurate reflection of reality, objective measures of
employee interaction with information system; cons: observation may cause people act
differently, limited time and number of people.
5. studying of business documents – in order to discover more details about current system
and the organization (existing problems, opportunities, organizational direction, titles and
names of key individuals, values of certain individuals or organization, special
information processing circumstances, reason why the current system is designed as it is,
data, rules for processing data). Written work procedure for an individual or work group
is very useful document. Problems with procedures (duplicate, missing, out of date or
contradicting reality) should be solved by the management not the analysts. Both formal
2
Information Systems Analysis
Karolina Muszyńska
and informal systems (procedures) should be considered. Business forms are also very
useful (what data flow in and out of the system, what kind of data and which are
necessary). Report generated by current system may also be useful. If the current system
is computer-based than we may use: flow charts, data dictionaries, CASE tool reports,
user manuals.
Modern methods for determining system requirements
Main idea behind JRP is to bring together the key users, managers and systems analysts
involved in the analysis of the current system (similar to group interview). But JRP follows a
particular structure of roles and agenda, which enables to collect systems requirements from
all the key people simultaneously. Typical participants:
-
JRP session leader – sets and supervises agenda and is neutral
-
users – key users of the system, who know the most about it
-
managers – they provide insight into new organizational directions, motivations for the
system
-
sponsor – someone at a relatively high level of the company who pays
-
system analysts – they are there to learn from users and managers, and not to dominate the
process
-
scribe – a person who takes notes
-
IS staff – other staff like programmers, or database analysts (they know some technical
limitations or ideas)
JRP sessions are usually held in special rooms with special equipment. Upper CASE tools can
be used during JRP (diagramming tools, display and report generation tools) in order to give
graphic form to system requirements, show it to users and make changes based on their
reactions. Also prototyping tools are good for presenting users with graphic illustrations of
what the alternative systems will look like.
Also group support systems may be used to support JRP sessions (because there are some
typical group meeting problems). Instead of giving everyone a few minutes to talk all
members of the group type their comments into computers and may see what everyone else
has been typing, but the comments are anonymous so bosses can also be criticized. Pros:
everyone has a chance to “say” something, important ideas are less likely to be missed, and
3
Information Systems Analysis
Karolina Muszyńska
poor ideas more likely to be criticized. Cons: leader has lower ability to resolve conflicts and
the session may become less structured.
Discovery prototyping allows to quickly convert basic requirements (obtained during i.e.
interviews) into a working, though limited version of the desired information system. The
prototype will then be viewed and tested by the user and changes will be introduced. And this
will be repeated until all concrete specifications for the ultimate system are developed.
Prototyping is mostly useful when:
-
user requirements are not clear or well understood,
-
one or a few users are involved,
-
possible designs are complex and must be concrete,
-
there are communication problems,
-
tools for prototyping are available.
Disadvantages of discovery prototyping: tendency to avoid creating documentation of system
requirements, prototypes may be too specific (based on a certain user’s taste), prototypes
ignore issues of sharing data with other systems (stand-alone systems), some important
requirements may be missed.
Questions:
1. Name four traditional techniques for collecting information during analysis. Give the
advantages and disadvantages of each method.
2. What is JRP and who takes part in a JRP session?
3. How has computing been used to support JRP?
4. What benefits do GSS provide?
5. Which type of CASE tools are appropriate for use during requirements determination?
6. What are the advantages and disadvantages of discovery prototyping?
4
Information Systems Analysis
Karolina Muszyńska