Unity University 2022

College of Engineering, Technology and Computational Sciences

Department of Computer Science

Course Title: Structured System Analysis & Design (COSC 2071)

Topic: Determining System Requirements

Topic Contents

3. Determining System Requirements

3.1 Introduction
3.2 Traditional Methods
3.3 Modern Methods
3.4 Radical Methods

Objectives
After studying this chapter, you should be able to:
 Describe options for designing and conducting interviews and develop a plan for
conducting an interview to determine system requirements.
 Explain the advantages and pitfalls of observing workers and analyzing business
documents to determine system requirements.
 Participate in and help plan a joint application design (JAD) session.
 Use prototyping during requirements determination.
 Select the appropriate methods to elicit system requirements.
 Explain business process reengineering (BPR) and how it affects requirements
determination.
 Understand how requirements determination techniques apply to development of systems.

Ephrem Tesfaye Tsidu Page 1

Unity University 2022
3.1 Introduction
Systems analysis is the part of the systems development life cycle in which you determine how a current
information system in an organization functions. Then you assess what users would like to see in a new
system. As you learned in Chapter 1, the two parts to analysis are determining requirements and
structuring requirements. This chapter illustrates the process of determining system requirements.
Techniques used in requirements determination have become more structured over time. As we see in
this chapter, current methods increasingly rely on computers for support. We first study the more
traditional requirements determination methods, which include interviewing, observing users in their
work environment, and collecting procedures and other written documents.
We then discuss modern methods for collecting system requirements. The first of these methods is joint
application design (JAD). Next, you read about how analysts rely more and more on information
systems to help them perform analysis. You learn how prototyping can be used as a key tool for some
requirements determination efforts. We end the chapter with a discussion of how requirements
determination continues to be a major part of systems analysis and design, even when organizational
change is radical, as with business process reengineering, and new, a with developing Internet
applications.
During requirements determination, you and other analysts gather information on what the system
should do from as many sources as possible. Such sources include users of the current system, reports,
forms, and procedures. All of the system requirements are carefully documented and made ready for
structuring. Structuring means taking the system requirements you find during requirements
determination and ordering them into tables, diagrams, and other formats that make them easier to
translate into technical system specifications.
The characteristics you need in order to be a good systems analyst during requirements determination.
These characteristics include:
Impertinence: You should question everything. Ask such questions as “Are all transactions
processed the same way?” “Could anyone be charged something other than the standard price?”
“Might we someday want to allow and encourage employees to work for more than one
department?”
Impartiality: Your role is to find the best solution to a business problem or opportunity. It is
not, for example, to find a way to justify the purchase of new hardware or to insist on
incorporating what users think they want into the new system requirements. You must consider
issues raised by all parties and try to find the best organizational solution.

Ephrem Tesfaye Tsidu Page 2

Unity University 2022
Relaxing of constraints: Assume anything is possible and eliminate the infeasible. For
example, do not accept this statement: “We’ve always done it that way, so we have to continue
the practice.” Traditions are different from rules and policies. Traditions probably started for a
good reason, but as the organization and its environment change, they may turn into habits rather
than sensible procedures.
Attention to details: Every fact must fit with every other fact. One element out of place means
that the ultimate system will fail at some time. For example, an imprecise definition of who a
customer is may mean that you purge customer data when a customer has no active orders; yet
these past customers may be vital contacts for future sales.
Reframing: Analysis is, in part, a creative process. You must challenge yourself to look at the
organization in new ways. Consider how each user views his or her requirements. Be careful
not to jump to this conclusion: “I worked on a system like that once—this new system must
work the same way as the one I built before.”
Deliverables and Outcomes
The primary deliverables from requirements determination are the types of information gathered during
the determination process. The information can take many forms: 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 these deliverables.
In addition, you need to understand the following components of an organization:
o The business objectives that drive what and how work is done
o The information people need to do their jobs
o The data handled within the organization to support the jobs
o When, how, and by whom or what the data are moved, transformed, and stored
o The sequence and other dependencies among different data-handling activities
o The rules governing how data are handled and processed
o Policies and guidelines that describe the nature of the business, the market, and the environment
in which it operates
o Key events affecting data values and when these events occur

Ephrem Tesfaye Tsidu Page 3

Unity University 2022
Types of Deliverables Specific Deliverables Specific deliverables
Information collected from conversations with  Interview transcripts
users  Notes from observations
 Meeting notes
Existing documents and files Business mission  Sample business forms and reports, and
and strategy statement computer displays
 Procedure manuals
 Job descriptions
 Training manuals
 Flowcharts and documentation of existing
