Post on 04-Jan-2016
20.04.23Object Oriented Analysis & Design & UML (Unified Modeling
Language) 1
Part II: Requirements
The requirements workflowUse case modelingAdvanced use case modeling
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 2
Requirements Workflow Most of the work is
in Inception and Elaboration phases Discover and reach agreement on
requirements: what you are going to build Express requirements in the language of
the user Solve the conflicting requirements problem Build high-level specifications Prioritize the requirements
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 3
Iterations in SW Development
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 4
Requirements and UML Use Case
is not the only set of requirements specifies Functional Requirements:
“what the system will do” many non-functional requirements in
a system (constraints on the system): Performance Reliability Maintainability Quality …
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 5
Workflow Model Contains –
Workers (icons) and Tasks (cogs)
Arrows indicate flow of work This is not “exact”
it is merely a “normal” workflow We extend the UP workflow
to include non-functional requirements also
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 6
Requirements Workflow
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 7
Extending Requirements Workflow
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 8
Importance of Requirements Discovering what the stakeholders
want the system to do. Failure here will cause project
failure Lack of user involvement
is a major cause of project failure Requirement should drive the rest
of system development
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 9
Requirements: The Crossroad
Requirements study is the crossroad All other project practices
are directed by the requirements
CodingExpectations
Fu
nct
ion
alit
yM
ainten
ance
RequirementsStudy
Desig
n
TestingPro
ject
Man
agm
ent
Qulity
Managem
ent
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 10
Defining Requirements Specification of
“what” should be implemented not “how”
Functional and Non-functional requirements Functional requirements:
What behavior system should offer Non-functional requirements :
A specific property of the system A constraint on the system
It is easier to include some “how”, but it must be mostly “what”
Produce SRS Document the System Requirements Specification
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 11
Well-formed Requirements UML does not have a specific tool Book suggests the format
<id> the <system> shall do <function> Separate Functional from non-functional
requirements Functional
what the system should do Non-functional
constraints on the system
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 12
Requirement Types
Functional Requirements A process the system has to perform Information the system must contain
Nonfunctional Requirements Behavioral properties the system
must have Operational Performance Security Cultural and political
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 13
Functional RequirementsFunctional Requirement
Description Examples
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 14
Nonfunctional Requirements
Nonfunctional Requirement
Description Examples
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 15
ATM SW Requirements Functional requirements
1. The ATM system shall check the validity of the inserted ATM card
2. The ATM system shall validate the PIN number entered by the customer.
3. The ATM system shall dispense no more than $250 against any ATM card in 24-hour period.
Non-functional requirements1. The ATM system shall be written in C++.2. The ATM system shall communicate with the bank using
256-bit encryption.3. The ATM system shall validate and ATM card in three
seconds or less.4. The ATM system shall validate a PIN number in three
seconds or less
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 16
Documenting Requirements
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 17
Use Case UC modeling is
a form of Requirements Engineering Uses
Actors Use Cases Relationships System Boundary
Activities: Find the system boundary Find the actors Find the use cases
Specify the use case Create scenarios
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 18
Use case modeling
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 19
System Boundary Separates the system from its
environment Boundary is defined by
who or what uses the system Represented by a box
labeled with the system name Actors are outside Use Cases are inside
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 20
Actor The role
some external entity adopts when interacting with the system
Represents a role played by a user or another system
Actor is a stereotype of class Use “stick person” to represent actors Actors are always external to the system
System might maintain internal representation of the actors
Example: Customer
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 21
Identifying Actors Who or what uses the system? What role do they play? Who installs the system? What starts and shuts down the system? Who maintains the system? What other system interact with ours? Who provides input? Things that happen at a given time can
be an Actor
Time
To find actors ask:•“Who or what uses or interacts with the system?”
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 22
Use Cases A specification of sequences or actions
Happens by interacting with outside actors Something the actor wants the system to do Always started by an actor Always specified from the user point of view Naming:
Verb with an object e.g. Place Order
Representation: an Oval with name inside
Place Order
GetStatus
OnOrder
To find use cases ask:•“How does each actor use the system?” and•“What does the system do for each actor?”
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 23
Identifying Use Cases Iterative process Start with a name Ask questions
What function will user want form the system?
What triggers system behavior store/retrieve information
Are actors notified by the system? What external events affect the system?
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 24
Example: Mail order system
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 25
Use Case Specification UML has no standard Template is normally used
UC name Identifier Actors Preconditions/post-conditions Flow of events (steps in UC)
<num> the <something> <some action>
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 26
Use case exampleUse case: ManageBasket
ID: UC10
Actors:Customer
Preconditions:1. The shopping basket contents are visible.
Flow of events:1. The use case starts when the Customer selects an item from
the basket.2. If the Customer selects “delete item”
1. The system removes the item from the basket
3. If the Customer types a new quantity1. The system updates the quantity on the item in the basket.
Postconditions:1. The basket contents have been updated.
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 27
Detail a use case
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 28
Branching etc.. Simple branching
can be specified within a UC Complex ones
may require a separate UC Use IF and indented (dot numbered)
actions when necessary use alternative flows
and post-conditions for each usecase
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 29
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 30
Repetition etc.. Use For <iteration expr> statements Use dot-numbered indented set of
statementsn. For (iteration expression)
n.1 Do somethingn.2 Do something elsen.3 …
n+1
Use While <boolean> to represent repetition of a sequence of actions
n. While (Boolean condition)n.1 Do somethingn.2 Do something elsen.3 …
n+1
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 31
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 32
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 33
Requirements Tracing Map (functional) requirements to Use Cases Requirements Traceability Matrix
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 34
Complex Use Cases UC should be simple If there are complex branching, iteration etc.:
use Scenarios Scenario:
One specific path through a UC Each Main Flow will be a scenario Scenarios do not branch Each possible branch is a potential Scenario Each UC has
exactly one “primary scenario” (perfect world path) There are many secondary scenarios
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 35
Scenarios
Primary Scenario Secondary Scenario How many Secondary scenarios?
Pick the most important ones Group similar ones Use risk factor as a guidance
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 36
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 37
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 38
Actor Generalization
Used to simplify diagrams Customer & SalesAgent
Triggers the same use-cases Only difference is the
CalculateCommission Too many crossed lines For the common behavior
There should be another role: Purchaser
The other roles are derived
Lis tP ro ducts
S ales system
O rderP ro ducts
A cceptP aym ent
C alcualteC o m m iss io n
C usto m er
S alesA gent
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 39
Actor Generalization To express the common actor
behavior Actors communicate with the same
set of use cases Sometimes the parent actors
are concrete But good style dictates actors to be
abstract Substitutability principle:
A descendant actor is replaced Anywhere the parent is expected Used to test the correctness
Example: Replace Purchaser by Customer or SalesAgent
ListP ro ducts
S ales system
O rderP ro ducts
A cceptP aym ent
C alcualteC o m m issio n
C usto m er S alesA gent
P urchaser
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 40
Use Case Generalization Used to represent
one or more use cases are the special type of a more general case
Use it only if the diagram is simplified!
The child use case Automatically inherits all features from its
parent The child use case may
Inherit features from their parent use case Add new features Override (change) inherited some of the
features
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 41
Restrictions to Override
The child automatically inherits all features from its parent.But not every type of use case element may be overridden!
Use case element Inherit Add Override
Relationship Y Y N
Precondition Y Y Y
Postcondition Y Y Y
Step in main flow Y Y Y
Alternative flow Y Y Y
Attribute Y Y N
Operation Y Y Y
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 42
Use Case Generalization: Example
The parent use case: FindProduct
Two specializations FindBook FindCD
C usto m er
S ales system
FindP ro duct
F indB o o k FindC D
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 43
Conventions in Documentation Use normal text
For inherited feature of parent
With no change Use italic text
For overridden feature of parent
Use bold text to add features to the child
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 44
Parent Use Case Specification
Use case: FindProduct ID: UC12
Actors: Customer Preconditions:
Flow of events: 1. The Customer selects “find product”. 2. The system asks the Customer for product search criteria. 3. The customer enters the requested criteria. 4. The system searches for products that match the Customer’s criteria. 5. If the system finds some matching products then
5.1. The system displays a list of the matching products. 6. Else
6.1. The system tells the Customer that no matching products could be found.
Postconditions:
Alternative flow: 1. At any point the Customer may move to a different page.
Postconditions:
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 45
Child Use Case SpecificationsChild use case: FindBook
ID: UC16 Parent use case ID: UC12 Actors: Customer Preconditions: Flow of events: 1. The Customer selects “find book”. 2. The system asks the Customer for book search criteria
consisting of author name, title, ISBN, or topic. 3. The customer enters the requested criteria. 4. The system searches for books that match the
Customer’s criteria. 5. If the system finds some matching books then
5.1. The system displays a page showing details of a maximum of five books.
5.2. For each book on the page the system displays the title, author, price, and ISBN.
5.3. While there are more books 5.3.1. The system gives the Customer the option
to display the next page of books. 6. Else
6.1. The system redisplays the “find book” search page.
6.2. The system tells the Customer that no matching products could be found.
Postconditions: Alternative flow: 1. At any point the Customer may move to a different page. Postconditions:
Child use case: FindCD ID: UC17 Parent use case ID: UC12 Actors: Customer Preconditions: Flow of events: 1. The Customer selects “find CD”. 2. The system asks the Customer for CD search criteria
consisting of artist, title, or genre. 3. The customer enters the requested criteria. 4. The system searches for CDs that match the Customer’s
criteria. 5. If the system finds some matching CDs then
5.1. The system displays a page showing details of a maximum of ten CDs.
5.2. For each CD on the page the system displays the title, artist, price, and genre.
5.3. While there are more CDs 5.3.1. The system gives the Customer the option
to display the next page of CDs. 6. Else
6.1. The system redisplays the “find CD” search page. 6.2. The system tells the Customer that no matching
products could be found. Postconditions: Alternative flow: 1. At any point the Customer may move to a different page. Postconditions:
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 46
«include» Used to include
the behavior of one use case called supplier into the flow of another one called client
Is a little bit like a function call Prevents repeating the use cases
The client use case executes until the point of inclusion
Specify exact point of inclusion! then the execution passes to the supplier when the supplier finishes
control returns to the client again
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 47
Example to «include»
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 48
Specification for «include»
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 49
«extend» Adds a new behavior
to an existing use case at a predefined extension point
Base: The use case that is extended Provides extension points
used to add new behaviors Does not know anything about the extensions use case is complete without its extensions
Extension: The use case that modifies the behavior of the base use
case Can access and modifies all base attributes and
operations Provides a set of extension segments to insert
extension points are not numbered in specification «extend» provides a good way
To deal with exceptional cases
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 50
Example to «extend»
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 51
Specification for «extend»
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 52
The Extension Use Case Generally are not complete Might have pre and post conditions Consists of one or more behavior
fragments Known as insertion segments
Rules: The «extend» relationship must
specify the extension points in the base use-case The number of insertion points must
Match the number of insertion segments Two extension use case might
«extend» the same base use case, at the same extension point
the order of execution is indeterminate
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 53
Extension use case example
20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 54
When to use advanced features?
If they simplify the use case model The best use cases are the simple ones The model must be understandable by all
stakeholders Actors and use cases are easily understood Actor generalization is more difficult to grasp Heavy use of «include» makes the complete
picture harder to visualize «extend» is very hardly understood the meaning of «extend» is widely
misunderstood
20.04.23Object Oriented Analysis & Design & UML (Unified Modeling
Language) 55
End of Chapter