ADVANCED SYSTEM DESIGN AND IMPLEMENTATION

1
Modeling System Requirements

Modeling System Requirements

The module aims to introduce and enlighten the students to different kinds
of modeling process to deeply understand the system requirements.
Specifically to the students are expected to:
 Use-case modeling and it’s benefits;
 Identify the business actors and requirements;
 Identify the relationships between actors in a use-case;
 Discuss the other types of modeling processes and tools;

Topic Coverage

 Use Case Modelling

 Process Modeling
 Conceptual Modeling
 Object Modeling
 Data Modeling

Use Case Modeling

Most of the time deployed systems does not satisfy users, some development are halted
just before completion or systems are not used at all. For system stakeholders it is really hard to
come up with the perfect system that will answer all the system users’ requirements. That is why
systems development team and the analyst must have the ability to communicate with users and
translate the requirements so that stakeholders will have a clear understanding to confirm the
requirement.
In order to achieve the best results in systems development planning, analyzing, designing,
building and deploying the analyst must first consider the needs of the stakeholders - the process
is called user-centered development and use-case modelingis the approach that will aid the
usage-centered development.
Use-case modeling goes together well with traditional systems and design tools like data
and process modeling. It also provides big help on architectural and interface design decisions as
well as other activities like system testing and project management.But it doesn’t specify the user
interface design. The kind of process use-case modeling is using are based on events of the
organization, who initiated the events and the system response for each event. Use-case modeling
is proven to give a lot of benefits, it is also considered as the best practice to identify, document
and fully comprehend the functional requirements of an information system.

Course Module
 Originally, use-case modeling was introduced by Dr. Ivar Jacobson in 1986 and got more
popular through his book, Object-Oriented Software Engineering that was published in 1992. Use-
case modeling is proven to be a precious help in creating object-oriented information systems,
below are the following benefits:
 Serves as a tool for obtaining functional requirements.
 Assists in decomposing system scope into more manageable pieces.
 Provides communication between users and stakeholders with regards to system
functionalities.
 Provides means in system development monitoring.
 Provides an aid in project estimates such as scope, effort, and schedule.
 Supplies baseline for testing, for test plans and test cases
 Source for user help systems and system development documentation.
 Serves as requirements traceability tool.
 Serves as the starting point for data object indentification.
 Defines database access requirements for add, edit, delete and read.
 Supplies system development framework.

There are two objects that must be considered first when performing use-case modeling.
First is the Use-case diagramis a diagram used to graphically represent the system as a gathering
of use cases, users (actors) and relationships. The diagram shows how the system will process
business events but it starts with a process called functional decomposition that breaks the
system apart into subcomponents. A sample diagram is shown in Figure 2. It shows how each
business events interacts with the system actors or users who involves in different processes. The
second object is the Use-case Narrativeis an entity that is using textual illustration of business
events and how users will interact with the system to complete a single or multiple tasks. It also
indentifies system events and its interaction with the users.

