Topic 4: Object-Oriented Approach to Requirements ... · to Requirements Engineering Software Engineering ... •Information in requirements document depends on type of system and

Topic 4: Object-Oriented Approach to Requirements Engineering

Software EngineeringFaculty of Computing

Universiti Teknologi Malaysia

Topic Outline

• Part I: Requirements Document

– Software Requirements Specification (SRS)

• Part II: Requirements Modeling Concept

– Use Case Modeling and Specification

– System Sequence Diagram (SSD)

– Activity Diagram

– Domain Modeling

– Statechart Diagram

Software Engineering 2

PART I

Requirements Document – Software Requirements Specification (SRS)


Objective

• To understand how requirements may be organized in a software requirements document

• To adopt a standard in producing a requirements document


The Software Requirements Document

• Software requirements document is an officialstatement of what is required for thereference of software developers.

• Should include both a definition of userrequirements and a specification of thesystem requirements.

• It is NOT a design document. As far aspossible, it should set WHAT the systemshould do rather than HOW it should do it.


User and System RequirementsRecall


Users of a Requirements Document


Requirements Document Variability

• Information in requirements document dependson type of system and the approach used in itsdevelopment.

• Systems developed incrementally will, typically,have less detail in the requirements document.

• Requirements documents standards have beendesigned e.g. IEEE standard. These are mostlyapplicable to the requirements for large softwareprojects.


IEEE Std 830-1998


SRS Outline of IEEE Std 830-1998

See page 11 of IEEE Std 830-1998


Example of Template for the Front Part of SRS Document


Section 1: Introduction


Section 2: Overall Description,Sub-Section 2.1


Sub-sections 2.1.1 to 2.1.3


Sub-sections 2.2 & 2.3


Sub-sections 2.4 to 2.6


Section 3: Specific Requirements


A.5 Template of SRS Section 3: Organized by Feature

• Section 3.1.1 to Section 3.1.4 provide the details of what described in 2.1.2 to 2.1.5. Consider to organize Section 3.2 by the modules i.e. map each feature with each module and map respective use case in the module with its functional requirement. For each functional requirement, indicate its details using use case description. Include sequence diagram (of system level also known as system sequence diagram) and activity diagram for each use case i.e. functional requirement.


Key Points

• The software requirements document is an agreed statement of the system requirements.

• It should be organized so that both system customers or users and software developerscan use it.


PART II

Requirements Modeling Concept

Reference: Satzinger et al. (2011)


Requirements Models: Traditional Approach vs. Object-Oriented Approach


Overview of Models Used in Requirements and Design

• Logical models specify processes

• Physical models are based on logical models

– Implement some component of the system

– Included within the design discipline

• UML diagrams are used in system development

• Additional models also used


UML Diagrams used for Modeling


Additional Models used for Requirements and Design Disciplines


ROCKY MOUNTAIN OUTFITTERS (RMO)

Case Study 1


Rocky Mountain Outfitters and Its Strategic Information Systems Plan

• RMO serves role of case study for text

• Business: manufacture and distribute sports clothing

• Project: develop new customer support system

• Initial activities– Understand the nature of the business

– Investigate current information system

– Define basic objectives of customer support system

– Develop the information systems strategic plan


Early RMO Catalog Cover (Spring 1978)


Introducing Rocky Mountain Outfitters (RMO)

• RMO founded by John and Liz Blankens in 1978

• Staff consists of 600 people

• Annual sales have risen to nearly $100 million

– Mail-order operation contributes $60 million

– In-store retail sales account for $7.5 million

– Phone-order operation accounts for $30 million


Current RMO Catalog (Spring 2006)


RMO Strategic Issues

• Founders commit to business expansion in 2002

• Growth channel: business-to-consumer (B2C) e-commerce

• Two key strategic thrusts support five year plan:

– Supply chain management (SCM)

– Customer relationship management (CRM)

• Object-oriented technology and techniques shape system development projects


