System Analysis & Design (CSC 3307) | Jeremiah Isuwa

SYSTEM ANALYSIS AND DESIGN (CSC 3307)

MODULE (3)
Module Content:

• Requirement Determination
• Requirements Analysis Strategies
• Requirement Gathering Techniques
• Business Process and Functional Modeling (Use cases and Activity Diagrams)
• Business Process Documentation with Use Cases and Use-Case Descriptions
Referral material: Systems Analysis and Design-An Object-Oriented Approach with UML-2015.

Introduction
In many ways, because it is here that the major elements of the system first emerge, the requirements-
determination step is the single most critical step of the entire system development process. During
requirements determination, the system is easy to change because little work has been done yet. As
the system moves through the system development process, it becomes harder and harder to return
to requirements determination and to make major changes because of all of the rework that is
involved. Several studies have shown that more than half of all system failures are due to problems
with the requirements. This is why the iterative approaches of object-oriented methodologies are so
effective—small batches of requirements can be identified and implemented in incremental stages,
allowing the overall system to evolve over time.

REQUIREMENT DETERMINATION
The purpose of requirements determination is to turn the very high-level explanation of the business
requirements stated in the system request into a more precise list of requirements that can be used as
inputs to the rest of analysis (creating functional, structural, and behavioral models). This expansion
of the requirements ultimately leads to the design of the system.

1
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

1. Defining a Requirement
A requirement is simply a statement of what the system must do or what characteristic it must have.
During analysis, requirements are written from the perspective of the businessperson, and they focus
on the “what” of the system. Because they focus on the needs of the business user, they are usually
called business requirements (and sometimes user requirements). Later in design, business
requirements evolve to become more technical, and they describe how the system will be
implemented. Requirements in design are written from the developer’s perspective, and they are
usually called system requirements.
We want to stress that there is no black-and-white line dividing a business requirement and a system
requirement—and some companies use the terms interchangeably. Requirements evolve from detailed
statements of the business capabilities that a system should have to detailed statements of the technical
way the capabilities will be implemented in the new system.
Requirements can be either functional or nonfunctional in nature. A functional requirement relates
directly to a process a system has to perform or information it needs to contain. For example,
requirements stating that a system must have the ability to search for available inventory or to report
actual and budgeted expenses are functional requirements. Functional requirements flow directly into
the creation of functional, structural, and behavioral models that represent the functionality of the
evolving system.
Nonfunctional requirements refer to behavioral properties that the system must have, such as
performance and usability. The ability to access the system using a Web browser is considered a
nonfunctional requirement. Nonfunctional requirements can influence the rest of analysis (functional,
structural, and behavioral models) but often do so only indirectly; nonfunctional requirements are
used primarily in design when decisions are made about the database, the user interface, the hardware
and software, and the system’s underlying physical architecture.
Nonfunctional requirements describe a variety of characteristics regarding the system: operational,
performance, security, and cultural and political. Performance requirements address issues related to the
speed, capacity, and reliability of the system. Security requirements deal with issues with regard to
who has access to the system and under what specific circumstances. Cultural and political
requirements deal with issues related to the cultural, political factors and legal requirements that affect
the system.

2
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

2. Requirements Definition
straightforward text report that simply lists the functional and nonfunctional requirements in an
outline format. Figure 1 shows a sample requirements definition for an appointment system for a
typical doctor’s office. Notice it contains both functional and nonfunctional requirements.
The most obvious purpose of the requirements definition is to provide the information needed by the
other deliverables in analysis, which include functional, structural, and behavioral models, and to
support activities in design. The most important purpose of the requirements definition, however, is
to define the scope of the system. The document describes to the analysts exactly what the system
needs to end up doing. When discrepancies arise, the document serves as the place to go for
clarification.

Figure 1: Sample Requirement Definition

3. Determining Requirements
Determining requirements for the requirements definition is both a business task and an information
technology task. In the early days of computing, there was a presumption that the systems analysts, as
experts with computer systems, were in the best position to define how a computer system should
operate. Many systems failed because they did not adequately address the true business needs of the
users. Gradually, the presumption changed so that the users, as the business experts, were seen as
being the best position to define how a computer system should operate.

3
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

