Chapter 4

System Modeling

Abdisalam Issa-Salwe

Department of Computer Science

Faculty of Information Science and Technology
East Africa University

Shari Lawrence Pfleeger and Joanne M. Atlee (2009): ,Software Engineering: Theory and Practice, 4 th E.. Pearson

Contents
 The Requirements Process
 Requirements Elicitation
 Types of Requirements
 Characteristic of Requirements
 Modeling Notations
 Requirements and Specification Languages
 Prototyping Requirements
 Requirements Documentation
 Validation and Verification
 Measuring Requirements
 Choosing a Specification Technique
 Information System Example
 Real Time Example

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

1
Objectives

 Eliciting requirements from the customers

 Modeling requirements
 Reviewing requirements to ensure their
quality
 Documenting requirements for use by the
design and test teams

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.1 The Requirements Process

 A requirement is an expression of desired behavior

 A requirement deals with
 objects or entities
 the state they can be in
 functions that are performed to change states or
object characteristics
 Requirements focus on the customer needs, not on the
solution or implementation
 designate what behavior, without saying how that
behavior will be realized

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

2
4.1 The Requirements Process
Sidebar 4.1 Why Are Requirements Important?
 Top factors that caused project to fail
 Incomplete requirements
 Lack of user involvement
 Unrealistic expectations
 Lack of executive support
 Changing requirements and specifications
 Lack of planning
 System no longer needed
 Some part of the requirements process is involved in
almost all of these causes
 Requirements error can be expensive if not detected early

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.1 The Requirements Process

Process for Capturing Requirements

 Performed by the req. analyst or system analyst

 The final outcome is a Software Requirements
Specification (SRS) document

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

3
4.2 Requirements Elicitation

 Customers do not always understand what

their needs and problems are
 It is important to discuss the requirements
with everyone who has a stake in the
system
 Come up with agreement on what the
requirements are
 If we can not agree on what the requirements
are, then the project is doomed to fail

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.2 Requirements Elicitation

Stakeholders
 Clients: pay for the software to be developed
 Customers: buy the software after it is developed
 Users: use the system
 Domain experts: familiar with the problem that the
software must automate
 Market Researchers: conduct surveys to determine
future trends and potential customers
 Lawyers or auditors: familiar with government, safety,
or legal requirements
 Software engineers or other technology experts

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4
4.2 Requirements Elicitation
Means of Eliciting Requirements

 Interviewing stake holders

 Reviewing available documentations
 Observing the current system (if one exists)
 Apprenticing with users to learn about user's task in
more details
 Interviewing user or stakeholders in groups
 Using domain specific strategies, such as Joint
Application Design, or PIECES
 Brainstorming with current and potential users

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.2 Requirements Elicitation

Means of Eliciting Requirements (continued)

 The Volere requirements process model suggests some

additional sources for requirements

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

5
4.3 Types of Requirements

 Functional requirement: describes required

behavior in terms of required activities
 Quality requirement or nonfunctional
requirement: describes some quality
characteristic that the software must posses
 Design constraint: a design decision such as
choice of platform or interface components
 Process constraint: a restriction on the
techniques or resources that can be used to build
the system

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.3 Types of Requirements

Sidebar 4.4 Making Requirements Testable
 Fit criteria form objective standards for judging
whether a proposed solution satisfies the
requirements
 It is easy to set fit criteria for quantifiable requirements
 It is hard for subjective quality requirements
 Three ways to help make requirements testable
 Specify a quantitive description for each adverb and adjective
 Replace pronouns with specific names of entities
 Make sure that every noun is defined in exactly one place in
the requirements documents

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

6
4.3 Types of Requirements
Resolving Conflicts

 Different stakeholder has different set of

requirements
 potential conflicting ideas
 Need to prioritize requirements
 Prioritization might separate requirements
into three categories
 essential: absolutely must be met
 desirable: highly desirable but not necessary
 optional: possible but could be eliminated

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.3 Types of Requirements

Two Kinds of Requirements Documents

 Requirements definition: a complete

listing of everything the customer wants to
achieve
 Describing the entities in the environment
where the system will be installed
 Requirements specification: restates the
requirements as a specification of how the
proposed system shall behave

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

7
4.4 Characteristics of Requirements

 Correct
 Consistent
 Unambiguous
 Complete
 Feasible
 Relevant
 Testable
 Traceable

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.5 Modeling Notations

Entity-Relationship Diagrams
 A popular graphical notational paradigm for
