Systems Analysis and Design in a Changing World, sixth edition 2-1

Chapter 2 - Investigating System Requirements

Table of Contents
 Chapter Overview
 Learning Objectives
 Notes on Opening Case
Chapter Overview
In Chapter 1 the authors presented a complete example of one iteration of a development project. They
also introduced the six core processes of the SDLC. In this chapter the focus is on the third core
process: "Discover and understand the details of the problem and the need." Since this class is about
SA&D by example and by hands-on, they move immediately into the analysis tasks of investigating
and understanding the user’s needs, e.g. the requirements. Later in Chapters 8 and 9 they return to core
processes 1 and 2 to teach about project management.
Ridgeline Mountain Outfitters (RMO) is the running case example used throughout the book and
therefore you will read about the detail background information on RMO.
Each of the six core processes has several detailed activities. These detailed activities are the activities
that are done by system developers in order to execute a core process. Immediately after the description
of RMO, the chapter presents the detailed activities for Core Process 3 and explains them in detail.
Another major topic in this chapter is a definition and discussion of requirements and how
requirements are captured by building models.
The next topic is a discussion on stakeholders - who they are and how to gather information, e.g.
requirements, from them.
Finally the chapter ends with instructions on how to use UML activity diagrams to document user work
flows.
This chapter is an important chapter with key concepts to help you understand the need and importance
of system analysis and how to gather user requirements.

Learning Objectives
After reading this chapter, you should be able to:
 Describe the activities of systems analysis
 Explain the difference between functional and nonfunctional requirements
 Describe the role of models in systems analysis
 Identify and understand different kinds of stakeholders and their contributions to requirements
definition
 Describe information-gathering techniques and determine when each is best applied
 Develop activity diagrams to model workflows
Systems Analysis and Design in a Changing World, sixth edition 2-2

Notes on Opening Case

Opening Case
Mountain Vista Motorcycles (MVM): This case highlights the need to understand the business
context for which the system is going to be built. In this case MVM would like to have a Internet
presence that is attractive and engaging for its clientele. The problem, of course, is to understand its
clientele and what kind of Web presence would be most beneficial. Without understanding its clientele,
MVM could easily build a system that is ineffective, or even worse is one that alienates or bores its
clients.
In this case, the normal role of the systems analyst needs to be expanded to help the user understand
new technology and how it can be used to enhance and expand MVM's Web presence. As in many new
system development endeavors analysts and users must work together as a team to determine what
system capabilities are needed to best fit the business need.
The RMO Consolidated Sales and Marketing System Project

Key Terms
 technology architecture – a set of computing hardware, network hardware and topology, and
system software employed by an organization
 application architecture – the organization and construction of software resources to
implement an organization’s information systems

Existing RMO Information Systems and Architecture

At present, RMO has a disparate collection of computers dispersed across home offices, retail stores,
telephone centers, order fulfillment/shipping centers, and warehouses—everything connected by a
complex set of local area networks (LANs), wide area networks (WANs), and virtual private networks
(VPNs). RMO’s technology architecture is modern but not state of the art. The term application
architecture describes how software resources are organized and constructed to implement an
organization’s information systems. Currently, the major RMO systems include:

 Supply Chain Management (SCM) – five year old system in Java and Oracle. Supports
purchasing, distribution, and inventory control. The new Tradeshow system will interface with
it.
 Phone/Mail Order System – twelve year old system in Visual Studio and Microsoft SQL Server.
It is at capacity.
 Retail Store System (RSS) – a retail store package purchased by RMO. Does point of sale and
a real-time inventory update.
 Customer Support System (CSS) – fifteen year old system, with upgrades eleven years ago.
Web-based catalog and Internet storefront with shopping cart.
Systems Analysis and Design in a Changing World, sixth edition 2-3

The current problems with the sales systems include:

 Treating phone, Web, and retail sales as separate systems rather than as an integrated whole
 Employing outdated Web-based storefront technology
 Not supporting modern technologies and customer interaction modes, including mobile
computing devices and social networking

RMO plans to replace the three customer order, retail, and support systems with a new Consolidate
Sales and Marketing System (CSMS).

The New Consolidated Sales and Marketing System (CSMS)

The new CSMS system will consist of four subsystems:

 The Sales subsystem provides such basic functions as searching the online catalog and
purchasing items and paying for them online.
 The Order Fulfillment subsystem will perform all the normal tasks of shipping items and