Therefore, the most effective approach is to have both business people and analysts working
together to determine business requirements. Sometimes, however, users don’t know exactly what
they want, and analysts need to help them discover their needs. A set of strategies has become popular
to help analysts do problem analysis, root cause analysis, duration analysis, activity-based costing,
informal benchmarking, outcome analysis, technology analysis, and activity elimination. Analysts can
use these tools when they need to guide the users in explaining what is wanted from a system. These
strategies work similarly. They help users critically examine the current state of systems and processes
(the as-is system), identify exactly what needs to change, and develop a concept for a new system (the
to-be system).
Although these strategies enable the analyst to help users create a vision for the new system, they are
not sufficient for extracting information about the detailed business requirements that are needed to
build it. Therefore, analysts use a portfolio of requirements-gathering techniques to acquire
information from users. The analyst has many techniques from which to choose: interviews,
questionnaires, observation, joint application development (JAD), and document analysis.
The information gathered using these techniques is critically analyzed and used to craft the
requirements definition report.

4. Creating a Requirements Definition

Creating a requirements definition is an iterative and ongoing process whereby the analyst collects
information with requirements-gathering techniques (e.g., interviews, document analysis), critically
analyzes the information to identify appropriate business requirements for the system, and adds the
requirements to the requirements definition report. The requirements definition is kept up to
date so that the project team and business users can refer to it and get a clear understanding of the
new system.
To create a requirements definition, the project team;
• First determines the kinds of functional and nonfunctional requirements that they will collect
about the system (of course, these may change over time).
• Next, the analysts use a variety of requirements-gathering techniques to collect information, and
they list the business requirements that were identified from that information.
• Finally, the analysts work with the entire project team and the business users to verify, change,
and complete the list and to help prioritize the importance of the requirements that were
identified.
4
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

This process continues throughout analysis, and the requirements definition evolves over time as
new requirements are identified and as the project moves into later phases of the Unified Process. The
project team cannot keep adding to the requirements definition, or the system will keep growing
and growing and never get finished. Instead, the project team carefully identifies requirements and
evaluates which ones fit within the scope of the system. When a requirement reflects a real business
need but is not within the scope of the current system or current release, it is either added on a list of
future requirements or given a low priority. The management of requirements (and system scope)
is one of the hardest parts of managing a project.

REQUIREMENTS ANALYSIS STRATEGIES

Before the project team can determine what requirements are appropriate for a given system, there
needs to be a clear vision of the kind of system that will be created and the level of change that it
will bring to the organization.
The basic process of analysis is divided into three steps:
• Understanding the as-is system,
• Identifying improvements, and
• Developing requirements for the to-be system.
Sometimes the first step (i.e., understanding the as-is system) is skipped or is performed in a cursory
manner. This happens when no current system exists, if the existing system and processes are
irrelevant to the future system.
Requirements analysis strategies help the analyst lead users through the analysis steps so that the vision
of the system can be developed. Requirements analysis strategies and requirements-gathering
techniques go hand in hand. Analysts use requirements-gathering techniques to collect information;
requirements analysis strategies drive the kind of information that is gathered and how it is ultimately
analyzed. The requirements analysis strategies and requirements gathering happen concurrently and
are complementary activities.
To move the users from the as-is system to the to-be system, an analyst needs strong critical thinking
skills. Critical thinking is the ability to recognize strengths and weaknesses and recast an idea in an
improved form, and critical thinking skills are needed to really understand issues and develop new
business processes. These skills are also needed to thoroughly examine the results of requirements
gathering, to identify business requirements, and to translate those requirements into a concept for
the new system.
5
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

1. Problem Analysis
The most straightforward (and probably the most commonly used) requirements-analysis technique
is problem analysis. Problem analysis means asking the users and managers to identify problems with the
as-is system and to describe how to solve them in the to-be system.
Improvements from problem analysis tend to be small and incremental (e.g., provide more space in
which to type the customer’s address; provide a new report that currently does not exist). This type
of improvement often is very effective at improving a system’s efficiency or ease of use.

2. Root Cause Analysis

In the business world, the challenge lies in identifying the root cause—few real-world problems are
simple. The users typically propose a set of causes for the problem under consideration. The
solutions that users propose can address either symptoms or root causes, but without a careful
analysis, it is difficult to tell which one is addressed.
Root cause analysis, therefore, focuses on problems, not solutions. The analyst starts by having the
users generate a list of problems with the current system and then prioritize the problems in order
of importance. Starting with the most important, the users and/or the analysts then generate all the
possible root causes for the problems. Each possible root cause is investigated (starting with the
most likely or easiest to check) until the true root causes are identified.