representing conceptual models
 Has three core constructs
 An entity: depicted as a rectangle, represents a
collection of real-world objects that have common
properties and behaviors
 A relationship: depicted as an edge between two
entities, with diamond in the middle of the edge
specifying the type of relationship
 An attribute: an annotation on an entity that
describes data or properties associated with the
entity
Department of Computer Science, Faculty of Information Science and Technology, East Africa University

8
4.5 Modeling Notations
Entity-Relationship Diagrams (continued)

 Entity diagram of turnstile problem

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.5 Modeling Notations

ER Diagrams Example: UML Class Diagram

 UML (Unified Modeling Language) is a collection

of notations used to document software
specifications and designs
 It represents a system in terms of
 objects: akin to entities, organized in classes that
have an inheritance hierarchy
 methods: actions on the object's variables
 The class diagram is the flagship model in any
UML specification
 A sophisticated ER diagram relating the classes
(entities) in the specification
Department of Computer Science, Faculty of Information Science and Technology, East Africa University

9
4.5 Modeling Notations
 

UML Class Diagram of Library Problem

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.5 Modeling Notations

UML Class Diagram (continued)

 Attributes and operations are associated with the

class rather than instances of the class
 A class-scope attribute represented as an
underlined attribute, is a data value that is shared by
all instances of the class
 A class-scope operation written as underlined
operation, is an operation performed by the abstract
class rather than by class instances
 An association, marked as a line between two
classes, indicates a relationship between classes'
entities

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

10
4.5 Modeling Notations
UML Class Diagram (continued)

 Aggregate association is an association that

represents interaction, or events that involve
objects in the associated (marked with white
diamond)
 “has-a” relationship
 Composition association is a special type of
aggregation, in which instances of the compound
class are physically constructed from instances of
component classes (marked with black diamond)

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.5 Modeling Notations

Event Traces

 A graphical description of a sequence of events that

are exchanged between real-world entities
 Vertical line: the timeline of distinct entity, whose
name appear at the top of the line
 Horizontal line: an event or interaction between the
two entities bounding the line
 Time progresses from top to bottom
 Each graph depicts a single trace, representing one of
several possible behaviors
 Traces have a semantic that is relatively precise,
simple and easy to understand
Department of Computer Science, Faculty of Information Science and Technology, East Africa University

11
 4.5 Modeling Notations
Event Traces Example: Message Sequence Chart
 An enhanced event-trace notation, with
facilities for creating and destroying entities,
specifying actions and timers, and
composing traces
 Verticalline represents a participating entity
 A message is depicted as an arrow from the
sending entity to the receiving entity
 Actions are specified as labelled rectangles
positioned on an entity's execution line
 Conditions are important states in an entity's
evolution, represented as labelled hexagon
Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.5 Modeling Notations

State Machines

 A graphical description of all dialog between the

system and its environment
 Node (state) represents a stable set of conditions
that exists between event occurrences
 Edge (transition) represents a change in
behavior or condition due to the occurrence of an
event
 Useful both for specifying dynamic behavior and for
describing how behavior should change in response
to the history of events that have already occurred

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

12
4.5 Modeling Notations
State Machines (continued)

 A path: starting from the machine's initial

state and following transitions from state
to state
A trace of observable events in the
environment
 Deterministic state machine: for every
state and event there is a unique response

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.5 Modeling Notations

State Machines Example: UML Statechart Diagrams

 A UML statechart diagram depicts the dynamic

behavior of the objects in a UML class
 UML class diagram has no information about
how the entities behave, how the behaviors
change
 A UML model is a collection of concurrently
executing statecharts
 UML statechart diagram have a rich syntax,
including state hierarchy, concurrency, and
intermachine communication

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

13
4.5 Modeling Notations
UML Statechart Diagrams (continued)

 State hierarchy is used to unclutter

diagrams by collecting into super state
those states with common transitions
 A super state can actually comprise
multiple concurrent submachines,
separated by dashed line
 The submachines are said to operate
concurrently

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.5 Modeling Notations

Data-Flow Diagrams
 ER diagram, event trace, state machines depict only
lower-level behaviors
 A data-flow diagram (DFD) models functionality and
the flow of data from one function to another
 A bubble represents a process
 An arrow represents data flow
 A data store: a formal repository or database of
information
 Rectangles represent actors: entities that provide
input data or receive the output result

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

14
4.5 Modeling Notations
Data-Flow Diagrams (continued)

 Advantage:
 Provides an intuitive model of a proposed
