Topic Two: Investigating System Requirements
1
Systems Analysis Activities
2
The left side of the figure above lists the activities of
the third core process, which is to discover and
understand the details.
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.
3
In essence, analysis activities are a second and more
thorough pass at defining the problem and need.
The first pass generates only enough detail to decide
whether a new or upgraded system is warranted and
feasible.
The second (analysis) pass assumes that the
organization is committed to the project. Thus,
considerably more time and resources are invested to
produce a much more detailed description of what the
system will do.
4
Although we concentrate only on analysis activities in
this chapter, keep in mind that they are usually
intermixed with design, implementation, and other
activities during the system development life cycle.
For example, as shown in the figure above analysis
activities are most intensive in the second iteration but
occur in varying degrees during all project iterations
except the last.
5
This pattern is typical because an analyst will often
concentrate on one part of a system, defining
requirements only for that part and simultaneously
designing and implementing software to satisfy those
requirements.
Organizing development activities in this iterative
manner enables development to be broken into smaller
steps and enables users to validate requirements by
testing and observing a functional system.
6
Gather Detailed Information
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.
7
They try to understand an existing system by identifying
and understanding the activities of all the current and
future users and by identifying all the present and
future locations where work occurs and all the system
interfaces with other systems, both inside and outside
the organization.
In short, analysts need to talk to nearly everyone who
will use the new system or has used similar systems,
and they must read nearly everything available about
the existing system. Later in this chapter, we discuss
how to identify and extract information from all these
people.
8
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.
For example, if you are implementing an order-entry system,
you need to become an expert on the way orders are
processed (including related accounting procedures).
If you are implementing a loan-processing system, you need
to become an expert on the rules used for approving credit.
If you work for a bank, you need to think of yourself as a
banker. The most successful analysts become experts in their
organization’s main business.
9
Define Requirements
The analyst uses information gathered from users
and documents to define requirements for the new
system. 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).
Defining requirements is not just a matter of writing
down facts and figures.
10
Instead, the analyst creates models to record
requirements, reviews the models with users and
others, and refines and expands the models to
reflect new or updated information.
Building and refining requirements models occupies
much of the analyst’s time. This chapter and the
next two chapters explain in considerable depth
how to create requirements models.
11
Prioritize Requirements
Once the system requirements are well understood, it
is important to establish which requirements are most
crucial for the system.
Sometimes, users suggest additional system functions
that are desirable but not essential.
However, users and analysts need to ask themselves
which functions are truly important and which are fairly
important but not absolutely required.
Why prioritize the functions requested by the users?
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.
12
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.
High-priority requirements are often incorporated into
early project iterations so analysts and users have
ample opportunity to refine those parts of the system.
Also, a project with many high-priority requirements
will typically have many iterations.
13
Develop User-Interface Dialogs
When a new system is replacing an old system that does
similar work, users are usually quite sure about their
requirements and the desired form of the user interface.
But many system development projects break new ground by
automating functions that were previously performed
manually or by implementing functions that were not
performed in the past.
In either case, users tend to be uncertain about many aspects
of system requirements. 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.
14
In comparison, 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 obtaining and documenting requirements.
Analysts can develop user interfaces via abstract
models, such as storyboards, or they can develop user-
interface prototypes on the actual input/output devices
that users will use (e.g., a computer monitor, iPad, or
cell phone).
A prototype interface can serve as a requirement and a
starting point for developing a portion of the system. In
other words, a user-interface prototype developed in
an early iteration can be expanded in later iterations to
become a fully functioning part of the system.
15
Evaluate Requirements with Users
Ideally, the activities of evaluating requirements
with users and documenting the requirements are
fully integrated.
But in practice, users generally have other
responsibilities besides developing a new system.
Thus, analysts usually use an iterative process in
which they obtain user input, work alone to model
requirements, return to the user for additional
input or validation, and then work alone to
incorporate the new input and refine the models.
16
Prototypes of user interfaces and other parts of the system
may also be developed when “paper” models are inadequate
or when users and analysts need to prove that chosen
technologies will do what they are supposed to do.
Also, if the system will include new or innovative technology,
the users may need help visualizing the possibilities available
from the new technology when defining what they require.
Prototypes can fill that need.
The processes of obtaining requirements, building models
and prototypes, and evaluating them with users may repeat
many times until requirements models and prototypes are
complete and accurate.
17
System requirements
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.
18
Functional requirements
Functional requirements are the activities that the system
must perform (i.e., the business uses to which the system will
be applied).
For example, if you are developing a payroll system, the
required business uses might include such functions as
“generate electronic fund transfers,” “calculate commission
amounts,” “calculate payroll taxes,” “maintain employee-
dependent information,” and “report tax deductions to the
TRA.”
The new system must handle all these functions. Identifying
and describing all these business uses require a substantial
amount of time and effort because the list of functions and
their relationships can be very complex.
19
Nonfunctional requirements
Nonfunctional requirements are characteristics of
the system other than those activities it must
perform or support.
It is not always easy to distinguish functional from
nonfunctional requirements.
One way to do so is to use a framework for
identifying and classifying requirements.
20
There have been many such frameworks developed
over time; the most widely used today is called FURPS+
(see figure below).
FURPS is an acronym that stands for functionality,
usability, reliability, performance, and security. The “F”
in FURPS is equivalent to the functional requirements
defined previously. The remaining FURPS categories
describe nonfunctional requirements:
21
22
Usability requirements describe operational characteristics
related to users, such as the user interface, related work
procedures, online help, and documentation.
For example, the user interface for a smartphone app
should behave similarly to other apps when responding to
such gestures as two-finger slides, pinching, and expanding.
Additional requirements might include menu format, color
schemes, use of the organization’s logo, and multilingual
support.
23
Reliability requirements describe the dependability
of a system—how often a system exhibits such
behaviors as service outages and incorrect
processing and how it detects and recovers from
those problems.
24
Performance requirements describe operational
characteristics related to measures of workload,
such as throughput and response time.
For example, the client portion of a system might be
required to have a one-half-second response time
to all button presses, and the server might need to
support 100 simultaneous client sessions (with the
same response time).
25
Security requirements describe how access to the
application will be controlled and how data will be
protected during storage and transmission.
For example, the application might be password
protected, encrypt locally stored data with 1024-bit
keys, and use secure HTTP for communication
among client and server nodes.
26
FURPS+ is an extension of FURPS that adds
additional categories, including design constraints
as well as implementation, interface, physical, and
supportability requirements—all these additional
categories summarized by the plus sign. Here are
short descriptions of each category:
27
Design constraints describe restrictions to which the
hardware and software must adhere.
For example, a cell phone application might be required
to use the Android operating system, consume no more
than 30MB of flash memory storage, consume no more
than 10MB of system memory while running, and
operate on CPUs rated at 1 GHz or higher.
28
Implementation requirements describe constraints
such as required programming languages and tools,
documentation method and level of detail, and a
specific communication protocol for distributed
components.
29
Interface requirements describe interactions among
systems.
For example, a financial reporting system for a publicly
traded company in the United States must generate
data for the Securities and Exchange Commission (SEC)
in a specific XML format.
The system might also supply data directly to stock
exchanges and bond rating agencies and automatically
generate Twitter messages, RSS feeds, and Facebook
updates.
30
Physical requirements describe such characteristics
of hardware as size, weight, power consumption,
and operating conditions.
For example, a system that supports battlefield
communications might have such requirements as
weighing less than 200 grams, being no larger than
5 centimeters cubed, and operating for 48 hours on
a fully charged 1200 milliwatt lithium ion battery.
31
Supportability requirements describe how a system
is installed, configured, monitored, and updated.
For example, requirements for a game installed on a
home PC might include automatic configuration to
maximize performance on existing hardware, error
reporting, and download of updates from a support
server.
32
Models and Modeling
A model is a representation of some aspect of
the system being built.
33
Analysts build models to describe system requirements
and use those models to communicate with users and
designers.
By developing a model and reviewing it with a user, an
analyst demonstrates an understanding of the user’s
requirements.
If the user spots errors or omissions, they are
incorporated into the model before it becomes the
basis for subsequent design and implementation
activities.
34
Reasons for modeling
Learning from the modeling process
Reducing complexity by abstraction
Remembering all the details
Communicating with other development team
members
Communicating with a variety of users and
stakeholders
Documenting what was done for future
maintenance/enhancement
35
Analysis and design models can be grouped
into three generic types:
-Textual models
-Graphical models
-Mathematical models
36
Textual models are text-based system models such
as memos, reports, narratives, and lists.
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.
37
Graphical models
Graphical models are system models that
use pictures and other graphical elements
Graphical models make it easier to understand
complex relationships that are difficult to
follow when described as a list or narrative.
38
Mathematical models
Mathematical models system models that describes
requirements numerically or as mathematical
expressions
Mathematical models are one or more formulas that
describe technical aspects of a system.
Analysts often use mathematical models to represent
functional requirements for scientific and engineering
applications and occasionally use them to describe
business system requirements in areas such as
accounting and inventory control.
39
Stakeholders
Stakeholders are people who have an interest in the
successful implementation of the system.
Each stakeholder group interacts with the system in different
ways, and each has a unique perspective on system
requirements.
Before gathering detailed information, the analyst identifies
every type of stakeholder who has an interest in the new
system and ensures that critical people from each stakeholder
category are available to serve as the business experts.
40
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
41
Internal stakeholders are those within the
organization who interact with the system or have a
significant interest in its operation or success.
You may be tempted to define internal stakeholders
as employees of an organization, but some
organizations—such as nonprofits and educational
institutions—have internal users (e.g., volunteers
and students) who are not employees.
42
External stakeholders are persons outside the
organization’s control and influence who interact
with the system or have a significant interest in its
operation or success.
43
Operational stakeholders are those who regularly interact
with a system in the course of their jobs or lives.
Examples include bookkeepers interacting with an accounting
or billing system, factory workers interacting with a
production scheduling system, customers interacting with an
Internet storefront, and patients who interact with a health
care Web site, Facebook page, or Twitter newsfeed.
Operational users are a key source of requirements
information, especially as it pertains to user interfaces and
related functionality.
44
Executive stakeholders are those who do not
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.
Examples include an organization’s senior managers
and board of directors, regulatory agencies, and
taxing authorities.
45
The client is the person or group that provides the
funding for the project.
The project team includes the client in its list of
important stakeholders because the team must
provide periodic status reviews to the client
throughout development.
46
An organization’s technical and support staff are also
stakeholders in any system. The technical staff includes
people who establish and maintain the computing
environment of the organization.
Support staff provide user training, troubleshooting,
and related services. Both groups should provide
guidance in such areas as programming language,
computer platforms, network interfaces, and existing
systems and their support issues.
Any new system must fit within an organization’s
existing technology architecture, application
architecture, and support environment.
Thus, technical and support representatives are
important stakeholders.
47
Information-Gathering Techniques
Techniques for gathering detailed requirements
information include:
■ Interviewing users and other stakeholders
■ Distributing and collecting questionnaires
■ Reviewing inputs, outputs, and documentation
■ Observing and documenting business procedures
■ Researching vendor solutions
■ Collecting active user comments and suggestions
48
Interview Users and Other Stakeholders
Interviewing users and other stakeholders is an effective
way to understand business functions and business
rules.
Unfortunately, it is also the most time consuming and
resource-expensive option. In this method, systems
analysts:
■ 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.
Obviously, this process may take some time, so it usually
requires multiple sessions with each of the users or user
groups.
49
Question Types
Questions can be roughly divided into two types:
- Open-ended are questions that
encourage discussion or explanation. Such as “How do
you do this function?”
-Closed-ended questions—questions
that get specific facts. Such as “How many forms a day
do you process?” that are used to get specific facts
50
Generally, open-ended questions help to start a
discussion and enable a large number of
requirements to be uncovered fairly quickly. A
discussion that starts with open-ended questions
usually shifts gradually to closed-ended questions
that elicit or confirm specific details of a business
process.
51
Distribute and Collect Questionnaires
Questionnaires enable analysts to collect information
from a large number of stakeholders.
Even if the stakeholders are widely distributed
geographically, they can still help define requirements
through questionnaires.
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.
52
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.
It may not be easy to obtain information from other
companies, but they are a potential source of
important information.
Sometimes, industry journals and magazines report the
findings of “best practices” studies. The project team
would be negligent in its duties if its members were not
familiar with best practice information.
53
Observe and Document Business Processes
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 you understand the business functions.
However, while observing existing processes, you must also
be able to visualize the new system’s associated business
processes.
That is, as you observe the current business processes to
understand the fundamental business needs, you should
never forget that the processes could and often should
change to be made more efficient.
Do not get locked into believing there is only one way of
performing the process.
54
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.
In addition, consulting firms often have experience
with the same problems, and software firms may have
already packaged solutions for a particular business
need.
Taking advantage of existing knowledge or solutions
can avoid costly mistakes and save time and money.
55
Collect Active User Comments and Suggestions
As discussed earlier, system development normally
proceeds with analysis, design, and other activities
spread across multiple iterations.
Portions of the system are constructed and tested
during each iteration. Users and other stakeholders
perform the initial testing of system functions during
the iteration in which those functions are
implemented.
They also test and use those same functions during
later iterations.
User feedback from initial and later testing is a valuable
source of requirements information.
56
Documenting Workflows with Activity Diagrams
A workflow is the sequence of processing steps that
completely handles one business transaction or
customer request.
Workflows may be simple or complex. Complex
workflows can be composed of dozens or hundreds of
processing steps and may include participants from
different parts of an organization.
An activity diagram describes the various user (or
system) activities, the person who does each activity,
and the sequential flow of these activities.
57
Synchronization bar is an activity diagram component
that either splits a control path into multiple
concurrent paths or recombines concurrent paths
Swimlane heading is an activity diagram column
containing all activities for a single agent or
organizational unit
58
