Lecture 2: Chapter 6

Determining System Requirements

Systems analysis is the part of the systems development life cycle in which you determine how
the current information system functions and assess what users would like to see in a new
system. Analysis has two subphases: requirements determination and requirements structuring.
In this chapter, you will learn about determining system requirements. Techniques used in
requirements determination have evolved over time to become more structured and increasingly
rely on computer support. We will first study the more traditional requirements determination
methods, including interviewing, observing users in their work environment, and collecting
procedures and other written documents. We will then discuss more current methods for
collecting system requirements. The first of these methods is Joint Application Design (JAD).
Next, you will read about how analysts rely more and more on information systems to help them
perform analysis. As you will see, CASE tools, are useful in requirements determination, and
prototyping has become a key tool for some requirements determination efforts. Finally, you will
learn how requirements analysis continues to be an important part of systems analysis and
design, whether the approach involves business process redesign, new Agile techniques (such as
constant user involvement or usage-centered design), or focuses on developing Internet
applications.

Performing Requirements Determination

As shown in Figure, there are two subphases to systems analysis: requirements determination
and requirements structuring. We will address these as separate steps, but you should consider
the steps as parallel and iterative. For example, as you determine some aspects of the current and
desired system(s), you begin to structure these requirements or build prototypes to show users
how a system might behave. Inconsistencies and deficiencies discovered through structuring and
prototyping lead you to explore further the operation of current system(s) and the future needs of
the organization. Eventually, your ideas and discoveries converge in a thorough and accurate
depiction of current operations and requirements for the new system. As you think about
beginning the analysis phase, you are probably wondering what exactly is involved in
requirements determination. We discuss this process in the next section.

1
Systems development life cycle with analysis phase highlighted

Once management has granted permission to pursue development of a new system (this was
done at the end of the project identification and selection phase of the SDLC) and a project is
initiated and planned, you begin determining what the new system should do. During
requirements determination, you and other analysts gather information on what the system
should do from as many sources as possible: from users of the current system; from observing
users; and from reports, forms, and procedures.

Good Systems Analyst Characteristics:

In many ways, gathering system requirements is like conducting any investigation. Have you
read any of the Sherlock Holmes or similar mystery stories? Do you enjoy solving puzzles?
From these experiences, we can detect some similar characteristics for a good systems analyst
during the requirements determination subphase. These characteristics include the following:

 Impertinence. You should question everything.

 Impartiality. consider all issues to find the best organizational solution. You must
consider issues raised by all parties and try to find the best organizational solution.
 Relax constraints. Assume that anything is possible and eliminate the infeasible.
 Attention to details. Every fact must fit with every other fact.
 Reframing. Analysis is, in part, a creative process. You must challenge yourself to look at
the organization in new ways. You must consider how each user views his or her

2
requirements. You must be careful not to jump to the following conclusion: “I worked on
a system like that once—this new system must work the same way as the one I built
before.
Deliverables for Requirements Determination:

The primary deliverables from requirements determination are the various forms of information
gathered during the determination process: transcripts of interviews; notes from observation and
analysis of documents; sets of forms, reports, job descriptions, and other documents; and
computer-generated output such as system prototypes. In short, anything that the analysis team
collects as part of determining system requirements is included in the deliverables resulting from
this subphase of the systems development life cycle.
The table lists examples of some specific information that might be gathered during
requirements determination.
These deliverables contain the information you need for systems analysis within the scope of the
system you are developing. In addition, you need to understand the following components of an
organization:
 The business objectives that drive what and how work is done
 The information people need to do their jobs
 The data (definition, volume, size, etc.) handled within the organization to support the
jobs
 When, how, and by whom or what the data are moved, transformed, and stored
 The sequence and other dependencies among different data-handling activities
 The rules governing how data are handled and processed
 Policies and guidelines that describe the nature of the business and the market and
environment in which it operates
3
 Key events affecting data values and when these events occur

Traditional Methods for Determining Requirements:

At the core of systems analysis is the collection of information. At the outset, you must
collect information about the information systems that are currently being used and how
users would like to improve the current systems and organizational operations with new or
replacement information systems. One of the best ways to get this information is to talk to
the people who are directly or indirectly involved in the different parts of the organizations
affected by the possible system changes: users, managers, funders, and so on. Another way to
find out about the current system is to gather copies of documentation relevant to current
systems and business processes. In this chapter, you will learn about various ways to get
information directly from stakeholders: interviews, group interviews, the Nominal Group
Technique, and direct observation. You will learn about collecting documentation on the
current system and organizational operation in the form of written procedures, forms, reports,
and other hard copy. These traditional methods of collecting system requirements are listed
in Table 6-2.
A-Interviewing and Listening:
Interviewing is one of the primary ways analysts gather information about an information
systems project. Early in a project, an analyst may spend a large amount of time interviewing
people about their work, the information they use to do it, and the types of information
processing that might supplement their work.
Other stakeholders are interviewed to understand organizational direction, policies, expectations
managers have on the units they supervise, and other nonroutine aspects of organizational