system's high-level functionality and of the
data dependencies among various processes
 Disadvantage:
 Can be aggravatingly ambiguous to a
software developer who is less familiar with
the problem being modeled

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.5 Modeling Notations

Data-Flow Diagrams Example: Use Cases
 Components
 A large box: system boundary
 Stick figures outside the box: actors, both human
and systems
 Each oval inside the box: a use case that represents
some major required functionality and its variant
 A line between an actor and use case: the actor
participates in the use case
 Use cases do not model all the tasks, instead they are
used to specify user views of essential system
behavior

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

15
4.5 Modeling Notations
Functions and Relations

 Formal methods or approach: mathematically

based specification and design techniques
 Formal methods model requirements or software
behavior as a collection of mathematical functions
or relations
 Functions specify the state of the system's
execution, and output
 A relation is used whenever an input value maps
more than one output value
 Functional method is consistent and complete

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.5 Modeling Notations

Decision Tables (continued)

 Decision table for library functions

borrow, return, reserve, and
unreserve

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

16
4.5 Modeling Notations
Logic

 An operational notation is a notation used to

describe a problem or a proposed software solution
in terms of situational behavior
 Model of case-based behavior
 Examples: state machine, event traces, data-flow
diagram, functional method
 A descriptive notation is a notation that describes
a problem or a proposed solution in terms of its
properties or its variant
 Example: logic

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.5 Modeling Notations

Logic (continued)

 A logic consists of a language for expressing

properties and a set of inference rules for
deriving new, consequent properties from the
stated properties
 In logic, a property specification represents only
those values of the property's variables for
which the property's expression evaluates to
true
 It is first-order logic, comprising typed variables,
constants, functions, and predicates

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

17
4.5 Modeling Notations
Logic Example: Object Constrain Language (OCL)
 A constrain language that is both mathematically
precise and easy for non-mathematicians to read,
write, and understand
 Designed for expressing constrains on object
models, and expressing queries on object type

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.6 Requirements and Specification Languages

Unified Modeling Language (UML)
 Combines multiple notation paradigms
 Eight graphical modeling notations, and the OCL
constrain language, including
 Use-case diagram (a high-level DFD)
 Class diagram (an ER diagram)
 Sequence diagram (an event trace)
 Collaboration diagram (an event trace)
 Statechart diagram (a state-machine model)
 OCL properties (logic)

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

18
4.6 Requirements and Specification Languages
Specification and Description Language (SDL)

 Standardized by the International Telecommunication

Union
 Specifies the behavior of real-time, concurrent, distributed
processes that communicate with each other via
unbounded message queues
 Comprises
 SDL system diagram (a DFD)
 SDL block diagram (a DFD)
 SDL process diagram (a state-machine model)
 SDL data type (algebraic specification)
 Often accompanied by a set of Message Sequence Chart
(MSC)

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.7 Prototyping Requirements

Building a Prototype

 To elicit the details of proposed system

 To solicit feedback from potential users about
 what aspects they would like to see improve
 which features are not so useful
 what functionality is missing
 Determine whether the customer's problem has
a feasible solution
 Assist in exploring options for optimizing quality
requirements

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

19
4.7 Prototyping Requirements
Prototyping Example

 Prototype for building a tool to track how much a user

exercises each day
 Graphical representation of first prototype, in which the user
must type the day, month and year

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.7 Prototyping Requirements

Prototyping Example (continued)
 Second prototype shows a more interesting and
sophisticated interface involving a calendar
 User uses a mouse to select the month and year
 The system displays the chart for that month, and the
user selects the appropriate date in the chart

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

20
4.7 Prototyping Requirements
Prototyping Example (continued)
 Third prototype shows that instead of calendar, the user
is presented with three slide bars
 User uses the mouse to slide each bar left or right
 The box at the bottom of the screen changes to show
the selected day, month, and year

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.7 Prototyping Requirements

Approaches to Prototyping

 Throwaway approach
 Developed to learn more about a problem or a proposed
solution, and that is never intended to be part of the
delivered software
 Allow us to write “quick-and-dirty”
 Evolutionary approach
 Developed not only to help us answer questions but also
to be incorporated into the final product
 Prototype has to eventually exhibit the quality
requirements of the final product, and these qualities
cannot be retrofitted
 Both techniques are sometimes called rapid
prototyping

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

21
 4.7 Prototyping Requirements
Prototyping vs. Modeling

 Prototyping
 Good for answering questions about the user
