Post on 09-Mar-2018
Topic 4: Object-Oriented Approach to Requirements Engineering
Software Engineering Faculty 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
Objective
• To understand how requirements may be organized in a software requirements document
• To adopt a standard in producing a requirements document
Software Engineering 4
The Software Requirements Document
• Software requirements document is an official statement of what is required for the reference of software developers.
• Should include both a definition of user requirements and a specification of the system requirements.
• It is NOT a design document. As far as possible, it should set WHAT the system should do rather than HOW it should do it.
Software Engineering 5
Requirements Document Variability
• Information in requirements document depends on type of system and the approach used in its development.
• Systems developed incrementally will, typically, have less detail in the requirements document.
• Requirements documents standards have been designed e.g. IEEE standard. These are mostly applicable to the requirements for large software projects.
Software Engineering 8
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.
Software Engineering 18
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 developers can use it.
Software Engineering 19
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
Software Engineering 22
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
Software Engineering 26
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
Software Engineering 28
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
Software Engineering 30
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
Software Engineering 31
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
Software Engineering 33
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
Software Engineering 35
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
Software Engineering 37
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
Software Engineering 38
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
Software Engineering 40
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
Software Engineering 42
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
Software Engineering 43
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
Software Engineering 44
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
Software Engineering 46
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
Software Engineering 47
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
Software Engineering 48
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
Software Engineering 51
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
Software Engineering 54
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
Software Engineering 55
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
Software Engineering 57
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
Software Engineering 61
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
Software Engineering 62
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
Software Engineering 64
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
Software Engineering 66
Class Symbol
Class Name
Attribute
Behavior/Method/Operation
Do not include this part in
analysis stage – only in design
stage
Software Engineering 67
Multiplicity of Associations
Recall the knowledge
gained from the database course
and SADM
Software Engineering 70
A University Course Enrollment Domain Model Class Diagram with a Many-to-Many Association
Software Engineering 71
A Refined University Course Enrollment Domain Model Class Diagram with an Association Class
Software Engineering 72
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
Software Engineering 73
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
Software Engineering 74
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
Software Engineering 75
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
Software Engineering 80
DETAILED REQUIREMENTS
Use Case Diagram, Activity Diagram, System Sequence Diagram, State Charts for State Machine Diagram
Software Engineering 82
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
Software Engineering 83
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
Software Engineering 85
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
Software Engineering 86
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
Software Engineering 87
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
Software Engineering 88
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
Software Engineering 90
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.
Software Engineering 93
« 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
Software Engineering 94
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
Software Engineering 97
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
Software Engineering 98
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
Software Engineering 99
Intermediate Description of Telephone Order Scenario for Create New Order Use Case
Software Engineering 101
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)
Software Engineering 102
Use Case Description and Functional Decomposition
Functional decomposition: breaking down a problem into small, isolated parts
• The parts work together to provide the functionality of the system
• Often do not make sense in isolation
• Use cases are NOT functional decomposition
• Keep the functionality together to describe a complete use of the system
2016 Software Engineering 103
Bad Example: Use Case with Functional Decomposition
2016 Software Engineering 104
Avoid FD: -Very small use cases -Too many use cases -Use cases with no result or value -Names with low-level operation i.e. function+data Insert Card
Fully Developed Use Case Description of Telephone Order Scenario for Create New Order
11 compartments
Software Engineering 107
Identifying Inputs and Outputs: System Sequence Diagram
• System sequence diagram (SSD)
– Describes flow of information
– Identifies interaction between actors and system
– Message oriented
Software Engineering 109
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
Software Engineering 110
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)
Software Engineering 112
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
Software Engineering 114
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
Software Engineering 116
SSD of Simplified Telephone Order Scenario for Create New Order Use Case
Parameter
Software Engineering 117
Agent Actor
Activity Input
message
Parameter
Direction
Note: Observe the link between activity diagram with SSD
Software Engineering 119
A Simple Activity Diagram to Demonstrate a Workflow
Agent
Swimlane
Activity
Direction
Decision symbol
Software Engineering 120
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
Software Engineering 122
State Chart or State Machine Diagram
• In OO approaches, state chart is drawn for a single class to show 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 satisfies some conditions, performs some actions, or waits for an event
– It is found by examining the attributes and links defined for the object
– represented as a rectangle with rounded corners • Transition
– represents a change of the internal condition/state of an object
2016 Software Engineering 123
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
Software Engineering 124
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 transition
to be taken. Optional: If missing, it indicates that the transition always occurs if event
occurs. 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
2016 Software Engineering 125
State-A State-B Event (arguments) [condition] / effect
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”
Software Engineering 127
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
Software Engineering 128
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
Software Engineering 131
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
Software Engineering 132
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
Software Engineering 134
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
Software Engineering 138
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
Software Engineering 142
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
Software Engineering 144
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
Software Engineering 145