4
operations. During interviewing you will gather facts, opinions, and speculation and observe
body language, emotions, and other signs of what people want and how they assess current
systems.
There are many ways to effectively interview someone, and no one method is necessarily better
than another. Some guidelines you should keep in mind when you interview, summarized in
Table 6-3,

First, you should prepare thoroughly before the interview. Set up an appointment at a time and
for a duration convenient for the interviewee. The general nature of the interview should be
explained to the interviewee in advance. You may ask the interviewee to think about specific
questions or issues or to review certain documentation to prepare for the interview. You should
spend some time thinking about what you need to find out and write down your questions. Do
not assume that you can anticipate all possible questions. You want the interview to be natural,
and, to some degree, you want to spontaneously direct the interview as you discover what
expertise the interviewee brings to the session.
You should prepare an interview guide (form) or checklist so that you know in which sequence
you intend to ask your questions and how much time you want to spend in each area of the
interview. The checklist might include some probing questions to ask as follow-up if you receive
certain anticipated responses. You can, to some degree, integrate your interview guide with the
notes you take during the interview,
Choosing Interview Questions:

5
 Each question in an interview guide can include both verbal and non-verbal information.
 Open-ended questions: questions that have no prespecified answers
 Closed-ended questions: questions that ask those responding to choose from
among a set of specified responses
You need to decide what mix and sequence of open-ended and closed-ended questions you will
use. Open-ended questions are usually used to probe for information for which you cannot
anticipate all possible responses or for which you do not know the precise question to ask.
Closed-ended questions provide a range of answers from which the interviewee may choose.
Closed-ended questions, like objective questions on an examination, can follow several forms,
including the following choices:
• True or false.
• Multiple choice (with only one response or selecting all relevant choices).
• Rating a response or idea on a scale, say from bad to good or strongly agree to strongly
disagree. Each point on the scale should have a clear and consistent meaning to each person, and
there is usually a neutral point in the middle of the scale.
• Ranking items in order of importance.
Interviewing Guidelines
■ don’t phrase a question in a way that implies a right or wrong answer.
■ Listen very carefully.
■ Type interview notes within 48 hours after the interview.
■Don't set expectations about the new system unless you know these will be deliverables.
■ Seek a variety of perspectives from the interviews.

 First, with either open- or closed-ended questions, do not phrase a question in a way that
implies a right or wrong answer.

 The second guideline to remember about interviews is to listen very carefully to what is
being said. Take careful notes or, if possible, record the interview (be sure to ask
permission first!). The answers may contain extremely important information for the
project. Also, this may be the only chance you have to get information from this
particular person. If you run out of time and still need to get information from the person
you are talking to, ask to schedule a follow-up interview.

6
 Third, once the interview is over, go back to your office and type up your notes within 48
hours. If you recorded the interview, use the recording to verify the material in your
notes. After 48 hours, your memory of the interview will fade quickly.

 Fourth, be careful during the interview not to set expectations about the new or
replacement system unless you are sure these features will be part of the delivered
system. Let the interviewee know that there are many steps to the project and the
perspectives of many people need to be considered, along with what is technically
possible. Let respondents know that their ideas will be carefully considered, but that due
to the iterative nature of the systems development process, it is premature to say now
exactly what the ultimate system will or will not do.

 Fifth, seek a variety of perspectives from the interviews.

 Drawbacks to individual interviews:

 Contradictions and inconsistencies between interviewees
 Follow-up discussions are time consuming
 New interviews may reveal new questions that require additional interviews with
those interviewed earlier

Interviewing Groups
 Interviewing several key people together
Advantages
 More effective use of time
 Can hear agreements and disagreements at once
 Opportunity for synergies ‫فرصة للتأزر‬
Disadvantages
 More difficult to schedule than individual interviews

Nominal Group Technique (NGT): special type of interview group

 A facilitated process that supports idea generation by groups
 Process
 Members come together as a group, but initially work separately.

7
 Each person writes ideas.
 Facilitator reads ideas out loud, and they are written on a blackboard or flipchart.
 Group openly discusses the ideas for clarification.
 Ideas are prioritized, combined, selected, reduced.
 NGT exercise used to complement group meetings or as part of JAD effort.
B-Directly Observing Users: interview in their jobs
 Watching users do their jobs
 Obtaining more firsthand and objective measures of employee interaction with
information systems
 Can cause people to change their normal operating behavior
 Time-consuming and limited time to observe
C-Analyzing Procedures and Other Documents:
 Document Analysis
 Review of existing business documents
 Can give a historical and “formal” view of system requirements
What can the analysis of documents tell you about the requirements for a new system? In
documents you can find information about the following:
 Types of information to be discovered:
• Problems with existing systems (e.g., missing information or redundant steps)
• Opportunities to meet new needs if only certain information or information processing were
available (e.g., analysis of sales based on customer type)
• Organizational direction that can influence information system requirements
(e.g., trying to link customers and suppliers more closely to the organization)
• Titles and names of key individuals who have an interest in relevant existing systems (e.g., the
name of a sales manager who led a study of the buying behavior of key customers)
• Values of the organization or individuals who can help determine priorities for different
capabilities desired by different users (e.g., maintaining market share even if it means lower
short-term profits)
• Special information processing circumstances that occur irregularly that may not be identified
by any other requirements determination technique (e.g., special handling needed for a few
large-volume customers that requires use of customized customer ordering procedures)