allowing customers to track the status of their orders as well as the shipments.
 The Customer Account subsystem provides all those services that enhance the customer
experience.
 The Marketing subsystem is for employees to set up the information and services for
customers, including information about all the merchandise offered by RMO.
Systems Analysis Activities
Figure 2-2 illustrates the five systems analysis activities that make up core process three. This core
process also goes by the name systems analysis. By completing these activities, the analyst defines in
great detail what the information system needs to accomplish to provide the organization with the
desired benefits. In essence, analysis activities are a second and more thorough pass at defining the
problem and need. The first pass was done to create the System Vision Document.

Gather Detailed Information

Beginning analysts often underestimate how much there is to learn about the work the user performs.
The analyst must become an expert in the business area the system will support.

Systems analysts obtain information from people who will be using the system, either by interviewing
them or by watching them work. They obtain additional information by reviewing planning documents
and policy statements. Analysts also study existing systems, including their documentation. They also
frequently obtain additional information by looking at what other companies (particularly vendors)
have done when faced with a similar business need.

Define Requirements
System requirements include the functions the system must perform (functional requirements) and such
related issues as user interface formats and requirements for reliability, performance, and security
(nonfunctional requirements).
Systems Analysis and Design in a Changing World, sixth edition 2-4

As the analyst gathers information, he or she will use that information to create models that express the
user's needs in terms of precise processing requirements. Building and refining requirements models
occupies much of the analyst’s time.

Prioritize Requirements
Once the system requirements are well understood, it is important to establish which requirements are
most crucial for the system. It is important to prioritize requirements because resources are always
limited, and the analyst must always be prepared to justify the scope of the system. Therefore, it is
important to know what is absolutely required. Unless the analyst carefully evaluates priorities, system
requirements tend to expand as users make more suggestions (a phenomenon called scope creep).
Requirements priorities also help to determine the number, composition, and ordering of project
iterations.

Develop User-Interface Dialogs

Such requirements models as use cases, activity diagrams, and interaction diagrams can be developed
based on user input, but it is often difficult for users to interpret and validate such abstract models. In
contrast, user validation of an interface is much simpler and more reliable because the user can see and
feel the system. To most users, the user interface is all that matters. Thus, developing user-interface
dialogs is a powerful method of eliciting and documenting requirements.

Evaluate Requirements with Users

Whether it is building models or creating user-interface dialogs, the requirements must be validated by
the user to insure that the new system does, in fact, meet the business need. Analysts usually use an
iterative process in which they elicit user input, work alone to model requirements or create dialogs,
return to the user for additional input or validation, and then work alone to incorporate the new input
and refine the models.
What Are Requirements?

Key Terms
 system requirements – the activities a system must perform or support and the constraints that
the system must meet
 functional requirements – the activities that the system must perform
 nonfunctional requirements – system characteristics other than the activities it must perform
or support
 usability requirements – operational characteristics related to users, such as the user interface,
related work procedures, online help, and documentation
 reliability requirements – requirements that describe system dependability
 performance requirements – operational characteristics related to measures of workload, such
as throughput and response time
Systems Analysis and Design in a Changing World, sixth edition 2-5

 security requirements – requirements that describe how access to the application will be
controlled and how data will be protected during storage and transmission
 FURPS+ – an extension of FURPS that includes design constraints as well as implementation,
interface, physical, and supportability requirements
 design constraints – restrictions to which the hardware and software must adhere
 implementation requirements – constraints such as required programming languages and
tools, documentation method and level of detail, and a specific communication protocol for
distributed components
 interface requirements – required interactions among systems
 physical requirements – characteristics of hardware such as size, weight, power consumption,
and operating conditions
 supportability requirements – how a system is installed, configured, monitored, and updated
System requirements are all the activities the new system must perform or support and the constraints
that the new system must meet. Generally, analysts divide system requirements into two categories:
functional and nonfunctional requirements. In this section the authors use the FURPS+ model to
categorize system requirements. Figure 2-3 defines the meanings of the elements of the FURPS+
acronym. They are:
 Functions
 Usability
 Reliability
 Performance
 Security
 + Design constraints

