requirement [a&n 3-5]
Post on 25-Feb-2016
42 Views
Preview:
DESCRIPTION
TRANSCRIPT
Requirement[A&N 3-5]
2
“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
3
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...
4
Examples
• SH: “Students can view grades”
• SH: “A grade above 6.0 is a pass”
• SH: “Every course is 7.5 ects”
(deletion just their own grades)
(distortion actually >= 6.0)
(generalization colloquiums are however 5 ects)
5
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
6
“Requirement” as a core WF within UP
Inception Elaboration Construction Transition
Iteration: 1 2 3 4 5 ...
time
• requirement
• analysis
• design
• implementation
• test
Typical deliverables: • project plan,• use case models 20%
Typical deliverables: • updated project plan,• use case models 80%• static and dynamic models• executable architectural baseline
7
Requirement Work Flow (in UP)
find actors and uses cases
prioritize use cases
detail use cases
prototype user interface
systemanalyst
architect
use case specifier
UI designer
Not showing the activities to produce functional/non-functional reqs .. See A&N.
some activities would be in the Inception phase, some could be in the elaboration phase.
We won’t discuss this
8
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.
9
Use case diagram, and its elements
Online shop system
customer
shopowner
deliverycompany
credit cardcompany
Buy Item
Add Item
subject name
subject boundary
actor
use case
“involvement” relation
A use case may have primary and secondary actors..
use case
With respect to a use-case, actors can be primary or secondary.
10
Model and its “specification” (backplane)
• 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)
ItemnamepriceapplyDiscount(d)order()
Buy Item
Backplaneclass ItemDesc: Represents an item to sell.applyDiscount(d), apply the discount d (in %) to the current price.order(), produces an order containing this item.
Backplaneusecase Buy ItemDesc: ……
11
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
12
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 ItemDesc: a customers buy an item from the shop.Primary actors: customerSecondary 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 customer4. Handle delivery
Post-conditions: the item is sent
Flow: describing how the functionality is broken down to a sequence of smaller ‘activities’.
13
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
14
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 card3. 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
15
Using <<include>> to split your use-cases
Online shop system
customer
shopowner
deliverycompany
credit cardcompany
Buy Item
Add Item
Deliver Item
Charge customer
<<include>>
<<include>>
16
Wrong perspective...
• 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”.
customer
Browse Items
Customerfunctionalities
Buyfunctionalities
ProfileManagement
Buy
Buy onDiscount
<<include>>
<<include>>
<<include>>
<<in
clude
>>
<<include>>
<<include>>
<<include>>
17
van Persie
Soccer championship use case ...(just kidding … ; no this is not how we should use use case )
van Bommel
Spot Robben
Sprint
Cross
<<extend>>
Robben
Setup
<<extend>>
Shoot
X
18
Include and extend
• When a use case becomes too big ... split it with “include”, which is also useful to indentify important sub-functionalities.
• 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
Buy Item
Deliver Item
<<include>>
Buy Item
Deliver Item
<<extend>>condition: customer lives in Europeext. point: ext.dlv
19
Extension point
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. …
Buy Item
Deliver Item
<<extend>>condition: customer lives in Europeext. point: ext.dlv
ID 2: Deliver Item…
20
And can we do something with this..?
• You can introduce generalization/specialization relations between actors and use-cases.
• Use with caution ... because it is vague what you actually can specialize.
customer
reseller
Buy Items
Browse Items
Get commission
buyer
reseller
Buy Items
Browse Items
Get commission
customer
21
A&N, on specializing use-case
(B) Buy Items
(C) Buy Items with discount
inherit-from-B can-add can-overrideRelationship Y Y Npre/post-cond Y Y Ysteps in flow Y Y Yextension points Y Y N
• how about inclusion?• problem in describing sub-use-case• problem in maintaining consistency
22
Pre and post-conditions
ID 1: Buy ItemDesc: a customers buy an item from the shop.Primary actors: customerSecondary 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 customer4. Deliver item
Post-conditions: the item is sent
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”).
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.
The customer has a valid creditcard&& valid address&& no export exclusion applies to his location
23
Before you start bloating your use case specifications...
• 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
PayPrimary actor: customerMain 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....
24
Check your coverage!
• You don’t have always have 1-1 mapping between functional reqs and use-cases make sure that you have cover all functional reqs.
find functional requirements
find non-functional reqs
trace requirement to use cases
systemanalyst
architect
25
Not used, future backup
26
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!
• Size test: if it is too small, don’t bother me.• Use reasonably...
Boss : “Sponge Bob, what were you doing all day?”Sponge : “Down-loading MSO slides boss!”
Boss happy? (yes/no)
27
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.
studentmentor
register course
view progress
unregister course
register exam
unregister exam
28
System boundary
student
mentor
StudentAdministration
Subsystem
iStudent Service
student deskstaff
sys. admin
Boundary defines who your actors, and what your functionalities are.
29
Example
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
Use case : register course
primary actors : studentpre-condition: the student has passed all background courses && the student has a compatible study programme && the course is not full
main flow:
1. The use-case starts when the student requests it.2. The system validate the student’s registration status.3. The system checks if the course still has a place.4. If 2 and 3 are ok, the student is registered.5. 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.
Brief/casual : Fully dressed :
top related