systems
 Consultant reports

Computer-based information  Results from joint application design

(JAD) sessions
 CASE repository contents and reports of
existing systems
 Displays and reports from system
prototypes

Ephrem Tesfaye Tsidu Page 4

Unity University 2022
Functional Requirements: These are the requirements that the end user specifically demands as basic
facilities that the system should offer. All these functionalities need to be necessarily incorporated into
the system as a part of the contract. These are represented or stated in the form of input to be given to
the system, the operation performed and the output expected. They are basically the requirements stated
by the user which one can see directly in the final product, unlike the non-functional requirements.
Non-functional requirements: These are basically the quality constraints that the system must satisfy
according to the project contract. The priority or extent to which these factors are implemented varies
from one project to other. They are also called non-behavioral requirements.
They basically deal with issues like:
 Portability
 Security
 Maintainability
 Reliability
 Scalability
 Performance
 Reusability
Functional Requirements Non Functional Requirements
A functional requirement defines a A non-functional requirement defines the quality
system or its component. attribute of a software system.
It specifies “What should the software It places constraints on “How should the software
system do?” system fulfill the functional requirements?”
Functional requirement is specified by Non-functional requirement is specified by technical
User. peoples e.g. Architect, Technical leaders and software
developers.
It is mandatory. It is not mandatory.
It is captured in use case. It is captured as a quality attribute.
Defined at a component level. Applied to a system as a whole.
Helps you verify the functionality of the Helps you to verify the performance of the software.
software.
Functional Testing like System, Non-Functional Testing like Performance, Stress,
Integration, End to End, API testing, etc. Usability, Security testing, etc. are done.
are done.
Usually easy to define. Usually more difficult to define.

Ephrem Tesfaye Tsidu Page 5

Unity University 2022
Examples of functional requirement
1) Authentication of user whenever he/she logs into the system.
2) System shutdown in case of a cyber-attack.
3) A Verification email is sent to user whenever he/she registers for the first time on some software
system.
Examples of non-functional requirement
1) Emails should be sent with a latency of no greater than 12 hours from such an activity.
2) The processing of each request should be done within 10 seconds
3) The site should load in 3 seconds when the number of simultaneous users are > 10000

Let’s take a library management system and list down its functional and non-functional requirements.
Functional requirements of Library management system
 Only authentic user must have the access to the system.
 Only the user must be able to provide the information related to the library.
 User must be able to:
o Provide the information regarding books.
o Search for the required books from database.
o Add new book to the database.
o Update the number of books in database.
o Enter data of issued book in Database.
o Add Information of returned books.
 User must have the knowledge about the no of copies of a book.
 Same Id’s for 2 or more books shall not be allowed.
 User must check if the book is available or not before issuing.
 User must enter issue and return date in database.
 The user must know the number of shelves in the library.
Non-functional requirements of Library management system
 Performance –the Server would be able to perform desired tasks in reasonable unit of time.
 Reliability - the Server would perform desired tasks as expected. The system does its work with
more accuracy like user registration to the system, user validation and authorization, book search
and issue operation, return status, and updating the database by synchronizing between database
and application.

Ephrem Tesfaye Tsidu Page 6

Unity University 2022
 Security - the system would provide access to only legitimate users. It will be secure on network
and only authorized person can use it.
 Scalability - the proposed system would be scalable to support extended number of users.
 Ease of Use - the proposed system would be user-friendly and would provide Graphical User
Interface (GUI).
 Accessibility - the proposed system would be GUI-based desktop application installed on
computing root node (server) running the application.
 Maintainability - the proposed system would be easy to maintain and extend. Minor
modification to the system would not cause harm to the running application.
3.2 Traditional Methods
In this subtopic, you learn about traditional ways to get information directly from those who have the
information you need: interviews and direct observation. You learn about collecting documentation on
the current system and organizational operation in the form of written procedures, forms, reports, and
other hard copy.
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. Others are interviewed to understand organizational direction, policies, and expectations
that managers have of the units they supervise. During interviewing, you gather facts, opinions, and
speculation and observe body language, emotions, and other signs of what people want and how they
assess current systems. Interviewing someone effectively can be done in many ways, and no one
method is necessarily better than another. Some guidelines to keep in mind when you interview are
discussed next.

First, prepare thoroughly before the interview. Set up an appointment at a time and for a duration that
is 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. 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 direct the interview
spontaneously as you discover what expertise the interviewee brings to the session.

Ephrem Tesfaye Tsidu Page 7