8
• The reason why current systems are designed as they are, which can suggest features left out
of current software, which may now be feasible and more desirable (e.g., data about a
customer’s purchase of competitors’ products were not available when the current system was
designed; these data are now available from several sources)
• Data, rules for processing data, and principles by which the organization operates that must be
enforced by the information system (e.g., each customer is assigned exactly one sales
department staff member as a primary contact if the customer has any questions)
 Useful document: Written work procedure
 For an individual or work group
 Describes how a particular job or task is performed
 Includes data and information used and created in the process
 Potential Problems with Procedure Documents:
 May involve duplication of effort.
 May have missing procedures.
 May be out of date.
 May contradict information obtained through interviews.
 Formal Systems: the official way a system works as described in organizational
documentation (i.e. work procedure)
 Informal Systems: the way a system actually works (i.e. interviews, observations)
Useful document: Business form
 Used for all types of business functions
 Explicitly indicate what data flow in and out of a system and data necessary for the
system to function
 Gives crucial information about the nature of the organization
 Useful document: Report
 Primary output of current system
 Enables you to work backwards from the report to the data needed to generate it
Sum. Useful document: Description of current information system

9
10
2-Contemporary Methods for Determining System Requirements
 Joint Application Design (JAD)
 Brings together key users, managers, and systems analysts
 Purpose: collect system requirements simultaneously from key people
 Conducted off-site
 Started by IBM in 1970s
 Intensive group-oriented requirements determination technique
 Team members meet in isolation for an extended period of time
 Highly focused
 Resource intensive
 Group Support Systems
 Facilitate sharing of ideas and voicing of opinions about system requirements

Illustration of the typical room layout for a JAD

JAD Participants:
 Session Leader: facilitates group process
 Users: active, speaking participants
 Managers: active, speaking participants
 Sponsor: high-level champion, limited participation
 Systems Analysts: should mostly listen

11
 Scribe: record session activities
 IS Staff: should mostly listen
End Result of JAD session
 Documentation detailing existing system
 Features of proposed system
CASE Tools during JAD: For requirements determination and structuring, the most useful
CASE tools are for diagramming and form and report generation.
 Used to analyze existing systems
 Help discover requirements to meet changing business conditions
 Diagramming and form-building CASE tools are used
 Enables analysts to enter system models directly into CASE during the JAD session
 Screen designs and prototyping can be done during JAD and shown to users.
Using Prototyping during Requirements Determination: System prototypes
 Iterative development process
 Rudimentary working version of system is built
 Refine understanding of system requirements in concrete terms
Prototyping is an iterative process involving analysts and users whereby a rudimentary version
of an information system is built and rebuilt according to user feedback. Prototyping can replace
the systems development life cycle or augment it.
 Quickly converts requirements to working version of system
 Once the user sees requirements converted to system, will ask for modifications or will
generate additional requests.

12
The prototyping methodology
 Types:
Evolutionary prototyping - prototype becomes the basis of the operational system
 Prototype needs to be built in order to address the functional needs of the production
system (e.g. database processing and coding logic).
Throwaway prototyping - prototype is just a model, discarded after use
 Prototype is just a mockup of screens shots an simple functionality, and production
system will be built from scratch.
 Most useful when:
 User requests are not clear.
 Few users are involved in the system.
 Designs are complex and require concrete form.
 There is a history of communication problems between analysts and users.
 Tools are readily available to build prototype.
 Drawbacks
 Tendency to avoid formal documentation
 Difficult to adapt to more general user audience
 Sharing data with other systems is often not considered
 Systems Development Life Cycle (SDLC) checks are often bypassed
3-Radical Methods for Determining System Requirements

 Business Process Reengineering (BPR): search for and implementation of radical

change in business processes to achieve breakthrough improvements in products and
services
 Goals
 Reorganize complete flow of data in major sections of an organization.
 Eliminate unnecessary steps.
 Combine steps.
 Become more responsive to future change
 Identification of processes to reengineer
 Key business processes

13
 Structured, measured set of activities designed to produce specific output
for a particular customer or market
 Focused on customers and outcome
Requirements Determination using Agile Methodologies:
1- Continual user involvement
2- Agile usage-centered design
3- The Planning Game

1- Continual user involvement

 Replace traditional SDLC waterfall with iterative analyze – design – code – test
cycle
For each features in the system, sorted in priority

The iterative analysis–design–code–test cycle

2- Agile Usage-Centered Design Steps
 Focuses on user goals, roles, and tasks
 Gather group of programmers, analysts, users, testers, facilitator.
 Document complaints of current system.
 Determine important user roles.
 Determine, prioritize, and describe tasks for each user role.
 Group similar tasks into interaction contexts.
 Associate each interaction context with a user interface for the system, and prototype
the interaction context.

14
 Step through and modify the prototype.

3- The Planning Game

 Based on eXtreme programming
 Exploration, steering, commitment

15