Diploma in Information Technology

Module: Information Systems 3A

Module Code: IS310

STUDY GUIDE 2023

TABLE OF CONTENTS

A WORD OF WELCOME ................................................................................................................. 3

PURPOSE OF THE MODULE .......................................................................................................... 3
MODULE OUTCOMES .................................................................................................................... 3
PRESCRIBED TEXTBOOK.............................................................................................................. 3
STUDY UNIT 1: AN OVERVIEW OF SYSTEMS ANALYSIS AND DESIGN ............................. 4
STUDY UNIT 2: INVESTIGATING SYSTEM REQUIREMENTS ................................................ 8
STUDY UNIT 3: IDENTIFYING USE STORIES AND USE CASES ........................................... 16
STUDY UNIT 4: DOMAIN MODELING ....................................................................................... 22
STUDY UNIT 5: USE CASE MODELING .................................................................................... 31
STUDY UNIT 6: ESSENTIALS OF DESIGN AND THE DESIGN ACTIVITIES ........................ 41
A WORD OF WELCOME
Welcome to Welcome to the Information Systems 3A Module. This subject will be
presented on NQF level 7 and will bear 15 credits in terms of the new HEQSF.

PURPOSE OF THE MODULE

In general, this module gives an overview of systems analysis and design and investigates
system requirements. In addition, learners will understand and be able to describe different
information system models and the concept of domain modelling.

MODULE OUTCOMES
At the end of this module students should be able to know:
 The value of information systems is discussed.
 Information systems within business organisations are discussed.
 Input, output and processing devices are explained.
 Types of software and their applications are discussed.
 The use of organising data and information in organisations are explained.
 The importance of telecommunications and networks are debated.
 The Internet, intranet and extranets are evaluated.
 Electronic commerce and mobile commerce are discussed.
 Enterprise systems are described.
 Information and decision support systems are evaluated.
 Systems development is investigated and analysed.
 Information system design, implementation and maintenance are examined.
 The personal and social impact of computers is discussed.

PRESCRIBED TEXTBOOK
Textbook Author Year Publisher ISBN

Systems Analysis and

Satzinger.et
Design in a Changing 2015 Cengage 9781305117204
al
World

Study Guide Page 3 of 50 Damelin ©

 STUDY UNIT 1: AN OVERVIEW OF SYSTEMS ANALYSIS AND DESIGN

Introduction
The objective of this section is to introduce the student to basic concepts that are needed to
understand system development. The whole chapter defines System Analysis, System
Design, System Development Life Cycle, Iterative development, Agile development and the
six core processes to system development. At the end, a case study of Ridgeline Mountain
Outfitters (RMO) is designed and developed showing how the six core processes are used in
each iteration.

Learning outcomes:
After having worked through this study unit you will be able to:
 Describe the purpose of systems analysis and design in the development of an
information system
 Describe the characteristics of Agile methodologies and iterative systems
development
 Explain the SDLC and identify its core processes
 Describe how the six core processes of the SDLC are used in each iteration
 Identify key diagrams used in systems analysis and systems design
 Explain the utility of identifying use cases in systems development
 Explain the utility of identifying object classes in systems development

Software development

Figure 1.1 shows the difference between system analysis and system design

System analysis System design

What is required for the new How the system will operate to
system to solve the problem? solve the problem?

• Systems analysis – these are activities that enable a person to understand and
specify what an information system should accomplish

• Systems design – these are activities that enable a person to define and describe in
detail the system that solves the need

SDLC (System Development Life Cycle)

The SDLC is a framework that identifies all the activities required to research, build, deploy
and maintain an information system. The SDLC defines all the activities required to develop
a new system that is starting from planning, analysis, design, implementation and
maintenance. There are many different versions of the SDLC. This section distils out six core
process required for the development of any new system. In other words, these six core
processes are common to all types of SDLCs. By understanding these six core processes,
students will not only be able to develop new systems effectively, but they will be able to
adapt to any other SDLC that they may encounter in industry. The six core processes are:
1. Identify the problem or need and obtain approval to proceed.
2. Plan and monitor the project—what to do, how to do it, and who does it.

Study Guide Page 4 of 50 Damelin ©

3. Discover and understand the details of the problem or the need.
4. Design the system components that solve the problem or satisfy the need.
5. Build, test, and integrate system components.
6. Complete system tests and then deploy the solution.
Table 1.1 illustrates the core processes to system development

Source: Satzinger et al. (2015)

Iterative Development
Iterative development is an approach to system development in which the system is grown/
developed piece by piece through multiple mini projects called iterations. Iterative
Development illustrates six core processes and how they are utilized across various
iterations to develop a new system. Core processes and iterative development are common
themes for many types of SDLCs, including the Unified Process, Extreme Programming, and
Scrum. Again, the approach in the prescribed textbook is to teach the students the general
concepts so that they can apply them in their own activities or within the framework of a
corporate environment.

Case study of RMO

The following is a sample project showing several iterations and activities within each
iteration:

Pre-Project Activities
Pre-project activities are those activities required to get the project approved and started.
There are two major objectives namely:
• Identify the problem and document the objective of the system (core process 1) and
within this activity the following needs to be done:
o Preliminary investigation
o System Vision Document
• Obtain approval to commence the project (core process 1). When obtaining approval
the System Analyst need to:
o Meet with key stakeholders, including executive management
o Make decisions and then the plan should be approved as well as the budget

Study Guide Page 5 of 50 Damelin ©

Day 1 Activities

 Core Process 2: Plan the Project

• Determine the major components (functional areas) that are needed
o Supplier information subsystem
o Product information subsystem
• Define the iterations and assign each function to an iteration
o Decide to do Supplier subsystem first
o Plan one iteration as it is small and straight forward
• Determine team members and responsibilities
o Use a WBS (Work Breakdown Structure ) to identify the tasks and the
duration needed for each task
Day 2 Activities
• Core Process 3: Discover and Understand Details
• Do preliminary fact-finding to understand requirements
• Develop a preliminary list of use cases and a use case diagram
• Develop a preliminary list of classes and a class diagram
Day 3 Activities
• Core Process 3: Discover and Understand Details
• Do in-depth fact-finding to understand requirements
• Understand and document the detailed workflow of each use case
• Core Process 4: Design System Components
• Define the user experience with screens and report sketches
Day 4 Activities
• Core Process 4: Design System Components
• Design the database (schema)
• Design the system’s high level structure
• Browser, Windows, or Smart phone
• Architectural configuration (components)
• Design class diagram
• Subsystem architectural design
Day 5 Activities
• Core Process 4: Detailed Design System Components
• Continue with design details
• Proceed use case by use case
• Core Process 5: Build, Test, and Integrate System Components
• Continue programming (build)
• Build use case by use case
• Perform unit and integration tests
Day 6 Activities
• Core Process 6: Complete System Testing and Deploy the System
• Perform system functional testing
• Perform user acceptance testing
• Possibly deploy part of system

Study Guide Page 6 of 50 Damelin ©

Key Terms
 Computer application (app)—a computer software program that executes on a
computing device to carry out a specific function or set of related functions
 Information system—a set of interrelated computer components that collects,
processes, stores, and provides as output the information needed to complete
business tasks
 Systems analysis—those activities that enable a person to understand and specify
what the new system should accomplish
 Systems design—those activities that enable a person to define and describe in
detail the system that solves the need
 Project—a planned undertaking that has a beginning and an end, and that produces
some definite result
 Systems Development Life Cycle (SDLC)—the entire process consisting of all the
activities required to build, launch, and maintain an information system
 Information systems development process—the actual approach used to develop
a particular information system
 Agile Development—an information systems development process that emphasizes
flexibility to anticipate or adapt any new requirements during development
 Iterative development—an approach to system development in which the system is