Unity University 2022
Prepare an interview guide or checklist so that you know in which sequence to ask your questions and
how much time 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 extent,
integrate your interview guide with the notes you take during the interview. This same guide can serve
as an outline for a summary of what you discover during an interview.
The first page of the sample interview guide contains a general outline of the interview. Besides basic
information on who is being interviewed and when, list major objectives for the interview. These
objectives typically cover the most important data you need to collect, a list of issues on which you
need to seek agreement (e.g., content for certain system reports), and which areas you need to explore.
Also, include reminder notes to yourself on key information about the interviewee (e.g., job history,
known positions taken on issues, and role with current system). This information helps you to be
personal, shows that you consider the interviewee important, and may assist in interpreting some
answers. Also included is an agenda with approximate time limits for different sections of the interview.
You may not follow the time limits precisely, but the schedule helps you cover all areas during the time
the interviewee is available. Space is also allotted for general observations that do not fit under specific
questions and for notes taken during the interview about topics skipped or issues raised that could not
be resolved. On subsequent pages, list specific questions.
Choosing Interview Questions
You need to decide on the mix and sequence of open-ended and closed-ended questions to use. Open-
ended questions are usually used to probe for information when you cannot anticipate all possible
responses or when you do not know the precise question to ask. The person being interviewed is
encouraged to talk about whatever interests him or her within the general bounds of the question. An
example is, “What would you say is the best thing about the information system you currently use to
do your job?” or “List the three most frequently used menu options.” You must react quickly to answers
and determine whether any follow up questions are needed for clarification or elaboration. Sometimes
body language will suggest that a user has given an incomplete answer or is reluctant to provide certain
information. If so, a follow-up question might result in more information. One advantage of open-ended
questions is that previously unknown information can surface. You can then continue exploring along
unexpected lines of inquiry to reveal even more new information. Open-ended questions also often put
the interviewees at ease because they are able to respond in their own words using their own structure.
Open-ended questions give interviewees more of a sense of involvement and control in the interview.
A major disadvantage of open-ended questions is the length of time it can take for the questions to be
answered. They also can be difficult to summarize.

Ephrem Tesfaye Tsidu Page 8

Unity University 2022
Closed-ended questions provide a range of answers from which the interviewee may choose. Here is
an example:
Which of the following would you say is the one best thing about the information system you currently
use to do your job (pick only one)?
a. Having easy access to all of the data you need
b. The system’s response time
c. The ability to run the system concurrently with other applications
Closed-ended questions work well when the major answers to questions are well known. Another plus
is that interviews based on closed-ended questions do not necessarily require a large time
commitment—more topics can be covered.
Closed-ended questions can also be an easy way to begin an interview and to determine which line of
open-ended questions to pursue. You can include an “other” option to encourage the interviewee to add
unexpected responses. A major disadvantage of closed-ended questions is that useful information that
does not quite fit the defined answers may be overlooked as the respondent tries to make a choice
instead of providing his or her best answer.
Like objective questions on an examination, closed-ended questions can follow several forms, including
these choices:
o True or false
o Multiple choice (with only one response or selecting all relevant choices)
o Rating a response or idea on some 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)
o Ranking items in order of importance
Interview Guidelines
First, with either open- or closed-ended questions, do not phrase a question in a way that implies a right
or wrong answer. Respondents must feel free to state their true opinions and perspectives and trust that
their ideas will be considered. Avoid questions such as “Should the system continue to provide the
ability to override the default value, even though most users now do not like the feature?” because such
wording predefines a socially acceptable answer.
Second, listen carefully to what is being said. Take careful notes or, if possible, record the interview on
a tape recorder (be sure to ask permission first!). The answers may contain extremely important
information for the project. Also, this may be your only chance to get information from this particular

Ephrem Tesfaye Tsidu Page 9