3. Duration Analysis
Duration analysis requires a detailed examination of the amount of time it takes to perform each
process in the current as-is system. The analysts begin by determining the total amount of time it
takes, on average, to perform a set of business processes for a typical input. They then time each of
the individual steps (or subprocesses) in the business process. The time to complete the basic step is
then totaled and compared to the total for the overall process.
For example, suppose that the analysts are working on a home mortgage system and discover that on
average, it takes thirty days for the bank to approve a mortgage. They then look at each of the basic
steps in the process (e.g., data entry, credit check, title search, appraisal) and find that the total amount
of time actually spent on each mortgage is about eight hours. This is a strong indication that the overall
process is badly broken, because it takes thirty days to perform one day’s work.
These problems probably occur because the process is badly fragmented. Many different people
must perform different activities before the process finishes. Processes in which many different people

6
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

work on small parts of the inputs are prime candidates for process integration or parallelization. Process
integration means changing the fundamental process so that fewer people work on the input, which
often requires changing the processes and retraining staff to perform a wider range of duties. Process
parallelization means changing the process so that all the individual steps are performed at the same
time.

4. Activity-Based Costing
Activity-based costing is a similar analysis; it examines the cost of each major process or step in a
business process rather than the time taken. The analysts identify the costs associated with each of the
basic functional steps or processes, identify the costliest processes, and focus their improvement
efforts on them.
Assigning costs is conceptually simple. Analysts simply examine the direct cost of labor and
materials for each input. Materials costs are easily assigned in a manufacturing process, whereas labor
costs are usually calculated based on the amount of time spent on the input and the hourly cost of the
staff.

5. Informal Benchmarking
Benchmarking refers to studying how other organizations perform a business process in order to learn
how your organization can do something better. Benchmarking helps the organization by introducing
ideas that employees may never have considered but that have the potential to add value.
Informal benchmarking is fairly common for customer-facing business processes (i.e., processes
that interact with the customer). With informal benchmarking, the managers and analysts think about
other organizations or visit them as customers to watch how the business process is performed.

6. Outcome Analysis
Outcome analysis focuses on understanding the fundamental outcomes that provide value to
customers. Although these outcomes sound as though they should be obvious, they often are not. For
example, consider an insurance company. One of its customers has just had a car accident. What is
the fundamental outcome from the customer’s perspective? Traditionally, insurance companies have
answered this question by assuming the customer wants to receive the insurance payment quickly. To
the customer, however, the payment is only a means to the real outcome: a repaired car. The insurance
company might benefit by extending its view of the business process past its traditional boundaries to

7
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

include not paying for repairs but performing the repairs or contracting with an authorized body shop
to do them.

7. Technology Analysis
Many major changes in business since the turn of the century have been enabled by new
technologies. Technology analysis starts by having the analysts and managers develop a list of
important and interesting technologies. Then the group systematically identifies how every
technology could be applied to the business process and identifies how the business would
benefit.
It is important to note the technology analysis in no way implies adopting technology for technology’s
sake. Rather the focus is on using new technologies to meet the goals of the organization.

8. Activity Elimination
Activity elimination is exactly what it sounds like. The analysts and managers work together to identify
how the organization could eliminate each activity in the business process, how the function could
operate without it, and what effects are likely to occur. Initially, managers are reluctant to conclude
that processes can be eliminated, but this is a force-fi t exercise in that they must eliminate each activity.

REQUIREMENT GATHERING TECHNIQUES

An analyst is very much like a detective (and business users are sometimes like elusive suspects). He
or she knows that there is a problem to be solved and therefore must look for clues that uncover the
solution. Unfortunately, the clues are not always obvious (and are often missed), so the analyst needs
to notice details, talk with witnesses, and follow leads just as Sherlock Holmes would have done.
The best analysts thoroughly gather requirements using a variety of techniques and make sure that the
current business processes and the needs for the new system is well understood before moving into
design. Analysts don’t want to discover later that they have key requirements wrong—such surprises
late in the development process can cause all kinds of problems.
The requirements-gathering process is used for building political support for the project and
establishing trust and rapport between the project team building the system and the users who
ultimately will choose to use or not use the system. All the key stakeholders (the people who can
affect the system or who will be affected by the system) must be included in the requirements-

8
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

gathering process. The stakeholders might include managers, employees, staff members, and even
some customers and suppliers.
There are many techniques for gathering requirements that vary from asking people questions to
watching them work. In this section, we focus on the five most commonly used techniques:
• Interviews,
• JAD sessions (a special type of group meeting),
• Questionnaires,
• Document analysis, and
• Observation.
Each technique has its own strengths and weaknesses, many of which are complementary, so most
projects use a combination of techniques.