◦ Implementation
◦ Interface
◦ Physical
◦ Support
Requirements gathering can be hard, but an easy technique is to listen to the users and other
stakeholders for statements such as:
“The ___________________________ system/app/device must _______________________.”
“The ___________________________ system/app/device should _______________________.”
“The ___________________________ system/app/device should NOT _______________________.”
“The ___________________________ system/app/device will NOT _______________________.”
Notice you also want to listen for things the system should not do as well. One of the end results of
Systems Analysis and Design in a Changing World, sixth edition 2-6

gathering and document requirements is the defining of the scope of the project. What is in and what is
NOT in the project.
Examples:
“The Customer Service system must be up during call center hours 7:00 AM to 7:00 PM Central time.”
“The Ebay website must be up 24/7.”
“The Geocaching app. should have the same features on mobile devices as it does on full browser
versions.”
“The Customer Account Lookup feature must display within sub-second response time.”
“The Customer Order system should send a confirmation email to the customer’s email account in
addition to displaying it on the web page.”
“The Customer Order system will not accept American Express or PayPal as a form of payment.”
“The Checkout process should not accept discount/coupon codes that are more than 30 days old.”
Models and Modeling

Key Terms
 Model – representation of some aspect of a system
 textual models – text-based system models such as memos, reports, narratives, and lists
 graphical models – system models that use pictures and other graphical elements
 mathematical models – system models that describes requirements numerically or as
mathematical expressions
 Unified Modeling Language (UML) – standard set of model constructs and notations defined
by the Object Management Group
A model is a representation of some aspect of the system being built, and the analyst needs to create a
variety of models to represent all aspects of the system. Some models are high-level overviews; some
are detailed views; some focus on one aspect of the system, such as inputs, processes, outputs, or data
storage; some show how the other models fit together; and some show the same problem from a
different perspective.
Models and the process of creating models are important to system development for the following
reasons:
 Learning from the modeling process
 Reducing complexity by abstraction
 Remembering all of the details
 Communicating with other development team members
 Communicating with a variety of users and stakeholders
 Documenting what was done for future maintenance/enhancement
Systems Analysis and Design in a Changing World, sixth edition 2-7

You may think why do you need to build models. The modeling process is frequently the only way that
the analyst really comes to understand the user requirements and to think through all of the “what if”
processing options. Without building models, analysts seldom dig deep enough to really understand the
requirements.
Analysis and design models can be grouped into three generic types:
 Textual models—Analysts use such textual models as memos, reports, narratives, and lists to
describe requirements that are detailed and are difficult to represent in other ways.
 Graphical models—Graphical models make it easier to understand complex relationships that
are difficult to follow when described as a list or narrative. Many graphical models used in
system development are drawn according to the notation specified by the Unified Modeling
Language (UML).
 Mathematical models—Mathematical models are one or more formulas that describe technical
aspects of a system.

Also in an Agile project, often models are quickly built, used for one of the above reasons, such as to
document some decisions or details, and then discarded after they are used to write program code.
However, even in an Agile project, it may be necessary to keep the documentation and models in order
to verify decisions that were made.
Today's object-oriented development most frequently uses the Unified Modeling Language (UML) to
build the models necessary for system development. All the diagrams in this textbook conform to UML
2.0 specifications.
Stakeholders

Key Terms
 Stakeholders – persons who have an interest in the successful implementation of the system
 internal stakeholders – persons within the organization who interact with the system or have a
significant interest in its operation or success
 external stakeholders – persons outside the organization’s control and influence who interact
with the system or have a significant interest in its operation or success
 operational stakeholders – persons who regularly interact with a system in the course of their
jobs or lives
 executive stakeholders – persons who don’t interact directly with the system but who either
use information produced by the system or have a significant financial or other interest in its
operation and success
 client – person or group that provides the funding for a system development project
Stakeholders are your primary source of information for system requirements. Stakeholders are all the
people who have an interest in the successful implementation of the system. One useful way to help
identify all the interested stakeholders is to consider two characteristics by which they vary: internal
stakeholders versus external stakeholders and operational stakeholders versus executive
stakeholders. Figure 2-6 illustrates an example of the stakeholders for an accounting system.
Systems Analysis and Design in a Changing World, sixth edition 2-8

Two other types of stakeholders not categorized by internal/external or operational/executive are the
clients and the technical staff. The client may not use the system directly, but he or she is the one who
pays for the system. In that sense, the new system must meet the client's objectives and reasons for
funding the project. The technical staff are stakeholders because they also have oversight responsibility
to ensure that the new system meets all the operational criteria for the organization.