RMO’s Organizational Structure and Locations

• John and Liz Blankens are chief executives

• 113 workers employed in Park City, Utah

• Two retail store locations: Park City and Denver

• Manufacturing facilities in Salt Lake City and Portland, Oregon


Rocky Mountain Outfitters’ Organizational Structure


RMO’s Organizational Structure and Locations (continued)

• Three distribution/warehouse facilities: Salt Lake City, Albuquerque, and Portland

• Mail-order processing in Provo, Utah

• Phone-sales center in Salt Lake City


Rocky Mountain Outfitter’s Locations


The RMO Information Systems Department

• 50 employees in information systems department

• Mac Preston: chief information officer (CIO)

• Information system organization

– System support: telecommunications, database administration, operations, and user support

– System development team: four project managers, six systems analysts, ten programmer analysts, and support staff


RMO Information Systems Department Staffing


Existing RMO Systems

• Data center in Park City supports (8) systems:– Merchandising/Distribution

– Mail Order

– Phone Order

– Retail Store Systems

– Office Systems

– Human Resources

– Accounting/Finance

– RMO Informational Web site


The Information Systems Strategic Plan

• SCM and CRM provide vision for the plan

• Two chief components

– Technology Architecture Plan: emphasize distributed computing

– Application Architecture Plan: seamlessly integrate replacements, upgrades and new packages

• Timetable reflects implementation schedule


The Timetable for RMO’s Application Architecture Plan


The Customer Support System

• Development project: customer support system (CSS)

• RMO core competency: cultivating customer loyalty

• Application architecture plan specifies CSS objectives

– Includes functions associated with providing products

– Supports customer relationship management strategy

– Offers multiple sales channels: telephone, mail, retail, and Internet

• System details worked out in requirements analysis


USE CASE AND DOMAIN MODEL


Objectives

• To define requirements using use cases and problem domain classes

• To identify and analyze events and resulting use cases, for use case diagram

• To identify and analyze domain classes for domain model class diagram

• To produce detail requirements using system sequence diagram, activity diagram and statechart diagram


Ways of Writing a System Requirements Specification

Notation Description

Natural language The requirements are written using numbered sentences in natural

language. Each sentence should express one requirement.

Structured natural

language

The requirements are written in natural language on a standard form or

template. Each field provides information about an aspect of the

requirement.

Design description

language

This approach uses a language like a programming language, but with

more abstract features to specify the requirements by defining an

operational model of the system. This approach is now rarely used

although it can be useful for interface specifications.

Graphical notations Graphical models, supplemented by text annotations, are used to define

the functional requirements for the system; UML use case and

sequence diagrams are commonly used.

Mathematical specifications These notations are based on mathematical concepts such as finite-

state machines or sets. Although these unambiguous specifications can

reduce the ambiguity in a requirements document, most customers don’t

understand a formal specification. They cannot check that it represents

what they want and are reluctant to accept it as a system contract.

Recall


Events and Use Cases

• Use case

– Activity the system carries out

– Entry point into the modeling process

• Event decomposition: help identify use cases

• Elementary business processes (EBPs)

– Basic unit of analysis

– Initiated by event occurring at specific time and place

– Discrete system response that adds business value


Identify Use Cases: User vs. Goal


Types of Events

• External Events

– Occur outside the system

– Usually caused by external agent

• Temporal Events

– Occurs when system reaches a point (deadline) in time

• State Events

– Asynchronous events responding to system trigger


Identifying Events

• Distinguish events from prior conditions

– Can the transaction complete without interruption?

– Is the system waiting for next transaction?

• Trace sequence of events initiated by external agent such as those in activity diagram

– Isolate events that actually touch the system


Events in the Rocky Mountain Outfitters Case

• Developing list of external events

– Identify all people and organizational units that want something from the system

• Developing list of temporal events

– Identify regular reports and statements that system must produce at certain times


External Events for the RMO Customer Support System


