Topic 6 - Requirements Analysis and Modelling (II)

ISP550
Information Systems
Engineering
Topic 6 : Requirements Analysis &

Modelling (II)
Learning Outcome
 Explain how the concept of “things” in the

problem domain also define requirements
 Identify and analyze data entities and
domain classes needed in the system
 Read, interpret, and create a domain model
class diagram
 Develop system sequence diagrams
2
Things in the Problem Domain
 Problem domain—the specific area (or

domain) of the users’ business need that is
within the scope of the new system.
 “Things” are those items users work with
when accomplishing tasks that need to be
remembered
 Examples of “Things” are products, sales,
shippers, customers, invoices, payments,
etc.
 These “Things” are modeled as domain
classes or data entities
 In this course, we will call them domain
classes. In database class you called them
data entities
Things in the Problem Domain
Two Techniques for Identifying them
 Brainstorming Technique
 Use a checklist of all of the usual types of
things typically found and brainstorm to
identify domain classes of each type
 Noun Technique
 Identifyall of the nouns that come up when the
system is described and determine if each is a
domain class, an attribute, or not something
we need to remember
Brainstorming Technique
 Are there any tangible things? Are there any
organizational units? Sites/locations? Are there
incidents or events that need to be recorded?
Brainstorming Technique:
Steps
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 the following: Are there any
tangible things you store information about? Are
there any locations involved? Are there roles
played by people that you need to remember?
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
The Noun Technique
A technique to identify problem domain
classes (things) by finding, classifying,
and refining a list of nouns that come up
in in discussions or documents
 Does end up with long lists and many
nouns that are not things that need to be
stored by the system
 Difficulty in identifying synonyms and
things that are really attributes
 Good place to start when there are no
users available to help brainstorm
7
Partial List
of Nouns
With notes on
whether to
include as
domain class
The Noun Technique: Steps
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.
(continued)
3. As this list of nouns builds, refine it. Ask these

questions about each noun to help you decide
whether you should include it:
 Is it a unique thing the system needs to know about?
 Is it inside the scope of the system I am working on?
 Does the system need to remember more than one of these
items?
Ask these questions to decide to exclude it:
 Is it really a synonym for some other thing I have identified?
 Is it really just an output of the system produced from other
information I have identified?
 Is it really just an input that results in recording some other
information I have identified?
Ask these questions to research it:
 Is it likely to be a specific piece of information (attribute) about
some other thing I have identified?
 Is it something I might need if assumptions change?
(continued)
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 define the list of
things in the problem domain.
Details about Domain Classes
 Attribute— describes one piece of

information about each instance of the
class
 Customer has first name, last name, phone
number
 Identifier or key
 One attribute uniquely identifies an instance of
the class. Required for data entities, optional
for domain classes. Customer ID identifies a
customer
 Compound attribute
 Two or more attributes combined into one
structure to simplify the model. (E.g., address
rather than including number, street, city,
state, zip separately). Sometimes an identifier
or key is a compound attribute .
Attributes and Values
 Class is a type of thing. Object is a specific instance of the class.
Each instance has its own values for an attribute
Associations Among Things
 Association— a naturally occurring

relationship between classes (UML term)
Just to Clarify…
 Called association on class diagram in UML

 Multiplicity is term for the number of associations between
classes: 1 to 1 or 1 to many
 We are emphasizing UML in this text
 Called relationship on ERD in database class
 Cardinality is term for number of relationships in entity
relationship diagrams: 1 to 1 or 1 to many
 Associations and Relationships apply in two directions
 Read them separately each way
 A customer places an order
 An order is placed by a customer
Minimum and Maximum Multiplicity
 Associations have minimum and maximum constraints

 minimum is zero, the association is optional
 If minimum is at least one, the association is mandatory
The Domain Model Class
Diagram
 Class
 A category of classification used to describe a collection of
objects
 Domain Class
 Classes that describe objects in the problem domain
 Class Diagram
 A UML diagram that shows classes with attributes and
associations (plus methods if it models software classes)

 Domain Model Class Diagram
 A class diagram that only includes classes from the
problem domain, no methods

Domain Class Notation
 Domain class has no methods
 Class name is always capitalized
 Attribute names are not capitalized and use camelback
notation (words run together and second word is
capitalized)
A Simple Domain Model Class
Diagram
 A customer places zero or more orders

 An order is placed by exactly one customer
 An order consists of one or more order items
 An order item is part of exactly one order
