Requirement [A&N 3-5]

1. Requirement[A&N 3-5]

2. 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

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 • 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 2 3 4 5 ... time

7. Requirement Work Flow (in UP) system analyst find actors and uses cases prioritize use cases architect use case specifier detail use cases prototype user interface UI designer 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.

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 With respect to a use-case, actors can be primary or secondary. subject name actor Online shop system “involvement” relation Buy Item customer delivery company use case A use case may have primary and secondary actors.. Add Item use case credit card company shop owner subject boundary

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) Item name price applyDiscount(d) order() 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 usecaseBuy Item Desc: … … Buy Item

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 Item Desc: a customers buy an item from the shop. Primary actors: customer Secondary actors: postal company, credit card company Pre-conditions: - Main flow: The use case starts when the customer clicks on “buy”. The system determines which item to buy. Charge customer 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 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

15. Using <<include>> to split your use-cases Online shop system Buy Item customer <<include>> delivery company Deliver Item <<include>> Charge customer Add Item credit card company shop owner

16. Wrong perspective... Browse Items • 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”. Buy <<include>> <<include>> Buy on Discount Customer functionalities Buy functionalities <<include>> <<include>> customer <<include>> <<include>> Profile Management <<include>>

17. Soccer championship use case ...(just kidding …  ; no this is not how we should use use case ) Spot Robben <<extend>> Shoot Setup X van Bommel van Persie Sprint Cross Robben <<extend>>

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 Buy Item condition: customer lives in Europe ext. point: ext.dlv <<include>> <<extend>> Deliver Item Deliver Item

19. Buy Item Extensionpoint condition: customer lives in Europe ext. point: ext.dlv <<extend>> Deliver Item ID 1: Buy Item … Main flow: The use case starts when the customer clicks on “buy”. The system determines which item to buy. Extentsion point: ext.dlv 3. … 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. Browse Items Browse Items customer Buy Items buyer Buy Items Get commission Get commission reseller customer reseller

21. A&N, on specializing use-case (B) Buy Items (C) Buy Items with discount inherit-from-B can-add can-override Relationship Y YN pre/post-cond Y YY steps in flow Y YY extension points Y YN • how about inclusion? • problem in describing sub-use-case • problem in maintaining consistency

22. 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: • The use case starts when the customer clicks on “buy”. • The system determines which item to buy. • 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”).

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 Pay Primary actor: customer Main flow: The use case starts when the customer clicks on “pay”. Get the items from the basket. Calculate the total price. Convert the price to customer’s currency. 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. system analyst find functional requirements find non-functional reqs architect trace requirement to use cases

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. view progress mentor student register course unregister course register exam unregister exam

28. System boundary iStudent Service Student Administration Subsystem student student desk staff mentor sys. admin Boundary defines who your actors, and what your functionalities are.

29. Example Brief/casual : Fully dressed : 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 : 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.