The Stakeholders at RMO

The following list of types of stakeholders can be used by the development team to help identify
individual stakeholders:
 Phone/mail sales order clerks
 Warehouse and shipping personnel
 Marketing personnel who maintain online catalog information
 Marketing, sales, accounting, and financial managers
 Senior executives
 Customers – includes expanded definition of a customer is. Be sure to read the paragraphs
below the list on page 48.
 External shippers (e.g., UPS and FedEx)
 Owners - Be sure to read the paragraphs below the list on page 48.
 Technical staff & support - Be sure to read the paragraphs below the list on page 48.
Analysis of each of these categories will identify the individuals that have an interest in the deployment
and utility of the new system. However, the analysis should be comprehensive and not too narrow. For
example customers could include existing as well as potential customers.
Information-Gathering Techniques

Key Terms
 open-ended questions – questions that encourage discussion or explanation
 closed-ended questions – questions that elicit specific facts
One of the most important skills that a systems analyst can develop is the ability to gather the right
information so that the new system requirements are accurate and complete. There are several methods
that can be used to gather information, some are more effective and efficient than others. The most
common methods are the following:
 Interviewing users and other stakeholders
 Distributing and collecting questionnaires
 Reviewing inputs, outputs, and documentation
 Observing and documenting business procedures
 Researching vendor solutions
Systems Analysis and Design in a Changing World, sixth edition 2-9

 Collecting active user comments and suggestions

Interviewing users and other stakeholders

This is the most frequently used method because it is the most information rich. However, it is also the
most time consuming. There are five steps that analysts usually do:
 Prepare detailed questions
 Meet with individuals or groups of users
 Obtain and discuss answers to the questions
 Document the answers
 Follow up as needed in future meetings or interviews
When analysts are preparing questions, they should consider three themes.
Question Themes:
What Are the Business Processes? In the first question—What do you do?—the focus is on
understanding the business functions. In most cases, the users will provide answers in terms of the
current system. As an analyst, you must carefully discern which of those functions are fundamental
business functions, which will remain, and which may possibly be eliminated with an improved
system.
How is the Business Process Performed? The second question—How can it be done?—moves the
discussion from the current system to the new system. The focus is on how the new system should
support the function rather than on how it is performed under the existing system. Thus, the first two
questions go hand-in-hand to discover the need and begin the definition of the system requirements in
terms of the new system.
What Information is Required? The final question—What information is needed?—defines specific
information that the new system must provide. The answers to the second and third questions form the
basis for the definition of the system requirements. If when the analyst focuses the investigation around
these three themes, he will be able to ask intelligent, meaningful questions in his investigation.
Question Types: Questions can be either open-ended, which allow the stakeholder to discuss and
explain, or closed-ended, which are useful for getting specific facts and numbers.
Focus of Questions—Current System or New?: A difficult issue in interviewing users and other
stakeholders is whether to focus the questions around the existing system or to emphasize only the new
system. Each project is different, and analysts must use good judgment on how much time to spend on
the old system. Analysts should remember that the only utility in reviewing existing systems, to ensure
that correct requirements are obtained for the new system. So if the new system duplicates many of the
extant business processes, then those processes should be reviewed.
Interview Preparation, Conduct, and Follow-Up: An interview with a user or stakeholder requires
planning and preparation. Without proper preparation, the interview can waste valuable time and can
even fail to discover important information.

Preparing for the interview: Every successful interview requires preparation. The first and most
Systems Analysis and Design in a Changing World, sixth edition 2-10

important step in preparing for an interview is to establish the objective of the interview. The second
step is to determine which users should be involved in the interview. The third step is to prepare
detailed questions to be used in the interview. The last step is to make the final interview arrangements
and to communicate those arrangements to all participants.
Conducting the interview: New systems analysts are usually quite nervous about conducting
interviews. However, in most cases, the users are excited about getting a better system to help them do
their jobs. Practicing good manners usually ensures that the interview will go well. Here are a few
guidelines:
 Dress appropriately.
 Arrive on time.
 Limit the time of the interview.
 Look for exception and error conditions.
 Probe for details.
 Take careful notes.
Following up the interview: Analysts often document the details of the interview by constructing
models of the business processes. Review your findings with the other project members in the
interview and document the results (that is, build the models) within a day or two to avoid forgetting
important details.

Distributing and Collect Questionnaires

