Chapter 5: Modeling System Requirements

1
Chapter 5 Modeling System Requirements
2
Learning Objectives

• Understanding why identifying use cases is the
  key to defining functional requirements
• Use three techniques for identifying use cases
• Write brief, intermediate, and fully developed
  use case description
• Identify and analyze data entities and domain
  classes needed in the system
• Read, interpret, and create an entity-relationship
  diagram

3
Overview

• Models are created as part of activity of
  defining system requirements.
• Two concepts help identify functional
  requirements in the traditional approach and
  object-oriented approach
• Use cases
• Things in the users work domain

4
Analysis Phase Activities

• Gather information
• Define system requirements
• Prioritize requirements
• Prototype for feasibility and discovery
• Generate and evaluate alternatives
• Review recommendation with management

5
Use Case

• Use case is an activity that system performs in
  response to a request by a user.
• Examples
• Search available flight
• Make reservation
• Check flight status
• A use cases name is its goal
• The name must be active, concise, and decisive

6
Techniques for Identifying Use Cases

• Identify user goals
• Users goal in using the information system.
• CRUD analysis technique (create, read, update,
  delete)
• Event decomposition technique
• Focus on elementary business processes (EBPs)

7
Identifying Use Cases Based on User Goals
8
Use Case Based on CRUD Technique
9
Event Decomposition

• What events occur that will require the system to
  respond?
• Business events trigger elementary business
  processes (EBPs)
• EBPs are at correct level of analysis for use
  cases
• Identify business events to decompose system into
  activities/use cases

10
Events Affecting a Charge Account Processing
System that Lead to Use Cases
11
Types of Events

• External
• Outside system
• Initiated by external agent or actor
• Temporal
• Occur as result of reaching a point in time
• Based on system deadlines
• State
• Something inside system triggers processing need

12
External Event Checklist
13
Temporal Event Checklist
14
Identifying Events

• Can be difficult to determine
• Often confused with conditions and responses
• May be useful to trace a transactions life cycle
• Certain events left to design phase
• System controls to protect system integrity
• Perfect technology assumption defers events

15
Sequence of Actions that Lead Up to Only One
Event Affecting the System
16
Sequence of Transactions for One Specific
Customer Resulting in Many Events
17
Events Deferred Until the Design Phase
18
Quick Quizzes

• What is an event?
• What are the three types of events?

19
Events in the RMO case

• Important external events involve customers
• Customer checks item availability, customer
  places order, customer changes or cancels order
• Other external events involve departments
• Shipping fulfills order, marketing sends
  promotion to customer, merchandising updates
  catalog
• Temporal events include periodic reports
• Time to produce order summary reports, Time to
  produce fulfillment summary reports

20
Information about Each Event in an Event Table
21
RMO Event Table
22
Use Case Description

• Use case description provides details of
  preconditions, postconditions, sequence of
  activities, and exception conditions in use case
• Describes actor interacting with computer system
  step-by-step to carry out business activity
• May have several scenarios for a use case, each a
  specific use case instance

23
Use Case Description Level of Detail

• Brief Description
• Intermediate Description
• Fully Developed Description

24
Brief Description of Create New Order Use Case
25
Intermediate Description of the Telephone Order
Scenario for Create New Order Use Case
26
Fully Developed Description of Telephone Order
Scenario for Create New Order Use Case
27
Use Case Description Components

• Use case name/scenario name
• Actors/stakeholders
• Related use cases
• Preconditions set of criteria that must be true
  prior to initiation of the use case
• Postconditions set of criteria that must be
  true upon completion of the use case
• Flow of activities (steps in one column or two)
• Exception conditions

28
Top Detail from Fully Developed Use Case
Description
29
Middle Detail from Fully Developed Use Case
Description
30
Bottom Detail from Fully Developed Use Case
Description
31
Quick Quizzes

• What does an actor represent in a use case?
• What is the difference between a fully developed
  description and an intermediate description?
• What are preconditions? What are postconditions?

32
Things in the Problem Domain

• Define system requirements by understanding
  system information that needs to be stored
• Store information about things in the problem
  domain that people deal with when they do their
  work
• Analysts identify these types of things by
  considering each use case in the event table
• What things does the system need to know about
  and store information about?

33
Types of Things
34
Procedure for Developing an Initial List of
Things

• Step 1 Using the event table and information
  about each use case, identify all nouns
• Step 2 Using other information from existing
  systems, current procedures, and current reports
  or forms, add items or categories of information
  needed
• Step 3 Refine list and record assumptions or
  issues to explore

35
RMO Example Things
36
Relationships Among Things

• Naturally occurring association among specific
  things
• Occur in two directions
• Number of associations is cardinality or
  multiplicity
• Binary, unary, ternary, n-ary

37
Attributes of Things

• Attribute refers to one specific piece of
  information about a thing.
• Identifier (or Key) is an attribute that uniquely
  identifies a thing.
• Compound attribute is an attribute that contains
  a collection of related attributes.

38
Relationships Naturally Occur Between Things
39
Cardinality/Multiplicity of Relationships
40
Attributes and Values
41
Data Entities

• Data entities are things system needs to store
  data about in traditional IS approach
• Modeled with entity-relationship diagram (ERD)
• Requirements model used to create the database
  design model for relational database

42
The Entity-Relationship Diagram (ERD)
43
Cardinality Symbols of Relationships for ERD
44
Expanded ERD with Attributes Shown
45
Customers, Orders, and Order Items
46
ERD with Many-to-Many Relationship
47
Many-to-Many Relationship Converted to
Associative Entity to Store Grade Attribute
48
RMO Customer Support System ERD
49
Where You Are Headed (Figure 5-39)