Transcript Requirement
Requirement
[A&N 3-5]
“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 3
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:
project plan, use case models 20%
• • • • Typical deliverables:
updated project plan, use case models 80% static and dynamic models executable architectural baseline
Inception Elaboration Construction Transition
•
requirement
•
analysis
•
design
•
implementation
•
test Iteration: 1 2 3 4 5 ...
time
6
Requirement Work Flow (in UP)
system analyst architect use case specifier UI designer
find actors and uses cases prioritize use cases detail use cases 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 subject name
Online shop system With respect to a use-case, actors can be primary or secondary.
customer
Buy Item
use case A use case may have primary and secondary actors..
delivery company
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 Post-conditions: the item is sent
Flow: describing how the functionality is broken down to a sequence of smaller ‘activities’.
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 <> to split your use-cases
customer
Online shop system Buy Item <
delivery company shop owner credit card company
15
Wrong perspective...
Customer functionalities Browse Items <
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
<
Setup van Bommel van Persie Shoot
X
Robben Sprint
<
Cross
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
<
Deliver Item Buy Item
<
Deliver Item
condition: customer lives in Europe ext. point: ext.dlv
• Or you can introduce “extension points” ... but you are cautioned: – stakeholders have great difficulty understanding <
Extension point
Buy Item
<
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.
Extentsion point: ext.dlv
3. … condition: customer lives in Europe ext. point: ext.dlv
ID 2: Deliver Item … 19
And can we do something with this..?
customer
Browse Items Buy Items
buyer
Browse Items Buy Items
reseller
Get commission 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 pre/post-cond Y Y
N
Y steps in flow Y Y extension points Y 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 Pre-conditions: Main flow: 1.
The use case starts when the customer clicks on “buy”.
2.
The system determines which item to buy.
3.
4.
Charge customer Deliver item Post-conditions: the item is sent
The customer has a valid creditcard && valid address && no export exclusion applies to his location 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 architect
find functional requirements find non-functional reqs 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.
student
view progress register course unregister course register exam unregister exam
mentor
27
System boundary
student
iStudent Service
student desk staff mentor
Student Administration Subsystem
sys. admin
Boundary defines who your actors, and what your functionalities are.
28
Example
Brief/casual : Use case : view progress primary actors: student, mentor 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 Fully dressed : Use case : register course 1.
2.
3.
4.
5.
primary actors : student pre-condition: the student has passed all background courses && the student has a compatible study programme && the course is not full
main flow:
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