"grown" piece by piece through multiple iterations

Summary of the study unit

 The system life cycle
 Iterative development
 Agile development
 Project activities
 Stages in the SDLC

Self-assessment and reflection

Answer the following questions to check whether you have achieved all the set
outcomes:
1. Give a brief explanation of the general SDLC phases.
2. What is prototyping? List and explain 4 advantages and 3 disadvantages of prototyping
3. What is the purpose of system analysis? Why is it important?
4. State the reason why you think that it is important to carry out requirements analysis
before design and coding starts.
5. What do you understand by the terms Predictive Approach and Adaptive Approach to
the SDLC? Give examples of each approach
6. What is a WBS? How does it helps in determining the project duration
7. What is a System Vision Document? What the purpose of a System Vision Document.
Briefly explain the major activities of a System Vision Document
8. What is the basic philosophy of Agile development?
9. Discuss any 3 benefits of using Iterative development as compared to Structured
development

Study Guide Page 7 of 50 Damelin ©

 STUDY UNIT 2: INVESTIGATING SYSTEM REQUIREMENTS

Introduction
In Study Unit 1 we introduced the six core processes of the SDLC. In this Study Unit we
focus on the third core process: "Discover and understand the details of the problem and the
need." Another major topic in this study unit 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. Finally the chapter ends with
instructions on how to use UML activity diagrams to document user work flows. This study
unit is an important study unit with key concepts to help the students understand the need
and the importance of system analysis and how to gather user requirements.

Learning outcomes:
After having worked through this study unit you will 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 Activities

Table 2.1 shows all the analysis activities which take place during system development

Source: Satzinger et al. (2015)

The above diagram illustrates the five systems analysis activities that make up core process
number three. 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.

Gather Detailed Information

At the 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 (thus observation). They obtain

Study Guide Page 8 of 50 Damelin ©

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 (non-functional requirements). 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 ensure 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. Requirements can be either
system or user requirements.

System Requirements
 Are all activities the new system must perform or support and the constraints that the
new system must meet? It can be either Functional requirements or Non-functional
requirements.
o Functional Requirements– the activities the system must perform, it can
be business uses or functions the users carry out.
o Non-Functional Requirements - other system characteristics, like
constraints and performance goals. FURPS+ is the commonly used
framework to determine non-functional requirements. FURPS+ stands for
Functionality Usability Reliability Performance and Security. Non-

Study Guide Page 9 of 50 Damelin ©

 functional requirements has also design constraints which needs to be
taken into consideration such as:
 Implementation
 Interface
 Physical
 Support

Models and Modeling

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
Frequently students will disparage the need to build models. However, 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. 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 study
guide conform to UML 2.0 specifications.

Stakeholders
 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

Study Guide Page 10 of 50 Damelin ©

  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.

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 also stakeholders because they have an oversight
responsibility to ensure that the new system meets all the operational criteria for the
organization.

Information-Gathering Techniques
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
 Collecting active user comments and suggestions

Interviewing users and other stakeholders

This is the most frequently used method even though it is 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

NB Interview questions can be open or closed questions. Open questions encourage

discussion and explanation whereas closed questions are used to get specific facts

Question Themes
When analysts are preparing questions, they should consider the following 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

Study Guide Page 11 of 50 Damelin ©

 discern which of those functions fundamental business functions are, 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.

A difficult issue in interviewing users and other stakeholders is whether to focus the
questions around the existing system or to emphasize only on 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 is to ensure that correct requirements are obtained for the new
system. So if the new system duplicates many of the extent business processes,
then those processes should be reviewed.

Planning and conducting an Interview

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 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.

Study Guide Page 12 of 50 Damelin ©

 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 collecting 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. The second source of inputs, outputs, and procedures is existing
business documents and procedure descriptions within the organization.

Observing and documenting 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.

Researching 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.

Collecting 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.

Reviewing inputs, outputs, and documentation

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. And another source is internal documents.

Documenting Workflows with Activity Diagrams

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.

Study Guide Page 13 of 50 Damelin ©

Creating activity diagrams to document workflows is straightforward. The first step is to
identify the agents to create the appropriate swim lanes. Next, follow the various steps of the
workflow and then make appropriate ovals for the activities. Usually there is a swim lane for
the actor or user of the system, and another swim lane 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.

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
 Non-functional 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
 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
 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
 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

Study Guide Page 14 of 50 Damelin ©

  Swim lane – heading activity diagram column containing all activities for a single
agent or organizational unit

Summary of the study unit

 Activities of system analysis
 System requirements
 Types of stakeholders
 Information gathering techniques
 Documenting workflows with activity diagrams
 Models and modeling

Self-assessment and reflection

Answer the following questions to check whether you have achieved all the set
outcomes:
1. Briefly discuss the activities of core process 3: Discover and understand the details
2. What is a Stakeholder? Explain the different types of Stakeholders
3. Functional requirements and non-functional requirements are not easy to distinguish.
One way to do so is to use the FURPS+ framework. Discuss the framework in detail
4. Discuss any three information gathering techniques which a System Analyst can use
during System Analysis
5. You have been employed as a Junior System Analyst at an upcoming organization,
there is need for a new system to be developed for Payroll department and you have
been tasked to interview current users of the system. Design a checklist for conducting
an interview.
6. What are the primary reasons for creating models during systems development?

Study Guide Page 15 of 50 Damelin ©

 STUDY UNIT 3: IDENTIFYING USE STORIES AND USE CASES

Introduction
This topic describes an overview of system analysis activities, functional, non-functional
requirements, modeling and information gathering techniques. It also focuses on identifying
and modeling the key aspects of functional requirements which is the Use Case.

Learning outcomes:
After having worked through this study unit you will be able to:
 Explain why identifying uses cases is the key to defining functional requirements
 Write user stories with acceptance criteria
 Describe the two techniques for identifying use cases
 Apply the user goal technique to identify use cases
 Apply the event decomposition technique to identify use cases
 Describe the notation and purpose for the use case diagram

User Stories and Use Cases

User Story

A User Story is a one-sentence description of a work-related task done by a user to achieve

some goal or result. User story describes a goal the user has when using a system.
Acceptance Criteria identify the features that must be present at the completion of the task.
For example a User Story can be a student graduating and then the acceptance criteria can
be student should have completed and passed all the modules or sort all the modules
completed by year etc. NB for each user story, they can be several acceptance criteria
which needs to be taken into consideration.

Use Case

Is an activity that the system performs, usually in response to a request by a user. Use
Cases define functional requirements. A System Analyst needs to decompose the system
into a set of use cases using the functional decomposition. The following are techniques for
identifying use cases:

 User goal technique OR

 Event decomposition technique

User goal technique

 Is a technique to identify use cases by determining what specific goals or objectives

must be completed by the system for the user? Users need to describe their goals
for using the new or updated system. It has the following steps:
o Identify all the potential users for the new system
o Classify the potential users in terms of their functional role (e.g., shipping,
marketing, sales)
o Further classify potential users by organizational level (e.g., operational,
management, executive)

Study Guide Page 16 of 50 Damelin ©

 o For each type of user, interview them to find a list of specific goals they will
have when using the new system (current goals and innovative functions to
add value)
o Create a list of preliminary use cases organized by type of user
o Look for duplicates with similar use case names and resolve inconsistencies
o Identify where different types of users need the same use cases
o Review the completed list with each type of user and then with interested
stakeholders

Event Decomposition

 It is a more comprehensive and complete technique which identify use cases by

determining the business events to which the system must respond
 Identifies all business events the information system responds to, with each event
leading to a use case
 Focuses on the EBP (Elementary Business Processes) which occurs in response to
a business event.

Types of Events

 External Event