1. Interviews
An interview is the most commonly used requirements-gathering technique. After all, it is natural—if
you need to know something, you usually ask someone. In general, interviews are conducted one-on-
one (one interviewer and one interviewee), but sometimes, owing to time constraints, several people
are interviewed at the same time. There are five basic steps to the interview process:
a) Selecting interviewees,
b) Designing interview questions,
c) Preparing for the interview,
d) Conducting the interview, and
e) Post-interview follow-up

a) Selecting interviewees
The first step in interviewing is to create an interview schedule listing who will be interviewed, when,
and for what purpose. The schedule can be an informal list that is used to help set up meeting times
or a formal list that is incorporated into the workplan. The people who appear on the interview
schedule are selected based on the analyst’s information needs. The project sponsor, key business
users, and other members of the project team can help the analyst determine who in the organization
can best provide important information about requirements. These people are listed on the interview
schedule in the order in which they should be interviewed.

9
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

People at different levels of the organization have varying perspectives on the system, so it is important
to include both managers who manage the processes and staff who actually perform the processes to
gain both high-level and low-level perspectives on an issue.
It is common to begin by interviewing one or two senior managers to get a strategic view and then to
move to midlevel managers who can provide broad, overarching information about the business
process and the expected role of the system being developed. Once the analyst has a good
understanding of the big picture, lower-level managers and staff members can fill in the exact details
of how the process works.

b) Designing interview questions

There are three types of interview questions: closed-ended questions, open-ended questions, and probing
questions. Closed-ended questions are those that require a specific answer. They are similar to
multiple-choice or arithmetic questions on an exam. Closed ended questions are used when an analyst
is looking for specific, precise information (e.g., how many credit card requests are received per day).
However, these types of questions don’t uncover why the answer is the way it is, nor do they uncover
information that the interviewer does not think to ask for ahead of time.
Open-ended questions are those that leave room for elaboration on the part of the interviewee.
They are similar in many ways to essay questions that you might find on an exam. Open-ended
questions are designed to gather rich information and give the interviewee more control over the
information that is revealed during the interview.
The third type of question is the probing question. Probing questions follow up on what has just
been discussed in order to learn more, and they often are used when the interviewer is unclear about
an interviewee’s answer. They encourage the interviewee to expand on or to confirm information from
a previous response, and they signal that the interviewer is listening and is interested in the topic under
discussion.
No type of question is better than another, and a combination of questions is usually used during
an interview. At the initial stage of an IS development project, the as-is process can be unclear, so the
interview process begins with unstructured interviews, interviews that seek broad and roughly
defined information. As the project progresses, the analyst comes to understand the business process
much better and needs very specific information about how business processes are performed. At this
time, the analyst conducts structured interviews, in which specific sets of questions are developed
before the interviews.

10
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

There are two fundamental approaches to organizing the interview questions: top down or bottom up.
With the top-down interview, the interviewer starts with broad, general issues and gradually works
toward more-specific ones. With the bottom-up interview, the interviewer starts with very specific
questions and moves to broad questions. In practice, analysts mix the two approaches, starting with
broad, general issues, moving to specific questions, and then returning to general issues.
The top-down approach is an appropriate strategy for most interviews. This enables the interviewee
to become accustomed to the topic before he or she needs to provide specifics. One case in which
the bottom-up strategy may be preferred is when the analyst already has gathered a lot of information
about issues and just needs to fill in some holes with details.

c) Preparing for the interview

It is important to prepare for the interview in the same way that you would prepare to give a
presentation. The interviewer should have a general interview plan listing the questions to be asked in
the appropriate order, should anticipate possible answers and provide follow-up with them, and
should identify segues between related topics.
The interviewer should be sure to prepare the interviewee as well. When the interview is
scheduled, the interviewee should be told the reason for the interview and the areas that will be
discussed far enough in advance so that he or she has time to think about the issues and organize his
or her thoughts.

d) Conducting the interview

The first goal is to build rapport with the interviewee, so that he or she trusts the interviewer and is
willing to tell the whole truth, not just give the answers that he or she thinks are wanted. The
interviewer should appear to be a professional and unbiased, independent seeker of information. The
interview should start with an explanation of why the interviewer is there and why he or she has
chosen to interview the person; then the interviewer should move into the planned interview
questions. As the interview draws to a close, the interviewee should have time to ask questions.

e) Post-interview follow-up
After the interview is over, the analyst needs to prepare an interview report that describes the
information from the interview. The report contains interview notes, information that was collected
over the course of the interview and is summarized in a useful format.

11
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

Often, the interview report is sent to the interviewee with a request to read it and inform the analyst
of clarifications or updates. Th e interviewee needs to be convinced that the interviewer genuinely
wants his or her corrections to the report. Usually there are few changes, but the need for any
significant changes suggests that a second interview will be required. Never distribute someone’s
information without prior approval.