interfaces
 Modeling
 Quickly answer questions about constraints
on the order in which events should occur, or
about the synchronization of activities

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.8 Requirements Documentation

Requirement Definition: Steps Documenting Process
 Outline the general purpose and scope of the system,
including relevant benefits, objectives, and goals
 Describe the background and the rationale behind
proposal for new system
 Describe the essential characteristics of an acceptable
solution
 Describe the environment in which the system will
operate
 Outline a description of the proposal, if the customer
has a proposal for solving the problem
 List any assumptions we make about how the
environment behaves
Department of Computer Science, Faculty of Information Science and Technology, East Africa University

22
 4.8 Requirements Documentation
Requirements Specification: Steps Documenting Process
 Describe all inputs and outputs in detail, including
 the sources of inputs
 the destinations of outputs,
 the value ranges
 data format of inputs and output data
 data protocols
 window formats and organizations
 timing constraint
 Restate the required functionality in terms of the
interfaces' inputs and outputs
 Devise fit criteria for each of the customer's quality
requirements
Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.8 Requirements Documentation

Sidebar 4.6 Level of Specification
 Survey shows that one of the problems with requirement
specifications was the uneven level of specification
 Different writing styles
 Difference in experience
 Different formats
 Over specifying requirements
 Underspecifying requirements
 Recommendations to reduce unevenness
 Write each clause so that it contains only one
requirement
 Avoid having one requirement refer to another
requirement
 Collect similar requirements together

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

23
4.8 Requirements Documentation
Sidebar 4.7 Hidden Assumptions

 Two types of environmental behavior of interest

 desired behavior to be realized by the
proposed system
 existing behavior that is unchanged by the
proposed system
 often called assumptions or domain
knowledge
 Most requirements writers consider assumptions
to be simply the conditions under which the
system is guaranteed to operate correctly

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.8 Requirements Documentation

Process Management and Requirements Traceability
 Process management is a set of procedures that track
 the requirements that define what the system
should do
 the design modules that are generated from the
requirement
 the program code that implements the design
 the tests that verify the functionality of the system
 the documents that describe the system
 It provides the threads that tie the system parts
together

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

24
 4.9 Validation and Verification

 In requirements validation, we check that our

requirements definition accurately reflects the
customer's needs
 In verification, we check that one document or
artifact conforms to another
 Verification ensures that we build the system
right, whereas validation ensures that we build
the right system

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.9 Validation and Verification

Sidebar 4.9 Computer-Aided Verification

 Model checking is an exhaustive search for a

specification's execution space, to determine whether
some temporal-logic property holds of the execution
 Atlee (1996) used the SMV model checker to verify five
properties of an SCR specification of the A-7 naval
aircraft
 A theorem prover uses a collection of built-in theories,
inference rules, and decision procedures for determining
whether a set of asserted facts logically entails some un-
asserted fact

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

25
4.10 Measuring Requirements
 Measurements focus on three areas
 product
 process
 resources
 Number of requirements can give us a sense of the size
of the developed system
 Number of changes to requirements
 Many changes indicate some instability or uncertainty
in our understanding of the system
 Requirement-size and change measurements should be
recorded by requirements type

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.11 Choosing a Specification Technique

Criteria for Evaluating Specification Methods

 Applicability  Veriability
 Implementability  Run time safety
 Testability/Simulation  Tools maturity
 Checkability  Looseness
 Maintainability  Learning curve
 Modularity  Technique maturity
 Level of abstraction  Data modeling
 Soundness  Discipline

26
4.11 Choosing a Specification Technique
Steps

 Determine which of the criteria are especially

important
 Evaluate each of the candidate techniques with
respect to the criteria
 Choose a specification technique that best
supports the criteria that are most important to
the problem

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

4.12 What This Chapter Means for You

 It is essential that the requirements definition and specification

documents describe the problem, leaving solution selection to
designer
 There are variety of sources and means for eliciting requirements
 There are many different types of definition and specification
techniques
 The specification techniques also differ in terms of their tool support,
maturity, understandability, ease of use, and mathematical formality
 Requirements questions can be answered using models or
prototypes
 Requirements must be validated to ensure that they accurately
reflect the customer's expectations

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

27
Group discussion

Group 1: Discuss Requirements

Process and the Characteristic of
Requirements
Group 2: Discuss requirements
and Specification Languages
Group 3: Discuss Prototyping
Requirements

Department of Computer Science, Faculty of Information Science and Technology, East Africa University

28