o An event that occurs outside the system, usually initiated by an external agent
or actor for example management need certain information regarding a
certain transaction.
 Temporal Event
o An event that occurs as a result of reaching a point in time for example
monthly statements to customers.
 State Event
o An event that occurs when something happens inside the system that triggers
some process for example reorder point is reached for inventory item.

Steps in the Event Decomposition technique

 Consider the external events in the system environment that require a response from
the system by using the checklist shown below

Study Guide Page 17 of 50 Damelin ©

Figure 3.1 shows an example of a checklist which can be used to identify use cases

Source: Satzinger et al. (2015)

 For each external event, identify and name the use case that the system requires
 Consider the temporal events that require a response from the system by using the
checklist shown above.
 For each temporal event, identify and name the use case that the system requires
and then establish the point of time that will trigger the use case
 Consider the state events that the system might respond to, particularly if it is a real-
time system in which devices or internal state changes trigger use cases.
 For each state event, identify and name the use case that the system requires and
then define the state change.
 When events and use cases are defined, check to see if they are required by using
the perfect technology assumption. Do not include events that involve such system
controls as login, logout, change password, and backup or restore the database, as
these are put in later.

Benefits of using the Event Decomposition technique

1. Events are broader than user goal technique that is event decomposition technique
captures temporal and state events as they occur.
2. Help decompose at the right level of analysis through the use of an Elementary
Business Process (EBP)
3. EBP is a fundamental business process performed by one person, in one place, in
response to a business event

Study Guide Page 18 of 50 Damelin ©

 4. Uses perfect technology assumption to make sure functions that support the users
work are identified and not additional functions for security and system controls

Use Case Symbols

Figure 3.2 illustrates Use Case symbols

Source: Satzinger et al. (2015)

Use Case Diagrams— the <<Includes>> relationship

 A relationship between use cases where one use case is stereotypically included
within the other use case— like a subroutine. Arrow points to subroutines

Figure 3.4 shows an example of a use case for sales subsystem

Study Guide Page 19 of 50 Damelin ©

Source: Satzinger et al. (2015)

Developing a Use Case Diagram

1. Identify all the stakeholders and users who would benefit by seeing a use case
diagram
2. Determine what each stakeholder or user needs to review in a use case diagram:
each subsystem, for each type of user, for use cases that are of interest
3. For each potential communication need, select the use cases and actors to show and
draw the use case diagram. There are many software packages that can be used to
draw use case diagrams like Microsoft Visio.
4. Carefully name each use case diagram and then note how and when the diagram
should be used to review use cases with stakeholders and users

Aspects of requirements and data modeling must be studied

Summary of the study unit

 User Stories and Use Cases

 Techniques used to identify use cases

 Steps to be followed in the User goal technique

 Steps to be followed in the Event decomposition technique

 Steps to be followed when developing a Use Case

Study Guide Page 20 of 50 Damelin ©

Self-assessment and reflection

Answer the following questions to check whether you have achieved all the set
outcomes:

1. What does the acronym UML stands for?

2. Using a Point Of Sale system, a student needs to identify three user stories and
acceptance criteria for each User Story
3. Draw a Use case diagram for a Point Of Sale system clearly showing all the actors
involved and any relationships among use cases

Study Guide Page 21 of 50 Damelin ©

 STUDY UNIT 4: DOMAIN MODELING

Introduction
The focus of this study guide is to identify and define the entities or problem domain classes.
Traditional system development methodologies called these “things” data entities and used
Entity-Relationship Diagrams to model the data structure. Object-oriented techniques call
these “things” problem domain classes, or just classes for short. A UML class diagram is
used to model the data structure. Students should be familiar with both Entity-Relationship
diagrams and Class diagrams.

The first part of the chapter is a discussion to help students find, identify, and classify these
“things.”
The second part of the study unit instructs how to build an entity-relationship diagram, and
the final topic in the chapter is how to build a class diagram domain model.
Learning outcomes:
After having worked through this study unit you will be able to:
 Explain how the concept of “things” in the problem domain also defines requirements
 Identify and analyze data entities and domain classes needed in the system
 Read, interpret, and create an entity-relationship diagram
 Read, interpret, and create a domain model class diagram
 Understand the domain model class diagram for the RMO Consolidated Sales and
Marketing
System

“Things” in the Problem Domain

A basic problem with data modeling is what to use for the generic term of items in the real
world that a system analyst is trying to discover. We have chosen to simply call them
“things.” Although “things” is a very ambiguous term that can be used to identify almost any
real world item or abstract idea, that information is in fact what data modeling is trying to
capture. The discussion on finding “things” is really quite comprehensive and should provide
a good foundation for the students.

The term “problem domain” is an interesting word choice. Often when we think of problem,
we think that something is broken. However, in this context, the word problem simply means
a need that requires a business solution. In other words, system developers are developing
a solution for a business need or business problem.

The Brainstorming Technique

 This technique is a joint effort between the analyst and the users. It is used to identify
problem domain classes where developers work with users to identify different types of
things they use in their work. The following questions needs to be asked:

o Are there any tangible things?

o Are there any organizational units?

o Are they any sites/locations?

o Are there roles played by people that you need to remember?

Study Guide Page 22 of 50 Damelin ©

 o Are there incidents or events that need to be recorded?

 And all the above questions are summarized below:

Figure 4.1 shows a summary of ‘things’

Source: Satzinger et al. (2015)

Here are the steps to follow when using the brainstorming technique:
1. Identify a user and a set of use cases.
2. Brainstorm with the user to identify things involved when carrying out the use case—that
is, things about which information should be captured by the system.
3. Use the types of things (categories) to systematically ask questions about potential things,
such as those questions asked previously.
4. Continue to work with all types of users and stakeholders to expand the brainstorming list.
5. Merge the results, eliminate any duplicates, and compile an initial list. Care should be
taken to distinguish between classes and attributes.

The Noun Technique

The noun technique is a more mechanical approach to identifying classes, but it is also a
powerful technique. The basic idea is to identify all the nouns, which are always some type
of “thing,” and build the list of all these nouns. Then refine the list to remove duplicates and
identify which are classes and which are attributes of classes.

Here are the steps to follow when using the noun technique:
1. Using the use cases, actors, and other information about the system—including inputs
and outputs—identify all nouns.
2. Using other information from existing systems, current procedures, and current reports or
forms, add items or categories of information needed.
3. As this list of nouns builds, you will need to refine it. Ask these questions about each noun
to help you decide whether you should include it:

Study Guide Page 23 of 50 Damelin ©

  Ask questions, such as is it important and inside the scope, to see if it should be
included.
 Ask questions to see if it should be excluded, such as is it only a report or an input or
is it an attribute.
 Ask questions to see if it needs further research. In other words that you cannot
answer whether it needs to be included or excluded.
4. Create a master list of all nouns identified and then note whether each one should be
included, excluded, or researched further.
5. Review the list with users, stakeholders, and team members and then refine the list of
things in the problem domain.

Attributes of Things
The noun technique involves listing all the nouns that come up in discussions or documents
about the requirements. Many of these nouns are actually attributes. During the refinement
of the nouns on the list of nouns, an evaluation of each noun will determine whether the
noun is an independent item, e.g. a class, or whether it describes or characterizes another
noun and hence is an attribute. One attribute may be used to identify a specific thing, such
as a Social Security number for an employee or an order number for a purchase. The
attribute that uniquely identifies the thing is called an identifier or key.

Associations among Things

An association is a naturally occurring relationship between specific things, such as an order
is placed by a customer and an employee works in a department. Is placed by and works in
are two associations that naturally occur between specific things. Information systems need
to store information about employees and about departments, but equally important is
storing information about the specific associations. In database management, the term
relationship is often used in place of association, which is the term used when modeling in
UML. We will use association in this book because we emphasize UML diagrams and terms.