Questionnaires enable analysts to collect information from a large number of stakeholders.
Questionnaires are often used to obtain preliminary insight into stakeholder information needs, which
helps to determine areas that need further research by using other methods. However,questionnaires are
not well suited to helping you learn about processes, workflows, or techniques.

Review Inputs, Outputs, and Procedures

There are two sources of information about inputs, outputs, and procedures. One source is external to
the organization—industry-wide professional organizations and other companies. The project team
would be negligent in its duties if its members were not familiar with best practice information. The
second source of inputs, outputs, and procedures is existing business documents and procedure
descriptions within the organization.

Observe and Document Business Procedures

Firsthand experience is invaluable to understand exactly what occurs within business processes. More
than any other activity, observing a business process in action will help analysts understand the
business functions. However, there is a danger that the user and analyst will decide to re-implement the
existing process instead of moving to a newer and more advanced approach.
Systems Analysis and Design in a Changing World, sixth edition 2-11

Research Vendor Solutions

Many of the problems and opportunities that companies want to address with new information systems
have already been solved by other companies. Researching existing solutions will frequently help users
generate new ideas for how to better perform their business functions. Frequently these solutions from
vendors are excellent and state of the art. It is also usually cheaper to purchase a solution than to build
one from scratch. However, there is always a danger of buying something that does not quite fit the
needs of the business. Care should be taken when purchasing a solution.

Collect Active User Comments and Suggestions

User feedback from initial and later testing is a valuable source of requirements information.
Interviews, discussions, and model reviews are an imperfect way of eliciting complete and accurate
requirements. The phrase “I’ll know it when I see it” applies well to requirements definition. Users
often cannot completely or accurately state their requirements until they can interact with a live system
that implements those requirements.
Documenting Workflows with Activity Diagrams

Key Terms
 Workflow – sequence of processing steps that completely handles one business transaction or
customer request
 activity diagram – describes user (or system) activities, the person who does each activity, and
the sequential flow of these activities
 synchronization bar – activity diagram component that either splits a control path into
multiple concurrent paths or recombines concurrent paths
 swimlane – heading activity diagram column containing all activities for a single agent or
organizational unit
As mentioned earlier, through the process of building models an analyst not only documents a business
process or workflow, but he/she also will come to understand the workflow in more depth. UML
activity diagrams provide a simple technique to document business workflows. The key terms define
each element of an activity diagram. Figure 2-14 provides visual elements that are used on an activity
diagram.
Creating activity diagrams to document workflows is straightforward. The first step is to identify the
agents to create the appropriate swimlanes. Next, follow the various steps of the workflow and then
make appropriate ovals for the activities. Usually there is a swimlane for the actor or user of the
system, and another swimlane for the actions done by the system. Use a decision symbol to represent
an either/or situation—one path or the other path but not both. Use synchronization bars for parallel
paths—situations in which both paths are taken. Include a beginning and an ending synchronization
bar.
Modeling takes practice. You will get practice as you do the case assignments. You will use Visio
Professional. I will be setting an account for you to get the software for free. I will send you an email
announcement when the accounts are ready. Be sure to download and install the software immediately
Systems Analysis and Design in a Changing World, sixth edition 2-12

just in case you have technical problems. No excuses for last minute technical problems.

Final Thoughts
The two primary areas that you may have difficulty in this chapter is the skill of learning to interview
well, in particular to probe deeply to really understand the issues. Even experienced analysts often do
not ask enough “what if” questions to determine all of the exception conditions. The most effective way
for you to learn this skill is by practicing. It is obvious hard to practice in an online class. If you think
you need practice in this area, then interview another student, colleague, instructor, or friend. The topic
could be on anything. It could be about their favorite movie, sport, talent, etc. Be sure to use all of the
steps mentioned above to prepare, conduct, and then document the interview.
The other area you may need help is in developing activity diagrams. The basic skill is not too
difficult, but knowing how detailed to make the action steps, i.e. the ovals, is sometimes a problem.
Whether to say, "enter your name" then "enter your address" etc. or to just say "enter client
information" is the issue. The answer is generally to enter a complete form full of data is sufficient.
In learning about activity diagrams, you may get the synchronization bar and the decision activity
confused. It sometimes helps to say use the following analogies.
 Synchronization bar = AND condition, multitasking, concurrent threads
 Decision Activity = OR condition, single thread (non-active thread dies)