UML Notation for Multiplicity
Domain Model Class Diagram
for a bank with many branches
Domain Model Class Diagram
for course enrollment at a university
 Where is each student’s grade remembered in this model?

 Each section has many grades and each grade is association with a student
 Each student has many grades and each grade is association with a section
Refined Course Enrollment Model
with an Association Class CourseEnrollment
 Association class— an association that is treated as a class in a
many to many association because it has attributes that need to
be remembered, such as grade
23
More Complex Issues about
Classes:
Generalization/Specialization Relationships
 Generalization/Specialization
 A hierarchical relationship where subordinate classes are
special types of the superior classes. Often called an
Inheritance Hierarchy
 Superclass
 the superior or more general class in a
generalization/specialization hierarchy
 Subclass
 the subordinate or more specialized class in a
generalization/specialization hierarchy
 Inheritance
 the concept that subclasses classes inherit characteristics of
the more general superclass
Generalization/Specialization
Inheritance
25
Inheritance for Three Types of Sales
 Abstract class— a class that allow subclasses to inherit characteristics

but never gets instantiated.
 Concrete class— a class that can have instances
Inheritance for the Bank with Special Types of Accounts
 A SavingsAccount
has 4 attributes
 A CheckingAccount
Has 5 attributes
 Note: the subclasses
inherit the
associations, too
System Sequence Diagram (SSD)
 An SSD is usually used together with use case
description/activity diagram
 Use case description/activity diagram identify the
flow of activities within a use case
 However, they do not explicitly identify inputs or
outputs
 This is provided by SSD
 Use case diagram shows how actor uses the
system
 System sequence diagram shows how actor
interacts with system
 Enters input data
 Receive output data
28
System Sequence
Diagram (SSD) Shows interactions
between objects
Shows the
sequence of
messages
between an
external actor
and the system
29
SSD Notation
 Actor
 :System
 Lifeline
 Message
 Note
30
SSD Notation
Loop Frame
31
SSD Notation
Loop Alternate
32
SSD Notation
Opt Frame
33
SSD Notation
Alt Frame
34
Creating an SSD
35
Recall Use
Case
Descriptio
n
Create
Custome
r
Account
36
Recall
Activity
Diagram
Create
Customer
Account
37
Steps for Developing SSD
1. Identify input message

2. Describe the message from the
external actor to the system using
the message notation
3. Identify any special conditions on
input messages
4. Identify and add output return values
 On message itself: aValue:=
getValue(valueID)
 As explicit return on separate dashed line
38
Identify Input Message 1
39
Describe the message 2
 Verb-noun: what the
system is asked to
do
 createNewCustomer()
 enterAddress()
 enterCreditCard()
 Consider parameters
the system will need
 Name, phone, emails
 Address
 Credit card information
40
Identify Special Condition 3
 Iteration/loop frame
 Opt or Alt frame
 Example- multiple addresses
41
Identify and Add 4
Output Return Values
 On message itself: aValue:=
getValue(valueID)
 As explicit return on separate

dashed line
42
43
Integrating
requirements model
44
Integrating Requirements
Models
45
Summary
√ Explain how the concept of “things” in the

problem domain also define requirements
√ Identify and analyze data entities and
domain classes needed in the system
√ Read, interpret, and create a domain model
class diagram
√ Develop system sequence diagrams

Topic 6 - Requirements Analysis and Modelling (II)

Uploaded by

Copyright:

Available Formats

Topic 6 - Requirements Analysis and Modelling (II)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Topic 6 - Requirements Analysis and Modelling (II)

Uploaded by

Copyright:

Available Formats

ISP550

Topic 6 : Requirements Analysis &

 Explain how the concept of “things” in the

 Problem domain—the specific area (or

1. Using the use cases, actors, and other

2. Using other information from existing systems,

3. As this list of nouns builds, refine it. Ask these

4. Create a master list of all nouns identified and

5. Review the list with users, stakeholders, and

 Attribute— describes one piece of

 Association— a naturally occurring

 Called association on class diagram in UML

 Associations have minimum and maximum constraints

associations (plus methods if it models software classes)

problem domain, no methods

 A customer places zero or more orders

 Where is each student’s grade remembered in this model?

 Abstract class— a class that allow subclasses to inherit characteristics

1. Identify input message

 Example- multiple addresses

 As explicit return on separate

√ Explain how the concept of “things” in the

You might also like