It is also important to understand the nature of each association in terms of the number of
links for each thing. Cardinality can be one-to-one or one-to-many. The term multiplicity is
used to refer to the number of links in UML and should be used when discussing UML
models. Multiplicity is established for each direction of the association. It is important to
describe not just the multiplicity but also the range of possible values of the multiplicity (the
minimum and maximum multiplicity). These terms are referred to as multiplicity constraints.
The next sections on the notation explain more about the various combinations of cardinality
and multiplicity constraints.

Associations between two classes are called binary associations. Sometimes an association
will be between different elements in the same class or set. These are called unary
associations. Associations can also exist between multiple classes, such as three classes –
a ternary association, or some arbitrary number n-ary associations.

The Entity-Relationship Diagram

A data model commonly used by traditional analysts and database analysts is called the
Entity Relationship Diagram (ERD). The ERD is not a UML diagram, but it is very commonly

Study Guide Page 24 of 50 Damelin ©

used and is quite similar to the UML domain model class diagram. An ERD consists of data
entities, attributes and relationships among entities.

Examples of ERD Notation

On the entity-relationship diagram, rectangles represent data entities, and the lines
connecting the rectangles show the relationships among data entities. Cardinality constraints
are expressed by the notations on the lines. Remember that the cardinality applies to each
end of the relationship and contains a minimum and maximum value.

Figure 4.2 is an example which illustrates cardinalities

Source: Satzinger et al. (2015)

Sometimes it is obvious what the relationships between data entities should be. Often it is
also clear what the cardinality constraints should be. However, when it is not clear, creating
a semantic net can be helpful. A semantic net is simply a drawing of the individual data
entities showing what relationships can exist. For example in the diagram above, orders are
always only connected to one customer, but a customer will have multiple orders. It is even
possible to have a customer, such as Mary, that has not made any orders yet. A semantic
net can be useful to help define cardinality constraints.

ERD Cardinality Symbols

Study Guide Page 25 of 50 Damelin ©

Figure 4.3 shows Cardinality symbols

Source: Satzinger et al. (2015)

The Domain Model Class Diagram

 Class
o A type of classification used to describe a collection of objects
 Domain Class
o Classes that describe objects in the problem domain
 Class Diagram
o A UML diagram that shows classes with attributes and associations
 Domain Model Class Diagram
o A class diagram that only includes classes from the problem domain, not
software classes and methods

UML Notation for Multiplicity

Figure 4.4 illustrates Multiplicity notations

Source: Satzinger et al. (2015)

Current approaches to system development, primarily object-oriented approaches, use the

term class rather than data entity and use concepts and notations based on UML to model

Study Guide Page 26 of 50 Damelin ©

the things in the problem domain. Class is a category or classification used to describe a set
of objects. So a class is a category, but it is also a set of objects. Classes that describe
things in the problem domain are called domain classes. Domain classes have attributes and
associations. Multiplicity (called cardinality in an ERD) applies among classes.

On a class diagram, rectangles represent classes, and the lines connecting the rectangles
show the associations among classes. The domain class symbol is a rectangle with two
sections. The top section contains the name of the class, and the bottom section lists the
attributes of the class. Class names are capitalized and attributes begin with lower case.
Both use camel case notation. Later, you will learn that the design class symbol includes a
third section at the bottom for listing methods of the class; methods do not apply to problem
domain classes.

Domain Model Class Diagram Notation

This section contains many examples of UML class diagram notation as explained above.
Multiplicity is denoted by numbers placed next to the class at either end of a binary
association line. Minimum and maximum multiplicity is denoted by 0….1 (zero or one) and
1…..* (one or many), and so forth.

Many-to-many associations allow data objects from one class to be connected to many
objects of the associated class, and this association occurs in both directions. Sometimes
the association itself will need to have attributes associated with it. An example of where a
CourseSection will have many students and a Student will be registered in many course
sections. The student also will receive a grade for that course section. The grade cannot be
associated solely with the student, nor with the course section. The grade belongs to the
association. In other words we need to treat the CourseSection—Student association as a
class (thus an association class). (Note the troubleshooting tips for this topic. Students often
have problems identifying association classes.)

More Complex Issues about Classes of Objects

Generalization/Specialization relationships are based on the idea that people classify
things in terms of similarities and differences. A generalization/specialization relationship is
used to structure these things from the more general to the more special. Each class of
things in the hierarchy might have a more general class above it, called a superclass. At the
same time, a class might have a more specialized class below it, called a subclass. UML
class diagram notation uses a triangle that points to the superclass to show a
generalization/specialization hierarchy. For example a bank account can be either a current
account or savings account, so when one says he/she has a bank account thus
generalization but if one says he/she has a current account or savings account thus
specialization. All this explanation is illustrated below:

Study Guide Page 27 of 50 Damelin ©

Figure 4.5 shows an example which illustrates the concept of generalization or specialization

Source: www.dotnettricks.com

A generalization/specialization relationship is also a set/subset relationship. All of the objects

in the specialized class are also within the generalized class. Thus all of the attributes in the
generalized class are also attributes of the specialized class. This is called inheritance, since
the subclass or subset inherits the attributes of the superclass or superset. Sometimes the
superclass is defined only to allow inheritance of attributes, but has no actual real-life objects
in it. In that situation, we call the superclass an abstract class, and are denoted by an
italicized name. A class that does have objects is a concrete class.

Whole-part relationships are used to show an association between one class and other
classes that are parts of that class. There are two types of whole-part relationships:
aggregation and composition.
Aggregation refers to a type of whole-part relationship between the aggregate (whole) and
its components (parts), where the parts can exist separately and is represented by an open
diamond.
Composition refers to whole-part relationships that are even stronger, where the parts, once
associated, can no longer exist separately, and is represented by a solid dark diamond.
Whole-part relationships— aggregation and composition—mainly allow the analyst to
express subtle distinctions about associations among classes. As with any association,
multiplicity can apply.

Key Terms
 Problem domain – the specific area (or domain) of the user’s business need (or
problem) that is within the scope of the new system
 Brainstorming technique – a technique to identify problem domain objects in which
developers work with users in an open group setting
 Noun technique – a technique to identify problem domain objects by finding and
classifying the nouns in a dialog or description
 Attributes – descriptive pieces of information about things or objects
 Identifier or key – an attribute the value of which uniquely identifies an individual
thing or object
 Compound attribute – an attribute that consists of multiple pieces of information but
is best treated in the aggregate

Study Guide Page 28 of 50 Damelin ©

  Association – a term, in UML, that describes a naturally occurring relationship
between specific things, sometimes called a relationship
 Relationship – a term that describes a naturally occurring association between
specific things, sometimes called an association
 Cardinality – a measure of the number of links between one object and another
object in a relationship
 Multiplicity – a measure, in UML, of the number of links between one object and
another object in an association
 Multiplicity constraints – the actual numeric count of the constraints on objects
allowed in an association
 Binary associations – associations between exactly two distinct types of things
 Unary association – an association between two instances of the same type of thing
 Ternary association – an association between exactly three distinct types of things
 N-ary association – an association between n distinct types of things
 Camelback notation or camelcase notation – when words are concatenated to
form a single word and the first letter of each embedded word is capitalized
 Association class – an association that is also treated as a class; often required in
order to capture attributes for the association
 Generalization/specialization relationship – a type of hierarchical relationship in
which subordinate classes are subsets of objects of the superior classes; an
inheritance hierarchy
 Superclass – the superior or more general class in a generalization/specialization
relationship
 Subclass – the subordinate or more specialized class in a
generalization/specialization relationship
 Inheritance – the concept that specialization classes inherit the attributes of the