Use-cases
Use-cases are tools used by use-case modeling to portray system tasks perform by
external users also known as actors in the approach they understand. Most information system
events are triggered by date or time and these events are called temporal events in which time is
considered as the actor that triggers an event automatically when it reaches a certain date or time.
Actors initiate activities or use case for the purpose of completing business tasks that produces
valuable outputs. There are 4 types of actors:
1. Primary Business Actor – the system users that benefits from the system with
measurable values but may or may not trigger an event. (Ex. Employee receiving a
salary (measurable value) from the payroll system, the employee does not trigger an
event but still directly receives an output)
2. Primary System Actor - the system users that directly uses the system to initiate an
event. (Ex. Payroll Processors, who inputs the attendance of employees)
3. External Server Actor– the system users that only reacts to a request from the use case.
(Ex. Government agencies authorizing employees contributions or deductions such as
taxes)
4. External Receiver Actor – the system users that are not primary actors but receives
measurable outputs from the use case. (Ex. Office messengers that distributes pay-slips
generated from a payroll system.
 ADVANCED SYSTEM DESIGN AND IMPLEMENTATION
3
Modeling System Requirements

Actor represents any system interaction. Figure 1 serves as the

symbol of an actor(user).

Figure1. Actor Symbol

System

Use Case 1 Use Case 1 Use Case 1

Actor 1 Actor 2 Actor 3

Figure 2. Sample Actor’s Interaction

Relationships
Relationships are connections between the symbols in a use-case diagram. It may vary how
lines are connected with the other symbols. Below are the types of relationships that can be found
in use case diagrams.
Relationships on Use Case Diagram
 Associations
The relationship which describes the interaction between the actor and use-
cases. Associations are represented by solid line connecting the actor and the us
case. Please refer to Figure 3.

Course Module
 Figure 3. Sample Association Relationship. (Source: Systems Analysis and Design Methods, 7 th Ed., Whitten,
Bently, 2007)

 Extends
Extension use case minimizes a complex use case to clearly understand
each step by making it simpleto extend functionality of the original use case. The
relationship between the extension use case and use case is called
extensionsthat are represented by an arrowhead line and labeled with
“<<extends>>”. Figure 4, is a sample of a extension use case showing lines with
extension labels.

Figure 4. Sample Extension Relationship. (Source: Systems Analysis and Design Methods, 7th Ed., Whitten,
Bently, 2007)

 Uses (or Includes)

There are many use cases that have the same steps of same functionality. To
 ADVANCED SYSTEM DESIGN AND IMPLEMENTATION
5
Modeling System Requirements

extract the identical steps, a separate use case called abstract use casemust be
established. You will notice that this relationship is labeled as “<<uses>>” as
shown in Figure 5.

Figure 5. Sample Uses Relationship. (Source: Systems Analysis and Design Methods, 7 th Ed., Whitten,
Bently, 2007)

 Depends On
A relationship between use cases that points out that one use case will not
execute unless another use case is executed.Anyone who will manage the project
or anyone who will serve as the developer must clearly understand which use
case depends on other use case to classify the development progression. Usually
depends on relationship indicates the need to plan and schedule. This line is
labeled with “<<depends on>>”. Check Figure 6 below to visualize a dependent
relationship.

Course Module
 Figure 6. Sample Depends-On Relationship. (Source: Systems Analysis and Design Methods, 7th Ed.,
Whitten, Bently, 2007)

 Inheritance
An inheritance relationship is when 2 or more actors have a common use
case or common activities. The sample in Figure 7 shows actors labeled as abstract
actors showing an inheritance relationship, inherited by patron and visitor actors.
 ADVANCED SYSTEM DESIGN AND IMPLEMENTATION
7
Modeling System Requirements

Figure 7. Sample Inheritance Relationship. (Source: Systems Analysis and Design Methods, 7 th Ed.,
Whitten, Bently, 2007)

Requirements Use-Case Modeling Process

When preparing the models every analyst must not fall into state of over-analyzing
(analysis by paralysis). Systems analyst must act fast, but not all the requirements can be
extracted during the analysis phase. Based on Systems Analysis and Design Methods, 7th ed. (2007)
by Whitten, J., Bentley, L., &Dittman, K., below are the steps on how to produce a model:

1. Identify business Actors

Identifying the actors will help you to filter the details of the use-case model.
You can create a list of actors and their participation in the process. When
looking for an actor you must identify some points like, who will process inputs
in the system and who will maintain the system.
When looking for potential actors you must look of different sources. You
must identify the whole scope of the system. Also all documentation and user
manuals must take into consideration even minutes of the meetings of the
project. To look for actors, you must first know who process inputs into the
system and who benefits (output) from the system, as well as the time triggered
process and who will maintain the system must take into consideration.
Actors should be identified with a term with textual description, stating the
actor’s role in the whole process. Refer to the sample actor glossary below.

Actors Glossary

TERM
DESCRIPTION

Cashier
Receives payment and process
invoicing.
An individual that purchased goods.
Customer
Merchandiser An employee or group of employees
responsible in maintaining product
shelves stocks.
Responsible for the inventory of
Stock Room
products, holds reports for shelves
stocks.

2. Identify business requirements use cases.

Course Module
 Business requirements use case represents relations of the business system
and its actors. The best way to identify the business use case is to check how
each actor interacts with the system and how they use the system. To clearly
identify the use case you must classify the tasks of the actors and what are the
outputs needed by the actors and what kind of inputs does the actors provide to
the system.

3. Construct use-case model diagram.

When actors and use cases are identified, you can use a use case diagram to
describe the capacity of the system. Remember that a single system may contain
more than one use cases, to clearly define the sub systems; you must create use
cases for every part of the subsystem. Please refer to Figure 3 as a sample taken
from Systems Analysis and Design Methods, 7th ed. (2007) by Whitten, J., Bentley,
L., &Dittman, K.
 ADVANCED SYSTEM DESIGN AND IMPLEMENTATION
9
Modeling System Requirements

Figure 3. Sample Use Case Diagram

Course Module
 4. Document business requirements use cases.

To document the business requirements, the high level use case must be
considered first to understand the impact of the whole system before focusing
on each use cases and expanding it to completely documented business
requirement narrative. A business requirement narrative describe the events
that contains the individuals who writes the narratives including the date, title,
and use case actors, stakeholders and description of the use case in which
purpose and activities are explained.

Conceptual modeling
There are many types of modeling methods in systems analysis, but unfortunately there are
only best practices and there is no standards. Methods may depend on the analyst point of view or
upon the situation or set up of the organization.
Another type of system representation; it is composed of a concept that symbolizes an
events and processes within the system. Concepts are used to simulate models inside the system,
which are represented by physical objects. The name of conceptual models was formed after
conceptualization phase. There is also a type of conceptual model called CAM or conceptual agent
model, this type of methodology uses agents as a feedback system.
Conceptual modeling plays the big role in communications between different parties with
different objectives involved in the system development process.

Object Oriented Analysis

Object Oriented Analysis is a procedure in systems development to identify software design
and engineering requirements through objects. An object in OOA represents actual business
interactions that incorporate data and functions. The tasks of OOA mainly identify and organize
objects by creating diagrams which represents the behavior and interaction of each objects. An
object oriented analysis approach is associated with an iterative development methodology.
Many analysts are also using a general purpose language called Unified Modeling
Language (UML). It is used to envision the design of the system. Many are considering that UML
as a key factor in object-oriented software development because it allows system developers to
clearly view the system as a whole. The objective of UML is to produce a common dictionary of
object based terms and diagram techniques that will help in system development from analysis to
design.
According to the creators of UML Version 2.0, every object oriented approach to develop an
information system must be:
 Use Case Driven
As discussed, use casedescribes how an actor interacts with the system. A use case
also focuses on one activity at a time and an effective tool to communicate any
requirements to the system developers.

 Architecture Centric
 ADVANCED SYSTEM DESIGN AND IMPLEMENTATION
11
Modeling System Requirements

The fundamental architecture of the developing system drives specification,

construction, and documentation of the system. There are 3 architectural views of
the system which are: (1) Functional View, in which describes the external behavior
of the system from user’s point of view. (2) Static View, describes the system
structure based on attributes, methods, classes, relationships, and messages. (3)
Dynamic View describes the internal behavior of the system and combines the
process and data modeling, because method execution can change through receiving
objects.

 Iterative and Incremental

Iterative and Incremental development is accentuated in object oriented
approaches, that a system, go through continuous testing for the entire project to
achieve the final needs of the users.

Activities and Exercises

 Case Study:Please refer to this reference which is free for

download: Shelly, Cashman, Rosenblatt. (2012). Systems Analysis and
Design. 9th Edition.Boston
 Chapter 5: Data and Processing Model - New Century Clinic
pp. 239 – 240
 Chapter 6: Data and Processing Model Personal Trainer pp.
240

 Capstone Case:Please refer to this reference which is free for

download: Shelly, Cashman, Rosenblatt. (2012). Systems Analysis and
Design. 9th Edition.Boston
 Chapter 6:Software Limited Inc. pp. 275 – 283

 Assignment 1: Article Review No. 3: System Dynamics Modeling

for Public Health: Background and Opportunities. (Please see the
attached PDF

 Course Project:
 Project Proposal Approval
 Project Assignment: Project Modelling – System Requirements
and Specifications

Course Module
References
 Textbook: Roth, Denis, Wixom. (2012). Systems Analysis and Design. 5th
Edidtion. Wiley

 Texbook: Shelly, Cashman, Rosenblatt. (2012). Systems Analysis and Design.

9th Edition.Boston

 Use Case Fundamentals Alistair Cockburn.:

http://cis.bentley.edu/lwaguespack/CS360_Site/Downloads_files/Use%20C
ase%20Template%20%28Cockburn%29.pdf

 Online Journal: System Dynamics Modeling for Public Health: Background

and Opportunities. Jack B. Homer and Gary B. Hirsch, American Journal of
Public Health: March 2006, Vol. 96, No. 3, pp. 452-458. doi:
10.2105/AJPH.2005.062059. Retrieved from:
http://ajph.aphapublications.org/ doi/pdf/10.2105/AJPH.2005.062059