2. Joint Application Development

JAD is an information-gathering technique that allows the project team, users, and management
to work together to identify requirements for the system. Capers Jones claims that JAD can reduce
scope creep by 50 percent and prevent the system’s requirements from being too specific or too
vague, both of which cause trouble during later stages of the development process.
JAD is a structured process in which ten to twenty users meet together under the direction of a
facilitator skilled in JAD techniques. The facilitator sets the meeting agenda and guides the
discussion but does not join in the discussion as a participant. He or she does not provide ideas or
opinions on the topics under discussion so as to remain neutral during the session. The facilitator
must be an expert in both group-process techniques and systems analysis and design technique.
JAD suffers from the traditional problems associated with groups: Sometimes people are
reluctant to challenge the opinions of others (particularly their boss), a few people often dominate the
discussion, and not everyone participates.
A new form of JAD called electronic JAD, or e-JAD, attempts to overcome these problems by using
groupware. In an e-JAD meeting room, each participant uses special software on a networked
computer to send anonymous ideas and opinions to everyone else. In this way, all participants can
contribute at the same time without fear of reprisal from people with differing opinions. A good JAD
approach follows a set of five steps:
a) Select Participants: JAD participants are selected in the same way as are interview participants, based
on the information they can contribute in order to provide a broad mix of organizational levels and
to build political support for the new system
b) Design a JAD Session: JAD sessions can run from as little as half a day to several weeks, depending
upon the size and scope of the project.
c) Preparing for JAD Session: As with interviewing, it is important to prepare the analysts and participants
for a JAD session.

12
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

d) Conducting a JAD Session: Most JAD sessions follow a formal agenda, and most have formal ground
rules that define appropriate behavior. Common ground rules include following the schedule,
respecting others’ opinions, accepting disagreement, and ensuring that only one person talks at a time.
e) Post-JAD Follow-up: As with interviews, a JAD post-session report is prepared and circulated among
session attendees.

3. Questionnaires
A questionnaire is a set of written questions used to obtain information from individuals.
Questionnaires are often used when there is a large number of people from whom information and
opinions are needed. In our experience, questionnaires are a common technique with systems intended
for use outside the organization (e.g., by customers or vendors) or for systems with business users
spread across many geographic locations. Most people automatically think of paper when they think
of questionnaires, but today more questionnaires are being distributed in electronic form, either via
e-mail or on the Web. Electronic distribution can save a significant amount of money as compared
to distributing paper questionnaires. A good process to use when using questionnaires follows four
steps:
a) Select Participants: As with interviews and JAD sessions, the first step is to identify the individuals
to whom the questionnaire will be sent. However, it is not usual to select every person who could
provide useful information. The standard approach is to select a sample, or subset, of people
who are representative of an entire group.
b) Designing a Questionnaire: Because the information on a questionnaire cannot be immediately
clarified for a confused respondent, developing good questions is critical for questionnaires.
Questions on questionnaires must be very clearly written and leave little room for
misunderstanding, so closed-ended questions tend to be most commonly used.
c) Administering the Questionnaire: The key issue in administering the questionnaire is getting
participants to complete the questionnaire and send it back. Dozens of marketing research
books have been written about ways to improve response rates. Commonly used techniques
include clearly explaining why the questionnaire is being conducted and why the respondent has
been selected, stating a date by which the questionnaire is to be returned, offering an inducement
to complete the questionnaire (e.g., a free pen), and offering to supply a summary of the
questionnaire responses.

13
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

d) Questionnaire Follow-up: It is helpful to process the returned questionnaires and develop a

questionnaire report soon after the questionnaire deadline. This ensures that the analysis process
proceeds in a timely fashion and that respondents who requested copies of the results receive
them promptly.
4. Document Analysis
Project teams often use document analysis to understand the as-is system. Under ideal
circumstances, the project team that developed the existing system will have produced documentation
that was then updated by all subsequent projects. In this case, the project team can start by reviewing
the documentation and examining the system itself.
Unfortunately, many systems are not well documented because project teams fail to document
their projects along the way, and when the projects are over, there is no time to go back and document.
Therefore, there might not be much technical documentation about the current systems available, or
it might not contain updated information about recent system changes.
The most powerful indication that the system needs to be changed is when users create their
own forms or add additional information to existing ones. Such changes clearly demonstrate the
need for improvements to existing systems. Thus, it is useful to review both blank and completed
forms to identify these deviations. Likewise, when users access multiple reports to satisfy their
information needs, it is a clear sign that new information or new information formats are
needed.