generalization class
 Abstract class – a class that describes a category or set of objects but that never
includes individual objects or instances
 Concrete class – a class that allows individual objects or instances to exist
 Whole-part relationship – a relationship between classes in which one class is a
part or a component portion of another class
 Aggregation – a type of whole-part relationship in which the component parts also
exist as individual objects apart from the aggregate
 Composition – a type of whole-part relationship in which the component parts
cannot exist as individual objects apart from the total composition
 Data entities – the term used in an ER diagram to describe sets of things or
individual things
 Entity-relationship diagram (ERD) – a diagram consisting of data entities (i.e., sets
of things) and their relationships
 Semantic net – a graphical representation of an individual data entity and its
relationship with other individual data entities

Study Guide Page 29 of 50 Damelin ©

Activity and system sequence diagrams must be studied

Summary of the study unit

 We learnt how to develop use case
 We learnt how to develop activity diagrams
 We learnt how to develop class diagrams and ERDs
 We learnt how to develop SSDs and State machine diagrams

Self-assessment and reflection

Answer the following questions to check whether you have achieved all the set
outcomes:
1. List 10 tips for creating useful Use Cases
2. What are the key components a use case?
3. Design part of a class diagram showing a student registering for a course. In your
answer clearly show any generalization / specialization
4. Draw an ERD for a bank that has many branches. Each branch has one or more
accounts. Each account is owned by one customer and results in one or more
transactions.

Study Guide Page 30 of 50 Damelin ©

 STUDY UNIT 5: USE CASE MODELING

Introduction
The main objective of defining requirements in system development is understanding users’
needs, how the business processes are carried out, and how the system will be used to
support those business processes. Model building is one of the best ways for analysts to
understand the business processes and to remember what they have learned from their fact
finding activities.

This study unit explains four types of models and how they are used to capture the business
rules and processes. Three of the models extend the definitions of the use cases, and the
final model extends information about the classes. Use case related models are the “fully
developed use case description,” UML activity diagrams, and UML system sequence
diagrams (SSD). The “fully developed use case descriptions” are used to document the
context, purpose, description, conditions, and workflow of each use case. Activity diagrams
are a graphical depiction of the use case workflow and are useful in illustrating the
alternative paths through a business process. SSDs are used to document the inputs and
outputs that are passed between the user and the system during a use case. Not only do
these models document the internal steps of a use case, but the very act of developing
these models force the analyst to ask detailed questions and help improve the
understanding of the requirements.

The State machine diagram is a class related model. For some object classes in the domain
model it is necessary to understand the life cycle of individual objects. This is especially true
for business objects that can have different status conditions. A state machine diagram
documents what these status conditions are and how an object changes status condition by
transitioning from state to state.

After reading this study unit, the student should be able to:
 Write fully developed use case descriptions
 Develop activity diagrams to model flow of activities
 Develop system sequence diagrams
 Use the CRUD technique to validate Use Cases
 Explain how use case descriptions and UML diagrams work together to define
functional requirements

Use Case Descriptions

A use case description lists and describes the processing details for a use case. Implied in
all use cases is a person who uses the system. In UML, that person is called an actor, as
shown on use case diagrams. Another way to think of an actor is as a role.

Internally, a use case includes a whole sequence of steps to complete a business process.
Frequently, several variations of the business steps exist within a single use case. These
different flows of activities are called scenarios or sometimes use case instances. Thus, a
scenario is a unique set of internal activities within a use case and represents a unique path
through the use case.

Study Guide Page 31 of 50 Damelin ©

 A use case description provides the documentation for the processing steps that are internal
to a use case. There may be several descriptions, each one describing a different scenario.
Depending on an analyst’s needs, use case descriptions tend to be written at two separate
levels of detail: brief description and fully developed description. As shown later in the
chapter, an activity diagram is also a useful technique to describe the internal processing of
a use case.

Brief Use Case Descriptions

A brief description can be used for very simple use cases, especially when the system to be
developed is a small, well-understood application. A simple use case would normally have a
single scenario and very few—if any—exception conditions. The following diagram illustrates
several single sentences brief descriptions. A brief description does not document the
internal processing since for simple use cases there are few steps.

Table 5.1 shows an example of a Use Case and a description of that use case

Source: Satzinger et al. (2015)

Fully Developed Use Case Descriptions

The fully developed description is the most formal method for documenting a use case. The
following items document each row of the example shown in the following table:

Study Guide Page 32 of 50 Damelin ©

Table 5.2 is an example of a fully developed Use Case

Source: Satzinger et al. (2015)

Use Case Description Details

 Use case name
o Verb-noun or a unique name for the use case
 Scenario (if needed)
o An instance of the use case being documented
o A use case can have more than one scenario (special case or more specific
path)
 Triggering event
o Based on event decomposition technique and it is a business event that
initiates or triggers the use case
 Brief description
o These are one or two sentence description of the results of a use case.
 Actors
o One or more users from use case diagrams or all the actors who use the use
case.
 Related use cases <<includes>>
o If one use case invokes or includes another use case
 Stakeholders
o Anyone with an interest in the results or successful completion of this use
case
 Preconditions
o What must be true before the use case begins or the state of the system
before the use case begins
 Post conditions
o What must be true when the use case is completed? Mostly used for planning
test case expected results
 Flow of activities

Study Guide Page 33 of 50 Damelin ©

 oThe activities that go in between the actor and the system. It is a step by step
sequence of the actions by the actor and the system internal to the use case.
 Exception conditions
o Where and what can go wrong. Or any exception conditions that cause the
system not to follow the expected flow of activities or that cause the use case
to terminate abnormally

Usually the flow of activities is the most difficult part to develop, but also assists the analyst
and the user to understand the requirements more deeply.

Activity Diagrams for Use Cases

An activity diagram is an easily understood diagram to document the workflows of the
business processes. Activity diagrams are standard UML diagrams that have an effective
technique to document the flow of activities within a use case. Activity diagrams are helpful
when the flow of activities for a use case is complex.

The System Sequence Diagram – Identifying Inputs and Outputs

In the object-oriented approach, the flow of information is achieved through sending
messages either to and from actors or back and forth between internal objects. A system
sequence diagram (SSD) is used to describe this flow of information into and out of the
automated system, e.g. between the actor and the system. Often an SSD is used in
conjunction with an activity diagram to get a complete picture of the steps and information
flow of a use case.

System Sequence Diagram (SSD) Notation

In a use case diagram, the actor “uses” the system, but the emphasis in an SSD is on how
the actor “interacts” with the system by entering input data and receiving output data. Refer
to figure below for the basic notation used in an SSD. A stick figure represents an actor. The
box labeled: System is an object that represents the entire automated system. (UMO object
notation is similar to UML class notation, except the object name is often preceded by a
colon and is underlined.)
Connected to the actor and the: System object are dashed lines, which represent life lines.
Messages are passed between the actor and the: System and are assumed to be passed
sequentially top to bottom along the life lines.

Study Guide Page 34 of 50 Damelin ©

Figure 5.1 illustrates symbols used when designing a System Sequence diagram

Source: Satzinger et al. (2015)

A message is documented with an arrow and a message descriptor. Since a SSD is a UML
object oriented model, the syntax for the messages is similar to interaction, e.g.
programming methods, syntax that is found in various Object Oriented Programming
languages. Here is a notation for the message descriptor:
*[true/false condition] return-value: = message-name (parameter-list)

Any part of the message can be omitted. In brief, the notation components do the following:
 An asterisk (*) indicates repeating or looping of the message.
 Brackets [ ] indicate a true/false condition. This is a test for that message only. If it
evaluates to true, the message is sent. If it evaluates to false, the message isn’t sent.
 Message-name is the description of the requested service. It is omitted on dashed-