Unity University 2022
person. If you run out of time and still need more information from the person you are talking to, ask to
schedule a follow-up interview.
Third, once the interview is over, go back to your office and key in your notes within forty-eight hours
with a word processing program such as Microsoft Word. For numerical data, you can use a spreadsheet
program such as Microsoft Excel. If you recorded the interview, use the recording to verify your notes.
After forty-eight hours, your memory of the interview will fade quickly. As you type and organize your
notes, write down any additional questions that might arise from lapses in your notes or ambiguous
information. Separate facts from your opinions and interpretations. Make a list of unclear points that
need clarification. Call the person you interviewed and get answers to these new questions. Use the
phone call as an opportunity to verify the accuracy of your notes. You may also want to send a written
copy of your notes to the person you interviewed to check your notes for accuracy.
Finally, make sure to thank the person for his or her time. You may need to talk to your respondent
again. If the interviewee will be a user of your system or is involved in some other way in the system’
success, you want to leave a good impression.
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. Many people will have to be interviewed. Choices will have to be
made from among many technically possible alternatives. Let respondents know that their ideas will be
carefully considered. Because of the repetitive nature of the systems development process, however, 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. Talk to several different people: potential users
of the system, users of other systems that might be affected by this new system, managers and superiors,
information systems staff, and others. Encourage people to think about current problems and
opportunities and what new information services might better serve the organization. You want to
understand all possible perspectives so that later you will have information on which to base a
recommendation or design decision that everyone can accept.
Directly Observing Users
Interviewing involves getting people to recall and convey information they have about organizational
processes and the information systems that support them. People, however, are not always reliable, even
when they try to be and say what they think is the truth. As odd as it may sound, people often do not
have a completely accurate appreciation of what they do or how they do it, especially when infrequent
events, issues from the past, or issues for which people have considerable passion are involved. Because

Ephrem Tesfaye Tsidu Page 10

Unity University 2022
people cannot always be trusted to interpret and report their own actions reliably, you can supplement
what people tell you by watching what they do in work situations.
For example, one possible view of how a hypothetical manager does her job is that a manager carefully
plans her activities, works long and consistently on solving problems, and controls the pace of her work.
A manager might tell you that is how she spends her day. Several studies have shown, however, that a
manager’s day is actually punctuated by many, many interruptions. Managers work in a fragmented
manner, focusing on a problem or a communication for only a short time before they are interrupted by
phone calls or visits from subordinates and other managers. An information system designed to fit the
work environment described by our hypothetical manager would not effectively support the actual work
environment in which that manager finds herself.
As another example, consider the difference between what another employee might tell you about how
much he uses electronic mail and how much electronic mail use you might discover through more
objective means. An employee might tell you he is swamped with e-mail messages and spends a
significant proportion of time responding to e-mail messages. However, if you were able to check
electronic mail records, you might find that this employee receives only three e-mail messages per day
on average and that the most messages he has ever received during one eight-hour period is ten. In this
case, you were able to obtain an accurate behavioral measure of how much e-mail this employee copes
with, without having to watch him read his e-mail.
The intent behind obtaining system records and direct observation is the same, however, and that is to
obtain more firsthand and objective measures of employee interaction with information systems. In some
cases, behavioral measures will more accurately reflect reality than what employees themselves believe.
In other cases, the behavioral information will substantiate what employees have told you directly.
Although observation and obtaining objective measures are desirable ways to collect pertinent
information, such methods are not always possible in real organizational settings. Thus, these methods
are not totally unbiased, just as no one data-gathering method is unbiased.
For example, observation can cause people to change their normal operating behavior. Employees who
know they are being observed may be nervous and make more mistakes than normal. On the other hand,
employees under observation may follow exact procedures more carefully than they typically do. They
may work faster or slower than normal. Because observation typically cannot be continuous, you receive
only a snapshot image of the person or task you observe. Such a view may not include important events
or activities. Due to time constraints, you observe for only a limited time, a limited number of people,
and a limited number of sites. Observation yields only a small segment of data from a possibly vast
variety of data sources. Exactly which people or sites to observe is a difficult selection problem. You

Ephrem Tesfaye Tsidu Page 11

Unity University 2022
want to pick both typical and atypical people and sites and observe during normal and abnormal
conditions and times to receive the richest possible data from observation.
Analyzing Procedures and Other Documents
As previously noted, interviewing people who use a system every day or who have an interest in a system
is an effective way to gather information about current and future systems. Observing current system
users is a more direct way of seeing how an existing system operates. Both interviewing and observing
have limitations. Methods for determining system requirements can be enhanced by examining system
and organizational documentation to discover more details about current systems and the organization
they support.
We discuss several important types of documents that are useful in understanding system requirements,
but our discussion is not necessarily exhaustive. In addition to the few specific documents we mention,
other important documents need to be located and considered, including organizational mission
statements, business plans, organization charts, business policy manuals, job descriptions, internal and
external correspondence, and reports from prior organizational studies.
What can the analysis of documents tell you about the requirements for a new system? In documents
you can find information about:
o Problems with existing systems (e.g., missing information or redundant steps)
o Opportunities to meet new needs if only certain information or information processing were
available (e.g., analysis of sales based on customer type)
o Organizational direction that can influence information system requirements (e.g., trying to link
customers and suppliers more closely to the organization)
o Titles and names of key individuals who have an interest in relevant existing systems (e.g., the
name of a sales manager who has led a study of buying behavior of key customers)
o 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)
o 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 who require use of customized customer ordering procedures)
o The reason why current systems are designed as they are, which can suggest features left out of
current software that may now be feasible and desirable (e.g., data about a customer’s purchase
of competitors’ products not available when the current system was designed; these data now
available from several sources)