5. Observation
Observation, the act of watching processes being performed, is a powerful tool for gathering
information about the as-is system because it enables the analyst to see the reality of a situation,
rather than listening to others describe it in interviews or JAD sessions. Observation is a good way
to check the validity of information gathered from indirect sources such as interviews and
questionnaires.
The goal is to keep a low profile, to not interrupt those working, and to not influence those being
observed. Nonetheless, it is important to understand that what analysts observe may not be the
normal day-to-day routine because people tend to be extremely careful in their behavior when they
are being watched.

14
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

Selecting the Appropriate Techniques

Each of the requirements-gathering techniques discussed earlier has strengths and weaknesses. No
one technique is always better than the others, and in practice most projects use a combination of
techniques. Thus, it is important to understand the strengths and weaknesses of each technique and
when to use each (Table 1). One issue not discussed is that of the analysts’ experience. In general,
document analysis and observation require the least amount of training, whereas JAD sessions are the
most challenging.

Table 1: Table of requirements-gathering techniques.

BUSINESS PROCESS AND FUCNTIONAL MODELING

Introduction
Functional models describe business processes and the interaction of an information system with
its environment. In object-oriented systems development, two types of models are used to describe
the functionality of an information system: Use cases and Activity diagrams. Both can be used to
describe the current as-is system and the to-be system being developed.
We have discussed popular requirements-gathering techniques, such as interviewing, JAD, and
observation. Using these techniques, the analyst determined the requirements and created a
requirements definition. The requirements definition defined what the system is to do.
In this section, we discuss how the information that is gathered using these techniques is
organized and presented in the form of use-case and activity diagrams and use case
descriptions. Because Unified Modeling Language (UML) has been accepted as the standard notation
by the Object Management Group (OMG), almost all object-oriented development projects today use

15
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

these models to document and organize the requirements that are obtained during the analysis
workflow.
• A use case is a formal way of representing the way a business system interacts with its
environment. Essentially, a use case is a high-level overview of the business processes in a business
information system.
• Activity diagrams are typically used to augment our understanding of the business processes and
our use-case model. Technically, an activity diagram can be used for any type of process-modeling
activity.
Process models depict how a business system operates. They illustrate the processes or activities
that are performed and how objects (data) move among them. A process model can be used to
document a current system (i.e., as-is system) or a new system being developed (i.e., to-be system),
whether computerized or not.
Activity diagrams and use cases are logical models—models that describe the business domain’s
activities without suggesting how they are conducted. Reading a use-case or activity diagram, in
principle, should not indicate if an activity is computerized or manual, if a piece of information is
collected by paper form or via the Web, or if information is placed in a filing cabinet or a large
database. These models provide information that is needed to ultimately build the system.

BUSINESS PROCESS IDENTIFICATION WITH USE CASES AND USE-CASE DIAGRAMS

An analyst can employ use cases and the use-case diagram to better understand the functionality of
the system at a very high level. Typically, because a use-case diagram provides a simple,
straightforward way of communicating to the users exactly what the system will do. A use-
case diagram is drawn when gathering and defining requirements for the system.
Use-case diagram illustrates in a very simple way the main functions of the system and the different
kinds of users that will interact with it. Figure 2 describes the basic syntax rules for a use-case diagram.
Figure 3 presents a use-case diagram for the doctor’s office appointment system.

Elements of Use-Case Diagrams

The elements of a use-case diagram include actors, use cases, subject boundaries, and a set of
relationships among actors and use cases. These relationships consist of association, include, extend,
and generalization relationships.

16
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

Figure 2: Syntax for use-case Diagram

1. Actor
The stick figures on the diagram represents actors. An actor is not a specific user but instead is a role
that a user can play while interacting with the system. An actor can also represent another system
in which the current system interacts. In this case, the actor optionally can be represented by a
rectangle containing <<actor>> and the name of the system. Actors can provide input to the
system, receive output from the system, or both.
Sometimes an actor plays a specialized role of a more general type of actor. For example, there may
be times when a new patient interacts with the system in a way that is somewhat different from a
general patient. In this case, a specialized actor (i.e., new patient) can be placed on the model, shown
using a line with a hollow triangle at the end of the more- general actor (i.e., patient). The specialized
actor inherits the behavior of the more general actor and extends it in some way (see Figure 4).

17
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

Figure 3: Use-Case Diagram for the Appointment System.