line return messages, which only show the return data parameters.
 Parameter-list (with parentheses on initiating messages and without parentheses on
return messages) shows the data that are passed with the message.
 Return-value on the same line as the message (requires :=) is used to describe data
being returned from the destination object to the source object in response to the
message. A return value may also be shown as a separate return message on a
dashed line.

To show a more complex flow of activities, loop frames, opt frames, and alt frames are used.
The frame is a rectangle which encloses the messages that are part of the loop or opt or alt.
The rectangle is labeled as a loop (looping set of messages), opt (optional messages), or alt
(if-then-else messages).

Study Guide Page 35 of 50 Damelin ©

Figure 5.2 shows an example of a System Sequence Diagram

Source: Satzinger et al. (2015)

Developing a System Sequence Diagram (SSD)

To develop an SSD, it is useful to have a detailed description of the use case—either in the
fully developed form or as an activity diagram. One advantage of using activity diagrams is
that it is easy to identify when an input or output occurs. Inputs and outputs occur whenever
an arrow in an activity diagram goes from an external actor to the computer system.

Recall for a workflow diagram there are two swim lanes: the actor and the computer system.
The system boundary coincides with the vertical line between the actor's swim lane and the
computer system's swim lane. The development of an SSD based on an activity diagram
falls into four steps:

1. Identify the input messages, which are the transition arrows that cross the system
boundary.
2. Describe the message from the external actor to the system by using the message
notation described earlier. The message name should describe the service requested from
the system, such as create a customer. Include the parameters that the system will need to
carry out the requested service.
3. Identify and add any special conditions such as iteration and true/false conditions.
4. Identify and add the outputs or return values from each message.

This sequence of steps two through four are done for each message identified in step one.
One of the advantages of creating a SSD is that it helps the analyst understand and verify
not only the processing steps of the use case, but the data values that are required.
Upon completion of this activity, the analyst will have a full description of a use case, with its
workflow in an activity diagram, and good documentation of the inputs and outputs required.
Model building is a powerful tool to help analysts understand user requirements. It also
provides a comprehensive document that can be used in systems design and programming.

Study Guide Page 36 of 50 Damelin ©

The State Machine Diagram – Identifying Object Behavior
Sometimes, it is important for a computer system to maintain information about the status of
problem domain objects. The status condition for a real-world object is often referred to as
the state of the object. A state of an object is a condition that occurs during its life when it
satisfies some criterion, performs some action, or waits for an event. For real-world objects,
we equate the state of an object with its status condition.
A state might have a name of a simple condition, such as On or In repair. Other states are
more active, with names consisting of gerunds or verb phrases, such as Being shipped or
Working. The name of a state shouldn’t be an object (or noun); it should be something that
describes the object (or noun).
States are described as semi-permanent conditions because external events can interrupt a
state and cause the object to go to a new state. An object remains in a state until some
event causes it to move, or transition, to another state. A transition, then, is the movement of
an object from one state to another state. Transitioning is the mechanism that causes an
object to leave a state and change to a new state.
States are semi-permanent because transitions interrupt them and cause them to end.
Generally, transitions are short in duration—compared with states—and they can’t be
interrupted.
A state machine diagram is composed of ovals representing the states of an object and
arrows representing the transitions. After a transition begins, it runs to completion by taking
the object to the new state, called the destination state. A transition begins with an arrow
from an origin state—the state prior to the transition—to a destination state, and it is labeled
with a string to describe the components of the transition.

The transition label consists of the following syntax with three components: transition-name
(parameters, …) [guard-condition] / action-expression any of which may be empty and which
have the following meanings:
 transition-name – the trigger or event that causes the transition to fire
 parameters – any parameters that need to be passed to the object from the
triggering object
 guard-condition – this “guards” the transition, or prohibits it from executing, even if
the trigger fires, unless the guard condition is true
 action-expression – some actions that must be completed as part of the transition.
The action expression may require the input parameters.

Composite States and Concurrency

In the real world, it is very common for an object to be in multiple states at the same time.
The condition of being in more than one state at a time is called concurrency, or concurrent
states. One way to show this is with a synchronization bar and concurrent paths, as in
activity diagrams. Another way to show concurrent states is to have states nested inside
other, higher-level states. These higher-level states are called composite states. A
composite state represents a higher level of abstraction and can contain nested states and
transition paths.

We can extend this idea of composite states and concurrency one step further by allowing
multiple paths within a composite state. Perhaps an object has entire sets of states and
transitions—multiple paths—that are active concurrently. To document concurrent multiple

Study Guide Page 37 of 50 Damelin ©

paths for a single object, we draw a composite state with the lower portion divided into
multiple compartments—one for each concurrent path of behavior.

Rules for Developing State Machine Diagrams

Usually, the primary challenge in building a state machine diagram is to identify the right
states for the object. It is often helpful to have students do object think exercises and pretend
to be the object itself, such as “I am an order,” “how do I come into existence,” and “what are
my status conditions that need to be recorded.”

The other major area of difficulty for new analysts is to identify and handle composite states
with nested threads. Usually, the primary cause of this difficulty is a lack of experience in
thinking about concurrent behavior. The best solution is to remember that developing state
machine diagrams is an iterative behavior—more so than developing any other type of
diagram. Analysts seldom get a state machine diagram right the first time. They always draw
it and then refine it again and again.

Finally, don’t forget to ask about an exception condition—especially when there are the
words verify or check. Usually, there will be two transitions out of states that verify
something: one for acceptance and one for rejection.
Here is a list of steps that will help in developing state machine diagrams:
1. Review the class diagram and select the classes that might require state machine
diagrams.
2. For each selected class in the group, make a list of all the status conditions that can be
identified
3. Begin building state machine diagram fragments by identifying the transitions that cause
an object to leave the identified state
4. Sequence these state-transition combinations in the correct order
5. Review the paths and look for independent, concurrent paths
6. Look for additional transitions
7. Expand each transition with the appropriate message event, guard condition, and action
expression
8. Review and test each state machine diagram
 Make sure states apply to that – the correct – object class
 Trace the entire life cycle of the object to make sure you have all states
 Handle all exception conditions as well as normal paths
 Double check for concurrent paths

Use Cases and CRUD

CRUD technique stands for Create, Read/Report, Update, and Delete. It is used to cross-
check against the existing set of use cases. In database context it ensures that all classes
have a complete “cover” of use cases. CRUD technique cannot be used for primary
identification of use cases.

Steps of the Crud

1. Identify all domain classes
2. For each class verify that use cases exist to
a. Create a new instance

Study Guide Page 38 of 50 Damelin ©

 b. Update existing instances
c. Reads or reports on information in the class
d. Deletes or archives inactive instances
3. Add new use cases as required. Identify responsible stakeholders
4. Identify which application has responsibility for each action: which to create, which to
update and which to use

Integrating Requirements Models

At this point students have learned about how to create several requirements models. One
of the key concepts for students to understand is that all of these models link together to
provide a complete picture of the user's requirements. And, it is extremely important that the
models are consistent with each other. Information across all of these models must be
consistent and provide a unified picture of the requirements.

Figure 5.3 shows the interaction among UML diagrams

Source: Satzinger et al. (2015)

The top two diagrams (i.e. use case diagrams and domain class diagrams) are important
because they provide an overview or comprehensive view of the entire system. One is the
use case diagram, which in its complete form identifies all of the use cases to be
implemented. The other is the class diagram or the domain model, which provides
information about all of the data items required.

Key Terms

 Use case – describes a textual model that lists and describes the processing details
for a use case

 Scenarios or use case instances – unique sets of internal activities within use
cases

 Pre-condition – a condition that must be true before a use case begins

 Post-condition – what must be true upon the successful completion of a use case

 System sequence diagram (SSD) – a diagram showing the sequence of messages