Ephrem Tesfaye Tsidu Page 12

Unity University 2022
o Data, rules for processing data, and principles by which the organization operates that must be
enforced by the information system (e.g., each customer assigned exactly one sales department
staff member as primary contact if customer has any questions)
One type of useful document is a written work procedure for an individual or a work group. The
procedure describes how a particular job or task is performed, including data and information used and
created in the process of performing the job. For example, the procedure shown in Figure 5-3 includes
data (list of features and advantages, drawings, inventor name, and witness names) required to prepare
an invention disclosure. It also indicates that besides the inventor, the vice president for research, the
department head, and the dean must review the material and that a witness is required for any filing of
an invention disclosure. These insights clearly affect what data must be kept, to whom information must
be sent, and the rules that govern valid forms.
Procedures are not trouble-free sources of information, however. Sometimes your analysis of several
written procedures reveals a duplication of effort in two or more jobs. You should call such duplication
to the attention of management as an issue to be resolved before system design can proceed. That is, it
may be necessary to redesign the organization before the redesign of an information system can achieve
its full benefits. Another problem you may encounter is a missing procedure. Again, it is not your job
to create a document for a missing procedure—that is up to management. A third and common problem
happens when the procedure is out of date, which you may realize in your interview of the person
responsible for performing the task described in the procedure. Once again, the decision to rewrite the
procedure so that it matches reality is made by management, but you may make suggestions based upon
your understanding of the organization. A fourth problem often encountered is that the formal
procedures may contradict information you collected from interviews, questionnaires, and observation
about how the organization operates and what information is required. As in the other cases, resolution
rests with management.
All of these problems illustrate the difference between formal systems and informal systems. A formal
system is one an organization has documented; an informal system is the way in which the organization
actually works. Informal systems develop because of inadequacies of formal procedures and individual
work habits, preferences, and resistance to control. It is important to understand both formal and
informal systems because each provides insight into information requirements and what is necessary to
convert from present to future systems.
A second type of document useful to systems analysts is a business form. Forms are used for all types
of business functions, from recording an order to acknowledging the payment of a bill to indicating

Ephrem Tesfaye Tsidu Page 13

Unity University 2022
what goods have been shipped. Forms are important for understanding a system because they explicitly
indicate what data flow in or out of a system.
A printed form may correspond to a computer display that the system will generate for someone to enter
and maintain data or to display data to online users. The most useful forms contain actual organizational
data that allow you to determine the data characteristics actually used by the application. The ways in
which people use forms change over time, and data that were needed when a form was designed may
no longer be required.
A third type of useful document is a report generated by current systems. As the primary output for
some types of systems, a report enables you to work backward from the information on the report to the
data that must have been necessary to generate it. You analyze such reports to determine which data
need to be captured over what time period and what manipulation of these raw data is necessary to
produce each field on the report.
If the current system is computer based, a fourth set of useful documents is one that describes the current
information systems—how they were designed and how they work. Several different types of
documents fit this description, everything from flowcharts to data dictionaries to user manuals. An
analyst who has access to such documents is fortunate because many in-house-developed information
systems lack complete documentation. Analysis of organizational documents and observation, along
with interviewing and distributing questionnaires, are the methods used most for gathering system
requirements.
3.3 Modern Methods
Even though we called interviews, questionnaires, observation, and document analysis traditional
methods for determining a system’s requirements, all of these methods are still used by analysts to
collect important information. Today, however, additional techniques are available to collect
information about the current system, the organizational area requesting the new system, and what the
new system should be like. In this section, you learn about two modern information-gathering
techniques for analysis: joint application design (JAD) and prototyping. These techniques can support
effective information collection and structuring while reducing the amount of time required for analysis.
Joint Application Design
In the late 1970s, systems development personnel at IBM developed a new process for collecting
information system requirements and reviewing system designs. The process is called joint application
design (JAD). The idea behind JAD is to structure the requirements determination phase of analysis
and the reviews that occur as part of the design. Users, managers, and systems developers are brought
together for a series of intensive structured meetings run by a JAD session leader. By gathering the