Temporal Events for the RMO Customer Support System


Looking at Each Event and the Resulting Use Case

• Enter use cases in an event table

• Event table includes rows and columns

– Each row is a record linking an event to a use case

– Columns represent key information

• RMO event table anatomizes customer support system


Information about each Event and the Resulting Use Case in an Event Table


The Complete Event Table for the RMO Customer Support System


Problem Domain Classes

• Problem domain

– Set of work-related “things” in system component

• Things have data representation within system

– Examples: products, orders, invoices, customers

• OO approach to things in problem domain

– Objects that interact in the system

• Identify and understand things in problem domain

– Key initial steps in defining requirements


Types of Things

• Things can be identified with methodology

• Separate the tangible from the intangible

• Include information from all types of users

• Ask important questions about nature of event

– “What actions upon things should be acknowledged and recorded by the system?”

• Example case: customer placing an order


Type of Things: Example


Procedure for Developing an Initial List of Things

• List nouns that users mention when discussing system

• Event table as source of potential things

– Use cases, external agents, triggers, response

• Select nouns with questions concerning relevance

– Further research may be needed


Partial List of “Things” Based on Nouns for RMO






Associations among Things

• Analyst document entity associations (relationships)– Example: “is placed by” and “works in”

• Associations apply in two directions– Customer places an order (better to use active voice)– An order is placed by a customer (passive voice – not

encouraged to be used

• Multiplicity: the number of associations – One to one or one to many

• The associations between types of things– Unary (recursive), binary, n-ary


Attributes of Things

• Specific details of things are called attributes

• Analyst should identify attributes of things

• Identifier (key): attribute uniquely identifying thing

– Examples: Social Security number, vehicle ID number, or product ID number

• Compound attribute is a set of related attributes

– Example: multiple names for the same customer


Attributes and Values


Classes and Objects

• Domain model class diagram as UML class

– OOA applies domain model class diagram to things

• Problem domain objects have attributes

• Software objects encapsulate attributes and behaviors

– Behavior: action that the object processes itself

• Software objects communicate with messages

• Information system is a set of interacting objects


Objects Encapsulate Attributes and Methods


Domain Model Class Diagram Notation

• Class diagram key– General class symbol: rectangle with three

sections– Sections convey name, attributes, and

behaviors – Methods (behaviors) not shown in domain

model class diagram– Lines connecting rectangles show associations– Multiplicity reflected above connecting lines

• Domain class objects reflect business concern, policies, and constraints


Class Symbol

Class Name

Attribute

Behavior/Method/Operation

Do not include this part in

analysis stage –only in design

stage


Class Symbol with Name and Attributes: Example


A Simple Domain Model Class Diagram


Multiplicity of Associations

Recall the knowledge

gained from the database course

and SADM


A University Course Enrollment Domain Model Class Diagram with a Many-to-Many Association


A Refined University Course Enrollment Domain Model Class Diagram with an Association Class


Hierarchies in Class Diagram Notation

• Generalization/specialization notation

– Inheritance hierarchy

– Rank things the more general to the more special

• Motor vehicle class includes trucks, cars, buses

• Classification: means of defining classes of things

– Superclass: generalization of a class

– Subclass: specialization of a class


Hierarchies in Class Diagram Notation (continued)

• Whole-part Hierarchy Notation– “The whole is equal to the sum of the parts”

• Two types of whole-part hierarchies– Aggregation: association with independent parts

(collection of)• Example: keyboard is part of computer system

– Composition: association with dependent part (composed of)• Example: CRT and monitor

• Multiplicity applies to whole-part relationships


Hierarchies in Class Diagram Notation (continued)

• Design Class Diagrams (in design phase)– Models classes into precise software analogs

– Includes domain class information plus methods

– Triangle symbol between classes indicates inheritance

– Properties of attributes are shown with curly braces

• Class fundamentals– Instances of a class (objects) manage their own data

– Abstract classes are not instantiated (created)

– Subclasses inherit attributes/behaviors from superclass


A Generalization/Specialization Hierarchy for Motor Vehicles


A Generalization/Specialization Hierarchy for Orders


Whole-Part (Aggregation) Relationships Between a Computer and Its Parts


Domain Model Class Diagram vs Design Class Diagram

Include method


RMO Domain Class Diagram

• Derives from noun list

• RMO domain class diagram shows attribute

• Models do not show methods

• Problem domain classes reflect high-level view of RMO use cases


Rocky Mountain Outfitters Domain Model Class Diagram


DETAILED REQUIREMENTS

Use Case Diagram, Activity Diagram, System Sequence Diagram, State Charts for State Machine Diagram


Detailed Object-Oriented (OO) Requirements Definitions

• System requirements captured with OO models

• “Divide and conquer” strategy toward complexity

• Two subsets of OO modeling approach

– Use case driven extending four specific models

• Use case diagrams, use case descriptions, activity diagrams, system sequence diagrams

– Object driven extending statechart diagram


Requirements Diagrams With UML Models


Detailed OO Requirements Definitions(continued)

• Use case diagram: table of contents for business events

• System sequence diagrams (SSDs)– Define and order sequence of inputs and outputs – Information flows referred to as messages

• Class diagrams – Identify real-world “things” – Determine the structure of the programming classes

• Statechart diagram describes collection of object states


System Processes: A Use Case/ Scenario View

• Define use cases into two tiers:

– Overview level derived from:

• Event table and use case diagrams

– Detailed level derived from combination of:

• Use case description

• Activity diagram

• Sequence diagram


Use Cases and Actors

• Source– Person or thing initiating the business event who

may/may not touch the system– Must be external to the system

• Actor– Person or thing that touches the system – Lies outside of automation boundary

• Identifying actors at the right level of detail– Assume actors (even non-human types) have

hands– Use case is a goal that the actor wants to achieve


The Use Case Diagram

• Notation for use case diagrams

– Simple stick figure represents an actor

– Actor’s hands indicate direct system access

– Use case itself symbolized by an oval

– Connecting lines match actors to use cases

• Actors may also be other system interfaces

– May be represented with stick figure or rectangle


A Simple Use Case with an Actor


Automation Boundary and Organization

• Expand use case diagrams with other actors and use cases

• Relationship line: allows each actor to interact with each use case

• Automation boundary

– Line drawn around the entire set of use cases

– Defines interface between actors and computer system


Use Case Diagram of Order-Entry Subsystem for RMO with a System Boundary


All Uses Cases Involving the Customer Actor


A Use Case Diagram of the Customer Support System (by Subsystem)

Note: If possible DO NOT duplicate the same actors e.g. clerk, customer, management (see arrows)

For a large system, the modularity is organized by sub-systems. However, for a medium to small size system, consider creating modules.


« Includes » Relationships

• «includes» or «uses» relationship– Use case calling services of common subroutine

– Common subroutine itself becomes additional use case

• Examples: “Validate customer account” and “Look Up Item Availability”

• Notation – Relationship denoted by connecting line with arrow

– Direction of the arrow indicates major/minor cases


An Example of Order-Entry Subsystem with <<includes>> Use Cases


The <<extend>> Relationships

2016 Software Engineering 96

<<extend>> relationships model exceptional or seldom invoked cases

The exceptional event flows are factored out of the main event flow for clarity

The direction of an <<extend>> relationship is to the extended use case

Use cases representing exceptional flows can extend more than one use case

Developing a Use Case Diagram

• Two ways to identify additional use cases

– Divide one large use case into two

– Define another use case based on a common subroutine

• Distinguish between temporal and state events

• Iterative process translates business events to use cases

– Identify the actors and roles for each use case

– Extract system response to business events

• Data of system stabilizes after completion of the goal


Use Case Detailed Descriptions

• Use cases have internal complexity

– Sequence of steps to execute business process

– Several variations may exist within single use case

• Valid variation known as scenario

– Example: “Create new order” varies from phone to Internet order

• Work with variety of diagrams and descriptions for each use case


Use Case Detailed Descriptions (continued)

• Use case descriptions written at (3) levels of detail

– Brief description

• Summary statement conjoined to activity diagram

– Intermediate description

• Expands brief description with internal flow of activities

– Fully Developed Description

• Expands intermediate description for richer view


Brief Description of Create New Order Use Case


Intermediate Description of Telephone Order Scenario for Create New Order Use Case


Use Case Detailed Descriptions (continued)

• Fully developed use case description

– Superset of intermediate and brief descriptions

– Consists of eleven compartments

– User, actor, stakeholder, EBP, and conditions identified

• Activity Diagram Description

– Document the workflows of business processes

– Document flow of activities for use case scenarios

– Form basis of system sequence diagrams (SSDs)


Use Case Description and Functional Decomposition

Functional decomposition: breaking down aproblem into small, isolated parts

• The parts work together to provide thefunctionality of the system

• Often do not make sense in isolation

• Use cases are NOT functional decomposition

• Keep the functionality together to describe acomplete use of the system


Bad Example: Use Case with Functional Decomposition


Avoid FD:-Very small use cases-Too many use cases-Use cases with no result or value-Names with low-level operationi.e. function+data Insert Card

Good Example: UCD Without Functional Decomposition


Note: 1 Use Case must have at least 1 scenario or normal flow.Software Engineering 106

Fully Developed Use Case Description of Telephone Order Scenario for Create New Order

11 compartments


Activity Diagram of Telephone Order vs. Web Order Scenario


Identifying Inputs and Outputs: System Sequence Diagram

• System sequence diagram (SSD)

– Describes flow of information

– Identifies interaction between actors and system

– Message oriented


SSD Notation

• Actor “interacts” with the system via input/output

• SSDs use object notation– Box (rectangle) refers to individual object

– Name of the object underlined

– Messages sent/received by objects, not classes

• Lifeline– Extension of object or actor for duration of the SSD

– Indicates sequence of the messages sent/received


Sample System Sequence Diagram (SSD)


SSD Notation (continued)

• Message syntax can take several forms

– Depends on send/return direction

• Message semantics: actions (like commands) invoked on destination object

• Complete message notation:*[true/false condition] return-value := message-name (parameter-list)


Repeating message (a)Detailed notation, (b) Alternate notation


Developing a System Sequence Diagram

• Begin with detailed description of use case– Fully developed form

– Activity diagrams

• 4-step process for turning activity diagram into SSD – Identify the input messages

– Describe messages from external actor to system

– Identify/apply special conditions to input messages

– Identify and add the output return messages


A Simplified Activity Diagram of Telephone Order Scenario


Developing a System Sequence Diagram (continued)

• Names of messages reflect services performed

• Important principle for identifying data parameters– Base the list on the class diagram

– Attributes from the classes listed as parameters

• Iteratively define input/output parameters around workflows

• Objective: discovery and understanding


SSD of Simplified Telephone Order Scenario for Create New Order Use Case

Parameter


SSD of Web Order Scenario for Create New Order Use Case


Agent Actor

ActivityInput

message

Parameter

Direction

Note: Observe the link between activity diagram with SSD


A Simple Activity Diagram to Demonstrate a Workflow

Agent

Swimlane

Activity

Direction

Decision symbol


An Activity Diagram Showing Concurrent Paths

Syncronizationbar


Rocky Mountain Outfitters Domain Model Class Diagram

Note: Parameters in SDD correspond to attributes in relevant classes

1

2

3

1

2

3

3 3

3


State Chart or State Machine Diagram

• In OO approaches, state chart is drawn for a single class toshow the lifetime behavior of a single object.

• State chart is also known as state machine diagram.• State:

– a condition during the life of an object when it satisfiessome conditions, performs some actions, or waits for anevent

– It is found by examining the attributes and links defined forthe object

– represented as a rectangle with rounded corners• Transition

– represents a change of the internal condition/state of anobject


Identifying the Object Behavior: State Chart Diagram

• In brief, a state in a state chart similar to status condition– Spans many business events

– Developed for complex problem domain classes

• State chart/state machine diagram – Composed of ovals representing status of object

– Arrows represent transitions


Transition Notation

i. Event: Single event that triggers a potential change of state i.e. from State-A to

State-B.ii. Guard condition:

Guard is a Boolean condition (true/false). It must be true for the transitionto be taken.

Optional: If missing, it indicates that the transition always occurs if eventoccurs.

iii. Effect: Behaviors that is executed during the transition. May include operation calls, the creation or destruction of another objects,

or the sending of a signal to an object. Optional: if missing, it indicates nothing is done during the transaction


State-A State-BEvent (arguments) [condition] / effect

Simple State Machine Diagram for a Printer


Identifying the Object Behavior: State chart (continued)

• Guidelines to help identify states– Check naming convention for status conditions

– Simple states reflect simple conditions such as “On”

– Complex states labeled with gerunds or verb phrases • Example: “Being shipped”

– Active states usually not labeled with nouns

– Describe only states of being of the object itself

– Status conditions reported to management/customers • Example: “Shipped”


Nested States And Concurrency

• Concurrency: condition of being in more than one state at a time

• Two modes of representation

– Use synchronization bars and concurrent paths

– Nest low-level states inside higher-level states

• Higher-level states also called composite states

– Complex structure of sets of states and transitions

– Represent a higher level of abstraction


Sample Composite States for Printer Object


Concurrent Paths for a Printer in Onstate


Rules for Developing State Charts

1. Select the classes that will require statecharts

2. List all the status conditions for each group

3. Specify transitions that cause object to leave the identified state

4. Sequence state-transition combinations in correct order

5. Identify concurrent paths (if any)

6. Look for additional transitions

7. Expand each transition as appropriate

8. Review and test each statechart


Developing RMO State Charts

• Review the domain class diagram

• Select classes with status conditions that need to be tracked

• Candidates: Order, OrderItem, InventoryItem, Shipment, Customer

• Choose Order and OrderItem

– Simplicity

– Location in the class hierarchy



Developing The Order Item State Chart

• Identify possible status conditions of interest

– “Ready to be shipped”

– “On back order”

– “Shipped”

• Continue developing statechart according to eight rules


States and Exit Transitions for OrderItem


Partial State Machine Diagram for OrderItem


Final State Machine Diagram for OrderItem


Developing the Order State Chart

• States mirror the life cycle of an order

• Application of rules leads to greater complexity– Concurrent states

– New transitions

• Benefits of developing a statechart for an object– Captures and clarifies business rules

– Gain true understanding of system requirements


States and Exit Transitions for Order


First-Cut State Machine Diagram for Order


Second-Cut State Machine Diagram for Order


Integrating Object-Oriented Models

• Primary (or source) models– Use case diagram – Problem domain class diagram

• CRUD analysis validates model completeness• Construction of one model depends on

another • Models capturing processes of new system

– Use case diagram and models to lower left

• Models capturing information about classes– Class diagrams and dependencies


Relationships among OO Requirements Models


Summary

• OOA family of models documents users’ needs and defines system requirements

• Use case detailed models (descriptive or activity)

• Sequence diagrams (SSDs)

• Domain model class diagrams

• Statechart diagrams


Summary (continued)

• Use case: single system function responding to an event

• Actors: human users or system interfaces that initiate system response

• System function decomposed into workflows

• SSDs, domain models, statecharts emulate routines and object interaction

• Software engineering terms signal transition into design phase


Documents

Topic 4: Object-Oriented Approach to Requirements ... · to Requirements Engineering Software Engineering ... •Information in requirements document depends on type of system and