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.

student

mentorregister 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 :