2. Association
Use cases are connected to actors through association relationships; these relationships show with
which use cases the actors interact. A line drawn from an actor to a use case depicts an association.
The association typically represents two-way communication between the use case and the actor. If
the communication is only one way, then a solid arrowhead can be used to designate the direction
of the flow of information.
Finally, it is possible to represent the multiplicity of the association. Figure 3 shows an asterisk (*) at
either end of the association between the Patient and the Manage Appointments use case. This simply
indicates that an individual patient (instance of the Patient actor) executes the Manage Appointments
use case as many times as he or she wishes and that it is possible for the appointment part of the
Manage Appointments use case to be executed by many different patients.

Figure 4: Use-Case Diagram with a Specialized Actor

18
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

3. Use Case
A use case, depicted by an oval in the UML, is a major process that the system performs and that
benefits an actor or actors in some way (see Figure 3); it is labeled using a descriptive verb–noun
phrase. We can tell from Figure 3 that the system has three primary use cases: Manage Appointments,
Produce Schedule, and Record Availability.
There are times when a use case includes, extends, or generalizes the functionality of another use
case in the diagram. These are shown using include, extend, and generalization relationships. It
may be easier to understand these relationships with the help of examples.
Let’s assume that every time a patient makes an appointment, the patient is asked to verify payment arrangements.
However, it is occasionally necessary to actually make new payment arrangements. Therefore, we may want to have a use
case called Make Payment Arrangements that extends the Manage Appointments use case to include this additional
functionality. In Figure 5, an arrow labeled with extend was drawn from the Make Payment
Arrangements use case to the Manage Appointment use case to denote this special use-case
relationship. The Make Payment Arrangements use case was drawn lower than the Manage
Appointments use case.
Similarly, there are times when a single use case contains common functions that are used by other use cases. For example,
suppose there is a use case called Manage Schedule that performs some routine tasks needed to maintain the doctor’s
office appointment schedule, and the two use cases Record Availability and Produce Schedule both perform the routine
tasks. Figure 5 shows how we can design the system so that Manage Schedule is a shared use case that is used by others.
An arrow labeled with include is used to denote the include relationship, and the included use case is drawn
below the use cases that contain it. Notice that the arrows are drawn from the Record Availability and
Produce Schedule use cases to the common Manage Schedule use case.
Finally, there are times when it makes sense to use a generalization relationship to simplify the individual use
cases. For example, in Figure 5, the Manage Appointments use case has been specialized to include a use case for an
Old Patient and a New Patient. The Make Old Patient Appt. use case inherits the functionality of the Manage
Appointments use case (including the Make Payment Arrangements use-case extension) and extends its own
functionality with the Update Patient Information use case. The Make New Patient Appt use case also inherits all the
functionality of the generic Manage Appointments use case and calls the Create New Patient use case, which includes
the functionality necessary to insert the new patient into the patient database. The generalization relationship
is represented as an unlabeled hollow arrow with the more general use case being higher than
the lower use cases. Also, notice that we have added a second specialized actor, Old Patient, and
that the Patient actor is now simply a generalization of the Old and New Patient actors.

19
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

Figure 5: Extends and Include Relationships

4. Subject Boundary
The use cases are enclosed within a subject boundary, which is a box that defines the scope of the
system and clearly delineates what parts of the diagram are external or internal to it (see Figure 2). A
subject boundary can be used to separate a software system from its environment, a subsystem from
other subsystems within the software system, or an individual process in a software system. They also
can be used to separate an information system, including both software and internal actors, from its
environment. Care should be taken to decide what the scope of the information system is to be.

Identifying the Major Use Cases and Drawing the Use Case Diagram
1) The first step is to review the requirements definition
2) The second step is to identify the subject’s boundaries. This helps the analyst to identify the
scope of the system. However, as we work through the development process, the boundary of the
system most likely will change.

20
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

3) The third step is to identify the primary actors and their goals. The primary actors involved
with the system come from a list of stakeholders and users. Recall that a stakeholder is a person,
group, or organization that can affect (or will be affected by) a new system, whereas an actor is a
role that a stakeholder or user plays, not a specific user (e.g., doctor, not Dr. Jones).
4) The fourth step is to simply identify the business processes and major use cases. Rather than
jumping into one use case and describing it completely at this point, we only want to identify the
use cases.
5) The fifth step is to carefully review the current set of use cases. It may be necessary to split
some of them into multiple use cases or merge some of them into a single use case. Also,
based on the current set, a new use case may be identified. You should remember that identifying
use cases is an iterative process, with users often changing their minds about what a use case is
and what it includes. It is very easy to get trapped in the details at this point, so you need to
remember that the goal at this step is to only identify the major use cases.

