Requirement
[A&N 3-5]
3
“Requirement”
• Obviously, we need to somehow capture what are the
requirements of the software to build.
• A&N categorize them to:
– Functional requirement, textual e.g. It is for playing Reversi; it
supports both single and multi-player modes.
– Non functional requirement, e.g. It should be platform independent.
– Use-cases  UML’s workout of textual func. req
2
How to find requirements ?
• Stake holders
• Elicitation:
–
–
–
–
Survey , interview stakeholders
Shadowing
Workshop
Discuss with the help of models or even prototypes
• Things to watch:
– you have to ask the right questions
– deletion, distortion, and generalization in stakeholders’ natural
language
• Prioritize requirements
– much is wasted on implementing unimportant features...
3
Examples
• SH: “Students can view grades”
(deletion  just their own grades)
• SH: “A grade above 6.0 is a pass”
(distortion  actually >= 6.0)
• SH: “Every course is 7.5 ects”
(generalization  colloquiums are however 5 ects)
4
Survey
•
•
•
•
•
•
What is your role wrt the current system ?
How do you use the system ?
Your key goals in using the system ?
Your issues in using the system ?
Your concerns towards the new system ?
Select characteristics that best for your need:
– how fast the system should response : medium/quick/very
quick
– how configurable should your work interface be:
none/medium/high
– how “powerful” should your work interface be: just
enough/high
– how extensive is the help system: low/medium/high
5
“Requirement” as a core WF within UP
Typical deliverables:
• updated project plan,
• use case models 80%
• static and dynamic models
• executable architectural baseline
Typical deliverables:
• project plan,
• use case models 20%
Inception
Elaboration
Construction
Transition
• requirement
• analysis
• design
• implementation
• test
Iteration:
1
time
2
3
4
5
...
6
Requirement Work Flow (in UP)
system
analyst
find actors and uses cases
prioritize use cases
architect
use case
specifier
detail use cases
UI designer
prototype user interface
We won’t discuss this
some activities would be in the Inception phase, some could
be in the elaboration phase.
Not showing the activities to produce functional/non-functional reqs .. See A&N.
7
Use case
• A use case specifies a functionality (of a system S) that an
external entity (“actor”) can trigger on S, or a functionality
that S itself triggers to be exercised on some actors.
• Actor can be human or another system.
• Imply that you need to decide a boundary for S, to determine
if something is an actor (which must be outside S).
• Good for identifying top level functional requirements.
• Use-case is described in texts (could be quite structured);
don’t confuse it with use-case diagram.
8
Use case diagram, and its elements
actor
customer
subject name
With respect to a use-case,
actors can be primary or
secondary.
Online shop system
Buy Item
use case
delivery
company
A use case may have primary and
secondary actors..
Add Item
use case
shop
owner
credit card
company
subject boundary
9
Model and its “specification” (backplane)
Item
name
price
applyDiscount(d)
order()
Buy Item
Backplane
class Item
Desc: Represents an item to sell.
applyDiscount(d), apply the discount d (in %) to the current price.
order(), produces an order containing this item.
Backplane
usecase Buy Item
Desc: …
…
• Diagrams/models are nice, but on their own they will be too
vague to drive implementation.
• Document your intent/semantics in the “specifications” part (of
each model element)
10
Working out your use cases
• You don’t immediately start by detailing out all your
uses-cases (remember: iterative approach)
• E.g. these three levels:
– brief : single paragraph description
– casual : multi-paragraphs, covering multiple scenarios.
– fully dressed : in all details, as in A&N
11
Detailing use cases
• A use case specification provides the details of a use case.
However, UML does not provide a standard for uc-spec. A&N
suggests this template:
ID 1: Buy Item
Desc: a customers buy an item from the shop.
Primary actors: customer
Secondary actors: postal company, credit card company
Pre-conditions: Main flow:
1. The use case starts when the customer clicks on “buy”.
2. The system determines which item to buy.
3. Charge customer
4. Handle delivery
Flow: describing how the
functionality is broken down
to a sequence of smaller
‘activities’.
Post-conditions: the item is sent
12
Example: web-ads
• Functional req: to show ads in websites, and
reroute users when they click
• Actors: user, site owner, ad owner
• Use cases: make new add, add add to a site,
rerouting user
13
Use case’s flow
• A&N add “if” and “while” for expressing flows.
• You can also specify alternative flows, e.g. to express
– how you handle error
– interruption to the main flow (e.g. user cancels)
Main flow:
...
2. If the customer’s credit card is valid
2.1. For each item in the basket:
2.1.1. Charge the item separately to the credit card
2.2. The items are packed and shipped
2.3. Charge the shipping cost to the credit card
3. Else the items are not shipped
Alternative flows:
• At 2.3. If today is the customer’s birthday, shipping cost is free.
• At 2.2. If some items are large, include ShippingLargeItems
refer to another use case
14
Using <<include>> to split your use-cases
Online shop system
customer
Buy Item
<<include>>
Deliver
Item
Add Item
shop
owner
delivery
company
Charge
customer
credit card
company
15
Wrong perspective...
Browse Items
Customer
functionalities
<<include>>
Buy
functionalities
Buy
<<include>>
Buy on
Discount
customer
Profile
Management
• where the actual works are on the leaves...
• You are trying to structure functionalities, but this is not what
we primarily want to capture in a use case “diagram”.
16
Soccer championship use case ...
(just kidding …  ; no this is not how we should use use case )
Spot
Robben
<<extend>>
Shoot
Setup
van Bommel
X
van Persie
Sprint
Cross
Robben
<<extend>>
17
Include and extend
• When a use case becomes too big ... split it with “include”, which is
also useful to indentify important sub-functionalities.
Buy Item
<<include>>
Deliver Item
Buy Item
<<extend>>
condition: customer lives in Europe
ext. point: ext.dlv
Deliver Item
• Or you can introduce “extension points” ... but you are cautioned:
– stakeholders have great difficulty understanding <<extend>>
– surprising numbers of designers misunderstand the semantics
– most sources, incl A&N, are not clear what the semantics is
18
Extension
point
Buy Item
<<extend>>
condition: customer lives in Europe
ext. point: ext.dlv
Deliver Item
ID 1: Buy Item
…
Main flow:
1. The use case starts when the
customer clicks on “buy”.
2. The system determines which item
to buy.
ID 2: Deliver Item
…
Extentsion point: ext.dlv
3. …
19
And can we do something with this..?
Browse Items
customer
reseller
Browse Items
buyer
Buy Items
Get
commission
Buy Items
Get
commission
customer
reseller
• You can introduce generalization/specialization relations
between actors and use-cases.
• Use with caution ... because it is vague what you actually can
specialize.
20
A&N, on specializing use-case
(B) Buy Items
(C) Buy Items with
discount
inherit-from-B can-add can-override
Relationship
Y
Y
N
pre/post-cond
Y
Y
Y
steps in flow
Y
Y
Y
extension points
Y
Y
N
• how about inclusion?
• problem in describing sub-use-case
• problem in maintaining consistency
21
Pre and post-conditions
ID 1: Buy Item
Desc: a customers buy an item from the shop.
Primary actors: customer
Secondary actors: postal company, credit card company
The customer has a valid creditcard
&& valid address
&& no export exclusion applies to his location
Pre-conditions: Main flow:
1. The use case starts when the customer clicks on “buy”.
2. The system determines which item to buy.
3. Charge customer
4. Deliver item
Post-conditions: the item is sent
The item is handed over to the delivery company;
there should be a proof of that.
&& The customer’s credit card is charged (the item
price + shipping cost); there should be a proof of
that
&& Those proofs are saved, and also emailed to
the customer.
Towards design this would suffice; but towards testing you may need to put more effort in detailing
pre- and post-conditions; in particular if you plan to out-source some of the testing tasks (e.g. the
“acceptance testing”).
22
Before you start bloating your use case
specifications...
Pay
Primary actor: customer
Main flow:
1. The use case starts when the customer clicks on “pay”.
2. Get the items from the basket.
3. Calculate the total price.
4. Convert the price to customer’s currency.
5. Check if the customer still has enough balance.
...
• You should focus on “what” (are required?), not the “how”
(the system does the work).
• Try to keep each UC-spec not bigger than ...
– A&N : 1 page
– Larman : fully dressed if often 3 – 10 pages
23
Check your coverage!
system
analyst
find functional requirements
find non-functional reqs
architect
trace requirement to use cases
• You don’t have always have 1-1 mapping between functional
reqs and use-cases  make sure that you have cover all
functional reqs.
24
Not used, future backup
25
Use case, or activity ?
• Are these use-cases?
– down-loading a course’s slides
– logging in
– selecting which course to register
• Boss test: a task performed (read: use-case) should add value
to my business!
Boss : “Sponge Bob, what were you doing all day?”
Sponge : “Down-loading MSO slides boss!”
Boss happy? (yes/no)
• Size test: if it is too small, don’t bother me.
• Use reasonably...
26
Example
iStudent will be a web-based system to let you and your mentor
keep track of your study progress and to register to courses.
You are asked to propose requirements in terms of use cases.
view progress
student
mentor
register course
unregister course
register exam
unregister exam
27
System boundary
iStudent Service
student
mentor
student desk
staff
Student
Administration
Subsystem
sys. admin
Boundary defines who your actors, and what your functionalities are.
28
Example
Brief/casual :
Fully dressed :
Use case : view progress
Use case : register course
primary actors: student, mentor
primary actors : student
pre-condition:
the student has passed all background courses
&& the student has a compatible study programme
&& the course is not full
pre-condition: for student: the progress
belongs to him; for mentor: the progress
belongs to one of her students
This let this student/mentor view and
browse through the student’s results.
post-condition: none
main flow:
1.
2.
3.
4.
5.
The use-case starts when the student requests it.
The system validate the student’s registration status.
The system checks if the course still has a place.
If 2 and 3 are ok, the student is registered.
Send a confirmation email to the student.
post-condition : the student is registered for the course.
alternate flow:
3.1. If the course is full, no registration takes place.
3.2. A set of alternative courses are offered to the students.
29