between an external actor and the system during a use case or scenario
 Interaction diagram – either a communication diagram or a sequence diagram that
shows the interactions between objects

Study Guide Page 39 of 50 Damelin ©

  Lifeline or object lifeline – the vertical line under an object on a sequence diagram
to show the passage of time for the object
 Loop frame – notation on a sequence diagram showing repeating messages
 True/false condition – part of a message between objects that is evaluated prior to
transmission to determine whether the message can be sent
 Opt frame – notation on a sequence diagram showing optional messages
 Alt frame – notation on a sequence diagram showing if-then-else logic
 State – a condition during an object’s life when it satisfies some criterion, performs
some action, or waits for an event
 Transition – the movement of an object from one state to another state
 State machine diagram – a diagram showing the life of an object in states and
transitions
 Pseudostate – the starting point of a state machine diagram, indicated by a black
dot
 Destination state – for a particular transition, the state to which an object moves
after the completion of a transition
 Origin state – for a particular transition, the original state of an object from which the
transition occurs
 Action-expression – a description of the activities performed as part of a transition
 Guard-condition – a true/false test to see whether a transition can fire
 Concurrency or concurrent state – the condition of being in more than one state at
a time
 Path – a sequential set of connected states and transitions
 Composite state – a state containing other states and transitions (that is, a path)

Summary of the study unit

 Rules for developing State Machine diagrams
 The State machine diagram – Identifying object behavior
 The System Sequence Diagram – Identifying Inputs and Outputs
 Integrating requirements models

Self-assessment and reflection

1. What is a state? What is the difference between a state, a concurrent state, and a
composite state?
2. List all the rules to be followed when designing a State Machine diagram
3. You have been recently employed at an upcoming IT company as a Junior System
Analyst. The IT Company develops different software for sale, at the moment they
are designing a Student Registration system for Damelin. You have been tasked to
draw a Use Case, SSD and Activity diagram for a Student Registration System

Study Guide Page 40 of 50 Damelin ©

 STUDY UNIT 6: ESSENTIALS OF DESIGN AND THE DESIGN ACTIVITIES

Introduction

There are two major themes in this study unit. The first major theme is about the conceptual
foundation principles of systems design. The second is about configuring and designing the
environment. The first three sections in the chapter introduce the concepts of systems
design. The first section defines design as distinct from analysis. The objective of systems
design is to define, organize, and structure the components of the final solution system that
will serve as the blueprint for construction. There are various components that need to be
designed, including items such as the application software, the database, the user interface,
the network, interfaces to external systems, and internal controls.

The second section compares analysis and design by discussing the different objectives of
analysis versus design. It also discusses the different models used for analysis and design.
Design models consist of such diagrams as package diagrams, design class diagram,
sequence diagrams, communication diagrams, database schema, and user-interface
screens. The final section with the first theme presents the six activities that support Core
Process 4, Design the application. These six activities are:
 design the environment
 design application architecture and software
 design user interfaces, design system interfaces
 design the database
 design system controls and security

The second major theme in this study unit concerns the detail design of the environment. In
other words, the first design activity, design the environment, is covered within this chapter.
Various different configurations of the deployment environment are explained, including
deploying internal systems, external systems, and remote VPN systems.

Learning Objectives
After reading this study unit, the student should be able to:
 Describe the difference between systems analysis and systems design
 Explain each major design activity
 Describe the major hardware and network environment options
 Describe the various hosting services available
 Describe security methods and controls

What is Systems Design?

The main objective of systems analysis is to thoroughly understand the organization’s
informational needs or requirements and to document those requirements in a set of
specifications. Systems design, then, is the bridge that takes us from requirements to
solution and the objective of system design is to define, organize and structure the
components of the final solution to serve as a blue print for construction
The following needs to be taken into consideration:
 Analysis provides the starting point for design
 Design provides the starting point for implementation

Study Guide Page 41 of 50 Damelin ©

  Analysis and design results are documented to coordinate the work

Design models
 Design is a model building activity. It is the formality of the project which will
dictate the type, complexity, and depth of models.
 Agile/iteration projects typically build fewer models, but models are still created
 Jumping to programming without design often causes less than optimum
solutions and may require rework
 The following illustrates analysis to design and implementation models:

Figure 6.1 illustrates analysis to design and implementation

Source: Satzinger et al. (2015)

Design activities
 Design activities correspond to components of the new system
 It is part of core process 4 with the following activities:

Table 6.1 contains all the activities of Core process 4

Study Guide Page 42 of 50 Damelin ©

Source: Satzinger et al. (2015)

Key Design Questions for each Activity

Table 6.2 contains the design activities for core process 4 and the key questions to be asked
when achieving a certain activity

Source: Satzinger et al. (2015)

Design Activities
As design decisions are made, especially at the detail level, they are derived from and
documented by the building of models. Systems design involves specifying in detail how a
system will work when using a particular technology. Each component of the final solution is
heavily influenced by the design of all the other components. Thus, systems design activities
are usually done in parallel. Each of the activities develops a specific portion of the final set
of design documents. Just as a set of building blueprints has several different documents, a
systems design package consists of several sets of documents that specify the entire
system.

1. Describe the environment

Environment consists of external systems and technology architecture. Any external
systems would have been identified and described by system analysis activities.
Those descriptions show how information flows to and from external systems.
Communications with external systems should show precise message formats, web
or network addresses of sources and destinations, communication protocols, security
methods and error detection and recovery. Technology architecture shows existing
architecture and even discovering any architecture which can be used
2. Design the application components
Application component is a well-defined unit of software that performs some
function(s). The following issues involve how to package components:
 Scope and size – what are the functions, boundaries, interfaces?
 Programming language – what are the accepted languages?

Study Guide Page 43 of 50 Damelin ©

  Build or buy – is an acceptable version available to purchase?
3. Design user interface
Analysts should remember that to the user of a system, the user interface is the
system. It is more than just the screens. It is everything the user comes into contact
with while using the system—conceptually, perceptually, and physically. Thus, the
user interface isn’t just an add-on to the system. As information systems become
increasingly interactive and accessible, the user interface is becoming a larger and
more important part of the total system. Designing the user interface can be thought
of as an analysis and a design activity. It has elements of analysis in that the
developers must understand the user’s needs and how the user carries out his or her
job. User-interface design is also a design activity in that it requires creativity and
conformity to rigorous technology requirements.
4. Design the database
By definition, an Information System requires data – usually in a database. Current
technology frequently uses Relational Database Management Systems (RDBMS).
When designing a database there is need to convert the data model to a relational
database and this requires addressing other technical issues such as:
 Throughput and response time
 Security
 Etc.
5. Design the software classes and methods
Analysis models such as class diagrams, SSDs and State Machine Diagrams are
extended to incorporate software specific elements. These models are blueprints for
software methods which will be programmed, tested and deployed. Purpose of this
activity is to describe in detail how the software program works.
System controls and security
 Controls and security methods are embedded within the technology architecture.
When designing a system the following controls should be considered:
o Integrity Controls
 Controls that maintain integrity of inputs, outputs , data and programs
o Security Controls
 Controls that protect the assets from threats, internal and external
 All these controls are summarized in the diagram below:

Figure 6.2 illustrates the environment with various controls and security

Study Guide Page 44 of 50 Damelin ©

Source: Satzinger et al. (2015)

Designing Integrity Controls

This is integrated into application programs and DBMS and the objectives of Integrity
Controls are to:
 Ensure that only appropriate and correct business transactions are accepted
 Ensure that transactions are recorded and processed correctly
 To protect and safeguard assets such as the database