BUSINESS PROCESS MODELING WITH ACTIVITY DIAGRAMS

Activity diagrams are used to model the behavior in a business process independent of objects. Activity
diagrams can be used to model everything from a high-level business workflow that involves many
different use cases, to the details of an individual use case, all the way down to the specific details of
an individual method. In a nutshell, activity diagrams can be used to model any type of process.

Elements of an Activity Diagram

Activity diagrams portray the primary activities and the relationships among the activities in a process.
Figure 6 shows the syntax of an activity diagram. Figure 7 presents a simple activity diagram that
represents the Manage Appointments use case of the appointment system for the doctor’s office
example.

21
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

Figure 6: Syntax of an Activity Diagram

22
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

Figure 7: Activity Diagram for the Manage Appointment Use case

BUSINESS PROCESS DOCUMENTATION WITH USE CASES AND USE-CASE

DESCRIPTIONS
Use-case descriptions provide a means to more fully document the different aspects of each
individual use case. The use-case descriptions are based on the identified requirements, use-case
diagram, and the activity diagram descriptions of the business processes.
Use cases capture the typical interaction of the system with the system’s users (end users and other
systems). These interactions represent the external, or functional, view of the system from the
perspective of the user. Each use case describes one and only one function in which users interact
with the system. Although a use case may contain several paths that a user can take while
interacting with the system, each possible execution path through the use case is referred to

23
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

as a scenario. Another way to look at a scenario is as if a scenario is an instantiation of a specific use

case.
When creating use-case descriptions, the project team must work closely with the users to fully
document the functional requirements. Organizing the functional requirements and documenting
them in a use-case description are a relatively simple process, but it takes considerable practice to
ensure that the descriptions are complete enough. The best place to begin is to review the use-case
and activity diagrams. The key thing to remember is that each use case is associated with one and only
one role that users have in the system. For example, a receptionist in a doctor’s office may play multiple
roles—he or she can make appointments, answer the telephone, fi le medical records, welcome
patients, and so on. It is possible that multiple users will play the same role. Therefore, use cases
should be associated with the roles played by the users and not with the users themselves.

Types of Use Cases

There are many different types of use cases. We suggest two separate dimensions on which to
classify a use case based on the purpose of the use case and the amount of information that the
use case contains:
• Overview versus Detail and
• Essential versus Real.
An overview use case is used to enable the analyst and user to agree on a high-level overview of the
requirements. Typically, overview use cases are created very early in the process of understanding the
system requirements, and they document only basic information about the use case, such as its
name; ID number; primary actor; type; a brief description; and the relationships among the actors,
actors and use cases, and use cases.
Once the user and the analyst agree upon a high-level overview of the requirements, the overview use
cases are converted to detail use cases. A detail use case typically documents, as far as possible, all the
information needed for the use case. Th ese can be based on the activities and control flows contained
in the activity diagrams.
An essential use case is one that describes only the minimum essential issues necessary to understand
the required functionality. A real use case goes farther and describes a specific set of steps. For
example, an essential use case in a doctor office might say that the receptionist should attempt to
match the patient’s desired appointment times with the available times, whereas a real use case might

24
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

say that the receptionist should look up the available dates on the calendar using Google Calendar to
determine if the requested appointment times were available.
The primary difference is that essential use cases are implementation independent, whereas real
use cases are detailed descriptions of how to use the system once it is implemented. Thus, real
use cases tend to be used only in the design, implementation, and testing.

Elements of a Use-Case Description

A use-case description has three basic parts: overview information, relationships, and the flow of
events.
• Overview Information: The overview information identifies the use case and provides basic
background information about the use case.
• Relationships: Use-case relationships explain how the use case is related to other use cases and users.
There are four basic types of relationships: association, extend, include, and generalization.
• Flow of Events: Finally, the individual steps within the business process are described. Three
different categories of steps, or flows of events, can be documented: normal flow of events, sub
flows, and alternative, or exceptional flows.
• Optional Characteristics: Other characteristics of use cases can be documented by use-case
descriptions. Th ese include the level of complexity of the use case; the estimated amount of time
it takes to execute the use case; the system with which the use case is associated; specific data flows
between the primary actor and the use case; any specific attribute, constraint, or operation
associated with the use case; any preconditions that must be satisfied for the use case to execute;
or any guarantees that can be made based on the execution of the use case.

25
System Analysis & Design (CSC 3307) | Jeremiah Isuwa

Figure 8: Sample Use-Case Description

Assignment.
Refer to assignment document and submit on or before set dateline. Prepare for presentation
of assignment as well.

26