Introduction to Requirement Modeling

Author and prepared by

Bertrand Meyer

Presented by
Engr. Farooq Iqbal
Welcome!!

Lecture 03
 Learning Outcomes
 You may be able to use the values of the software metrics that are
collected to make inferences about product and process quality.
 Product quality metrics are particularly useful for highlighting
anomalous components that may have quality problems. These
components should then be analyzed in more detail.
 Software analytics is the automated analysis of large volumes of
software product and process data to discover relationships that
may provide insights for project managers and developers.

3
4
Perspectives on Software Engineering:
Quality of Software

5
6
7
Communication Problem

8
9
10
 General Groupings of Things
There are two general groupings of things
 Structural things that define the conceptual and
physical structures of an O-O system and are
described by nouns.
 Behavioral things, the verbs that represent the
behavior of the system and the states of the
system before, during, and after the behaviors
occur.
11
 A Little Bit Review :
Object-Oriented Systems Analysis and Design

 Object-oriented (o-o) techniques work well in

situations where complicated systems are undergoing
continuous maintenance, adaptation, and design.
 The Unified Modeling Language (UML) is an industry
standard for modeling object-oriented systems.

12
13
14
15
16
17
Practical Tool: UML

18
19
Sequence diagram and activity diagram

20
21
ANALYSIS MODEL REVISITED

22
 Basic concept of Analysis Model
A Primarily step in Software construction

 To describe what the customer require by building a model

using requirement elicited from customer
 To establish a basis for the creation of a software design
 To define a set of requirements that can be validated once the
software is built, or validate software requirements using
multiple dimensions thereby increasing probability of finding
error

23
 Model

• What is a model?
– a model is a simplification of reality

• Why do we model?
– we build models so that we can better understand the system we are developing
– we build models of complex systems because we cannot understand such a syst
em in whole
– four aims to achieve
• help us to visualize a system
• permit us to specify the structure/behavior of a system
• give us a template that guides us in constructing systems
• document the decisions we have made

24
 Analysis Model - UML

Class diagram Function

Object diagram
Use case diagram
Activity diagram

Data Object

Behavior
State-chart diagram
Interaction diagram

25
 Relationship

 Connectedness (join together)

 A fact that must be remembered by the system and cannot or is not
computed or derived
 Several instance of a relationship can exist
 Object/Entity can be related in many ways

own

26
 Cardinality and Multiplicity

own

Automobile Person
own
Make
Birthday
Model
Height
Body type
Weight
Price
Expertise
Color

27
 Association: Multiplicity

• Unspecified
• Exactly one 1
• Zero or more (many, unlimited
• One or more 0..*
• Zero or one 1..*
• Specified range
• Multiple, disjoint ranges 0..1

2..4
2, 4..6

28
 Object models

Object = entity + operations

Object models describe the system in terms of object classes

An object class is an abstraction over a set of objects with common

attributes and the services (operations) provided by each object

Various object models may be produced

Inheritance models
Aggregation models
Interaction models

29
 Association and Aggregation

Association
• Is a Relationship between objects.
• Objects have independent lifecycles.
• There is no owner.
• Objects can create and delete independently.

Aggregation
• Specialize form of Association.
• has-a relationship between objects
• Object have independent life-cycles
• Parent-Child relationship

30
31
 Functional Modeling: Data Flow Diagram

Every computer-based system is an

information transform ....

computer
input based output
system

32
 Data Flow Diagramming

• all icons must be labeled with meaningful names

• the DFD evolves through a number of levels of detail
• always begin with a context level diagram (also called level
0)
• always show external entities at level 0
• always label data flow arrows
• do not represent procedural logic

33
Level 0

34
35
Basic Concept

36
 Review Questions

• What is the relationship of UML with SC?

• Can we use this Requirement Modeling for AI?
• Why we use Association and Aggregation is Software Construction?
Thank you