Ephrem Tesfaye Tsidu Page 14

Unity University 2022
people directly affected by an IS in one room at the same time to work together to agree on system
requirements and design details, time and organizational resources are better managed. Group members
are more likely to develop a shared understanding of what the IS is supposed to do.
The primary purpose of using JAD in the analysis phase is to collect systems requirements
simultaneously from the key people involved with the system. The result is an intense and structured,
but highly effective, process. Having all the key people together in one place at one time allows analysts
to see the areas of agreement and the areas of conflict. Meeting with all these important people for over
a week of intense sessions allows you the opportunity to resolve conflicts or at least to understand why
a conflict may not be simple to resolve.
JAD sessions are usually conducted in a location away from where the people involved normally work,
in order to limit distractions and help participants better concentrate on systems analysis. A JAD may
last anywhere from four hours to an entire week and may consist of several sessions. A JAD employs
thousands of dollars of corporate resources, the most expensive of which is the time of the people
involved. Other expenses include the costs associated with flying people to a remote site and putting
them up in hotels and feeding them for several days.
The following is a list of typical JAD participants:
JAD session leader: The JAD leader organizes and runs the JAD. This person has been trained in
group management and facilitation as well as in systems analysis. The JAD leader sets the agenda and
sees that it is met. He or she remains neutral on issues and does not contribute ideas or opinions, but
rather concentrates on keeping the group on the agenda, resolving conflicts and disagreements, and
soliciting all ideas.
 Users: The key users of the system under consideration are vital participants in a JAD. They are
the only ones who clearly understand what it means to use the system on a daily basis.
 Managers: Managers of the work groups who use the system in question provide insight into
new organizational directions, motivations for and organizational impacts of systems, and
support for requirements determined during the JAD.
 Sponsor: As a major undertaking, because of its expense, a JAD must be sponsored by someone
at a relatively high level in the company such as a vice president or chief executive officer. If
the sponsor attends any sessions, it is usually only at the beginning or the end.
 Systems analysts: Members of the systems analysis team attend the JAD, although their actual
participation may be limited. Analysts are there to learn from users and managers, not to run or
dominate the process.

Ephrem Tesfaye Tsidu Page 15

Unity University 2022
 Scribe: The scribe takes notes during the JAD sessions, usually on a personal computer or
laptop.
 IS staff: Besides systems analysts, other IS staff, such as programmers, database analysts, IS
planners, and data-center personnel, may attend the session. Their purpose is to learn from the
discussion and possibly to contribute their ideas on the technical feasibility of proposed ideas
or on the technical limitations of current systems.
JAD sessions are usually held in special-purpose rooms where participants sit around horseshoe-shaped
tables. These rooms are typically equipped with whiteboards (possibly electronic, with a printer to make
copies of what is written on the board). Other audiovisual tools may be used, such as magnetic symbols
that can be easily rearranged on a whiteboard, flip charts, and computer-generated displays. Flip-chart
paper is typically used for keeping track of issues that cannot be resolved during the JAD, or for those
issues requiring additional information that can be gathered during breaks in the proceedings.
Computers may be used to create and display form or report designs or to diagram existing or
replacement systems. In general, however, most JADs do not benefit much from computer support. The
end result of a completed JAD is a set of documents that detail the workings of the current system and
the features of a replacement system. Depending on the exact purpose of the JAD, analysts may gain
detailed information on what is desired of the replacement system.
Taking Part in a JAD
Imagine that you are a systems analyst taking part in your first JAD. What might participating in a JAD
be like? Typically, JADs are held off-site, in comfortable conference facilities. On the first morning of
the JAD, you and your fellow analysts walk into a room that looks much like the one depicted in Figure
5-6. The JAD facilitator is already there. She is finishing writing the day’s agenda on a flip chart. The
scribe is seated in a corner with a laptop, preparing to take notes on the day’s activities. Users and
managers begin to enter in groups and seat themselves around the U-shaped table. You and the other
analysts review your notes describing what you have learned so far about the information system you
are all there to discuss. The session leader opens the meeting with a welcome and a brief rundown of
the agenda. The first day will be devoted to a general overview of the current system and major problems
associated with it. The next two days will be devoted to an analysis of current system screens. The last
two days will be devoted to analysis of reports.
The session leader introduces the corporate sponsor, who talks about the organizational unit and current
system related to the systems analysis study and the importance of upgrading the current system to meet
changing business conditions. He leaves and the JAD session leader takes over. She yields the floor to