Input controls
Prevent invalid or erroneous data from entering the system and the following controls needs
to be taken into consideration:
 Value Limit Controls that is checking the range of inputs for reasonableness
 Completeness Controls that is, ensuring that all the data has been entered
 Data Validation Controls that is ensuring that specific data values are correct
 Field Combination Controls that is ensuring that data is correct based on
relationships between fields

Output controls
To ensure that output arrives at the proper destination (for authorized eyes) and it should be
accurate, current, and complete. Examples of output controls can be:
 Physical access to printers and display devices
 Discarded data – protect from “dumpster diving”

Study Guide Page 45 of 50 Damelin ©

Also output should be labeled on printed and electronic output to correctly identify source of
data.

Redundancy, Backup and Recovery

Protect data and systems from catastrophes and not only data needs to be protected even
databases, hardware, software applications, and networks. Copies should be kept on-site
and off-site and also recovery strategies should be put in place in case of a disaster.

Fraud Prevention
It is very critical to prevent internal fraud, embezzlement, or loss. There is a fraud triangle
which contains the following:
 Opportunity
 Motive
 Rationalization

Figure 6.3 illustrates the Fraud triangle

Source: Satzinger et al. (2015)

Fraud Risk – Factors and Techniques

Table 6.3 explains factors and techniques affecting fraud risk

Source: Satzinger et al. (2015)

Study Guide Page 46 of 50 Damelin ©

Designing Security Controls
 Thus protecting all assets against external threats
 Other objectives of designing security controls include:
o Protect and maintain a stable, functioning operating environment 24/7
(equipment, operating systems, DBMSs)
o Protect information and transactions during transmission across networks and
Internet
 Access Controls – limit a person’s ability to access servers, files, data, applications
o Authentication – to identify users through the use of Multifactor Authentication
(find out)
o Access control list – list of valid users
o Authorization – authenticated user’s list of permission level for each resource
 Registered Users – those with authorization
 Unauthorized Users – anyone not registered
 Privileged Users – those that maintain lists and systems

Data Encryption
It is a method to secure data which is stored or transmitted. Encryption alters data so that it
is unrecognizable and decryption converts encrypted data back to a readable format. There
is need for an Encryption Algorithm which is a mathematical transformation of the data. And
lastly an encryption Key is needed, which is a long data string that allows the same algorithm
to produce unique encryptions.

Symmetric Key Encryption

 Encryption method that uses the same key to encrypt and decrypt data send from
one point to another as illustrated below:

Figure 6.4 shows the symmetric encryption

Source: Satzinger et al. (2015)

Asymmetric Key Encryption

 Encryption method that uses different keys to encrypt and decrypt that is Public or
Private key as illustrated below:

Figure 6.5 shows the Asymmetric encryption

Study Guide Page 47 of 50 Damelin ©

Source: Satzinger et al. (2015)

Digital Signatures and Certificates

Digital Signature is a technique where a document is encrypted using a private key. And can
only be decrypted with a correct public key. Digital Certificate is an organizations’ name and
public key that is encrypted and certified by an authorized third party. Digital signatures and
digital certificates are widely known and accepted and they are built into Web browsers.

Secure Transactions
 Secure Sockets Layer (SSL) – standard set of protocols for authentication and
authorization
 Transport Layer Security (TLS) – an Internet standard equivalent to SSL
 IP Security (IPSec) – Internet security protocol at a low-level transmission
 Hypertext Transfer Protocol Secure (HTTPS) – Internet standard to transmit Web
pages

Key Terms
 Network diagram – a model that shows how the application is deployed across
networks and computers
 Architectural design – broad design of the overall system structure; also called
general design or conceptual design
 Detail design – low-level design that includes the design of the specific program
details
 Local area network (LAN) – a computer network in which the cabling and hardware
are confined to a single location
 Client-server architecture – a computer network configuration with user’s
computers and central computers that provide common services
 Client computers – the computers at which the users work to perform their
computational tasks

Study Guide Page 48 of 50 Damelin ©

  Server computer – the central computer that provides services (such as database
access) to the client computers over a network
 Hypertext Markup Language (HTML) – the predominant language for constructing
Web pages and which consists of tags and rules about how to display pages
 Transmission Control Protocol/Internet Protocol (TCP/IP) – the foundation
protocol of the Internet; used to provide reliable delivery of messages between
networked computers
 Three-layer architecture – a client/server architecture that divides an application
into view layer, business logic layer, and data layer
 View layer – the part of the three-layer architecture that contains the user interface
 Business logic layer or domain layer – the part of a three-layer architecture that
contains the programs that implement the business rules and processes
 Data layer – the part of a three-layer architecture that interacts with the data
 Hypertext Transfer Protocol Secure (HTTPS) – an encrypted form of information
transfer on the Internet that combines HTTP and TLS
 Transport Layer Security (TLS) – an advanced version of Secure Sockets Layer
(SSL) protocol used to transmit information over the Internet securely
 Content delivery network (CDN) – a set of server computers, separate from the
hosting computers, used to deliver such static content as images or videos
 Hosting – the process of providing physical servers at a secure location and selling
those services to other businesses that wish to deploy Web sites
 Colocation – a hosting service with a secure location but in which the computers are
usually owned by the client businesses
 Virtual server – a method to partition the services of a physical Web server so it
appears as multiple, independent Internet servers
 Cloud computing – an extension of virtual servers in which the resources available
include computing, storage, and Internet access and appear to have unlimited
availability
 Service Level Agreement (SLA) – part of the contract between a business and a
hosting company that guarantees a specific level of system availability
 Virtual Private Networks (VPNs) – a closed network with security and closed
access built on top of a public network, such as the Internet
 Peer-to-peer connection – when independent computers communicate and share
resources without the need of a centralized server computer

Summary of the study unit

 The Elements of Design
 Design Activities
 Design the Environment

Self-assessment and reflection

1. What is the primary purpose of analysis?
2. What is the objective of object-oriented design?

Study Guide Page 49 of 50 Damelin ©

 3. What are eight primary components that need to be designed (usually through the
use of models)?
4. Giving examples, briefly explain the fraud triangle
5. You have been tasked to design a Point Of Sale system for ABC, briefly discuss all
the activities needed when designing a system, in your example clearly state the type
of database which is most suitable, any security measures which needs to be put in
place as well as Electronic Funds Transfer (EFT) if any.

SECTION C

Conclusion
The units in this study guide have been arranged in an order which can help the learner to
follow from the ground upwards. It is recommended that the learner uses this book by
following the order given here. Also, the learner must remember that this book is just a guide
and other sources of reading materials may be needed. The learner is again encouraged to
work the entire example in this guide, answer all the self assessment question to enhance
the quick assimilation of the guide content

Bibliography

 System Analysis and Design in Changing world by John Satzinger, Robert Jackson,
Stephen Burd 7th Edition

 http://www.buzzle.com/images/diagrams/waterfall-model-diagram.jpg

 http://codebetter.com/raymondlewallen/2005/07/13/software-development-life-cycle-
models/

 http://www.ianswer4u.com/2011/12/spiral-model-advantages-
and.html#axzz2CGHcDHwk

 http://www.ianswer4u.com/2011/12/spiral-model-advantages-and.html#ixzz2CGIBooqd

 http://en.wikipedia.org/wiki/Rapid_application_development#Four_phases_of_RAD

 http://istqbexamcertification.com/what-is-rad-model-advantages-disadvantages-and-
when-to- use-it/

 http://searchcio-midmarket.techtarget.com/definition/Prototyping-Model

 http://crackmba.com/wp-content/uploads/2012/02/Prototyping-Model_circle.jpg

 http://en.wikipedia.org/wiki/Prototype

 http://www.scmwise.com/project-management-steps.html

 http://www.gatherspace.com/static/use_case_example.html

Study Guide Page 50 of 50 Damelin ©