Ephrem Tesfaye Tsidu Page 16

Unity University 2022
the senior analyst, who begins a presentation on key problems with the system, which have already been
identified. After the presentation, the session leader opens the discussion to the users and managers in
the room.
After a few minutes of talk, a heated discussion begins between two users from different corporate
locations. One user, who represents the office that served as the model for the original systems design,
argues that the system’s perceived lack of flexibility is really an asset, not a problem. The other user,
who represents an office that was part of another company before a merger, argues that the current
system is so inflexible as to be virtually unusable. The session leader intervenes and tries to help the
users isolate particular aspects of the system that may contribute to the system’s perceived lack of
flexibility.
Questions arise about the intent of the original developers. The session leader asks the analysis team
about their impressions of the original system design. If these questions cannot be answered during this
meeting because none of the original designers are present nor are the original design documents readily
available, the session leader assigns the question about intent to the “to-do” list. This question becomes
the first item on a flip-chart sheet of to-do items, and the session leader gives you the assignment of
finding out about the intent of the original designers. She writes your name next to the to-do item on
the list and continues with the session. Before the end of the JAD, you must get an answer to this
question.
The JAD will continue in this manner for its duration. Analysts will make presentations, help lead
discussions of form and report design, answer questions from users and managers, and take notes on
what is being said. After each meeting, the analysis team will meet, usually informally, to discuss what
has occurred that day and to consolidate what they have learned. Users will continue to contribute during
the meetings, and the session leader will facilitate, intervening in conflicts, seeing that the group follows
the agenda. When the JAD is over, the session leader and her assistants must prepare a report that
documents the findings in the JAD and then circulate it among users and analysts.
Prototyping
Designing and building a scaled-down but working version of a desired system is known as prototyping.
A prototype can be developed with a CASE tool, a software product that automates steps in the systems
development life cycle. The analyst works with users to determine the initial or basic requirements for
the system. The analyst then quickly builds a prototype. When the prototype is completed, the users
work with it and tell the analyst what they like and do not like about it. The analyst uses this feedback
to improve the prototype and takes the new version back to the users. This iterative process continues
until the users are relatively satisfied with what they have seen. The key advantages of the prototyping

Ephrem Tesfaye Tsidu Page 17

Unity University 2022
technique are: (1) it involves the user in analysis and design, and (2) it captures requirements in concrete,
rather than verbal or abstract, form. In addition to being used as a stand-alone, prototyping may also be
used to augment the SDLC. For example, a prototype of the final system may be developed early in
analysis to help the analysts identify what users want. Then the final system is developed based on the
specifications of the prototype.
In this section, we see how prototyping can augment the requirements determination process. To
establish requirements for prototyping, you still have to interview users and collect documentatio.
Prototyping, however, allows you to quickly convert basic requirements into a working, though limited,
version of the desired information system. The user then views and tests the prototype. Typically, seeing
verbal descriptions of requirements converted into a physical system prompts the user to modify
existing requirements and generate new ones. For example, in the initial interviews, a user might have
said he wanted all relevant utility billing information on a single computer display form, such as the
client’s name and address, the service record, and payment history. Once the same user sees how
crowded and confusing such a design would be in the prototype, he might change his mind and instead
ask for the information to be organized on several screens but with easy transitions from one screen to
another. He might also be reminded of some important requirements (data, calculations, etc.) that had
not surfaced during the initial interviews.
You would then redesign the prototype to incorporate the suggested changes. Once modified, users
would again view and test the prototype. Once again, you would incorporate their suggestions for
change. Through such a repetitive process, the chances are good that you will be able to better capture
a system’s requirements. The goal with using prototyping to support requirements determination is to
develop concrete specifications for the ultimate system, not to build the ultimate system.
Prototyping is most useful for requirements determination when:
 User requirements are not clear or well understood, which is often the case for totally new
systems or systems that support decision making.
 One or a few users and other stakeholders are involved with the system.
 Possible designs are complex and require concrete form to evaluate fully.
 Communication problems have existed in the past between users and analysts, and both parties
want to be sure that system requirements are as specific as possible.
 Tools (such as form and report generators) and data are readily available to rapidly build
working systems.

Ephrem Tesfaye Tsidu Page 18

Unity University 2022
Prototyping also has some drawbacks as a tool for requirements determination. They include the
following:
X A tendency to avoid creating formal documentation of system requirements, which can then make
the system more difficult to develop into a fully working system.
X Prototypes can become idiosyncratic to the initial user and difficult to diffuse or adapt to other
potential users.
X Prototypes are often built as stand-alone systems, thus ignoring issues of sharing data and
interactions with other existing systems.
X Checks in the SDLC are bypassed so that some more subtle, but still important, system
requirements might be forgotten (e.g., security, some data-entry controls, or standardization of
data across systems).
3.4 Radical Methods
The overall process by which current methods are replaced with radically new methods is referred to as
business process reengineering (BPR). The search for, and implementation of, radical change in
business processes to achieve breakthrough improvements in products and services.
To better understand BPR, consider the following analogy. Suppose you are a successful European
golfer who has tuned your game to fit the style of golf courses and weather in Europe. You have learned
how to control the flight of the ball in heavy winds, roll the ball on wide-open greens, putt on large and
undulating greens, and aim at a target without the aid of the landscaping common on North American
courses. When you come to the United States to make your fortune on the U.S. tour, you discover that
improving you’re putting, driving accuracy, and sand shots will help, but the new competitive
environment is simply not suited to your playing style. You need to reengineer your whole approach,
learning how to aim at targets, spin and stop a ball on the green, and manage the distractions of crowds
and press. If you are good enough, you may survive, but without reengineering, you will never become
a winner.
BPR advocates suggest that radical increases in the quality of business processes can be achieved through
creatively applying information technologies. BPR advocates also suggest that radical improvement
cannot be achieved by making minor changes in existing processes but rather by using a clean sheet of
paper and asking, “If we were a new organization, how would we accomplish this activity?” Changing
the way work is performed also changes the way information is shared and stored, which means that the
results of many BPR efforts are the development of information system maintenance requests, or
requests for system replacement. You likely have encountered or will encounter BPR initiatives in your

Ephrem Tesfaye Tsidu Page 19

Unity University 2022
own organization. A recent survey of IS executives found that they view BPR to be a top IS priority for
the coming years.
Identifying Processes to Reengineer
A first step in any BPR effort is to understand what processes need to change, what are the key business
processes for the organization. Key business processes are the structured set of measurable activities
designed to produce a specific output for a particular customer or market. The important aspect of this
definition is that key processes are focused on some type of organizational outcome such as the creation
of a product or the delivery of a service. Key business processes are also customer focused. In other
words, key business processes would include all activities used to design, build, deliver, support, and
service a particular product for a particular customer. BPR, therefore, requires you first to understand
those activities that are part of the organization’s key business processes and then to alter the sequence
and structure of activities to achieve radical improvements in speed, quality, and customer satisfaction.
The same techniques you learned to use for system requirements determination can be applied to
discovering and understanding key business processes: interviewing key individuals, observing
activities, reading and studying organizational documents, and conducting JAD sessions.
After identifying key business processes, the next step is to identify specific activities that can be
radically improved through reengineering. Michael Hammer and James Champy, two academics who
coined the term BPR, suggest systems analysts ask three questions to identify activities for radical
change:
1. How important is the activity to delivering an outcome?
2. How feasible is changing the activity?
3. How dysfunctional is the activity?
The answers to these questions provide guidance for selecting which activities to change. Those activities
deemed important, changeable, yet dysfunctional, are primary candidates for alteration.
Disruptive Technologies
Once key business processes and activities have been identified, information technologies must be
applied to improve business processes radically. Hammer and Champy suggest that organizations think
“inductively” about information technology. Induction is the process of reasoning from the specific to
the general, which means that managers must learn about the power of new technologies and think of
innovative ways to alter the way work is done.

Ephrem Tesfaye Tsidu Page 20

Unity University 2022

Self-Assessment
I. Fill in the blanks
1. ………………..is the search for, and implementation of, radical change in business processes to
achieve breakthrough improvements in products and services.
2. ………………….is the person who makes detailed notes of the happenings at a joint application
design session.
3. …………….are questions in interviews and on questionnaires that ask those responding to
choose from among a set of specified responses.
4. ……………………..questions in interviews and on questionnaires that have no prespecified
answers.

II. Short answer type questions

1. Describe systems analysis and the major activities that occur during this phase of the systems
development life cycle.
2. What are some useful character traits for an analyst involved in requirements determination?
3. Describe three traditional techniques for collecting information during analysis. When might one
be better than another?
4. What are the general guidelines for conducting interviews?
5. What is JAD? How is it better than traditional information-gathering techniques? What are its
weaknesses?
6. Describe how prototyping can be used during requirements determination. How is it better or
worse than traditional methods?

_______________The End! _______________

Ephrem Tesfaye Tsidu Page 21