Presentation on theme: "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: –"— Presentation transcript:
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 UMLs workout of textual func. req 2 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... 3
Examples SH: Students can view grades SH: A grade above 6.0 is a pass SH: Every course is 7.5 ects 4 (deletion just their own grades) (distortion actually >= 6.0) (generalization colloquiums are however 5 ects)
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 6 InceptionElaborationConstructionTransition 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
Requirement Work Flow (in UP) 7 find actors and uses cases prioritize use cases detail use cases prototype user interface system analyst 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 wont discuss this
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); dont confuse it with use-case diagram. 8
Use case diagram, and its elements 9 Online shop system customer shop owner delivery company credit card company 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.
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) 10 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: … …
Working out your use cases You dont 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: 12 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.
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 cases 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) 14 Main flow:... 2. If the customers 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 customers birthday, shipping cost is free. At 2.2. If some items are large, include ShippingLargeItems refer to another use case
Using > to split your use-cases 15 Online shop system customer shop owner delivery company credit card company Buy Item Add Item Deliver Item Charge customer >
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. 16 customer Browse Items Customer functionalities Customer functionalities Buy functionalities Buy functionalities Profile Management Profile Management Buy Buy on Discount Buy on Discount >
van Persie Soccer championship use case... (just kidding … ; no this is not how we should use use case ) 17 van Bommel Spot Robben Sprint Cross > Robben Setup > Shoot X
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 > – surprising numbers of designers misunderstand the semantics – most sources, incl A&N, are not clear what the semantics is 18 Buy Item Deliver Item > Buy Item Deliver Item > condition: customer lives in Europe ext. point: ext.dlv
Extension point 19 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 > condition: customer lives in Europe ext. point: ext.dlv ID 2: Deliver Item …
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. 20 customer reseller Buy Items Browse Items Get commission Get commission buyer reseller Buy Items Browse Items Get commission Get commission customer
A&N, on specializing use-case 21 (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 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
Pre and post-conditions 22 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.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 customers 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
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 23 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 customers currency. 5.Check if the customer still has enough balance....
Check your coverage! You dont have always have 1-1 mapping between functional reqs and use-cases make sure that you have cover all functional reqs. 24 find functional requirements find non-functional reqs trace requirement to use cases system analyst architect
Use case, or activity ? Are these use-cases? – down-loading a courses 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, dont bother me. Use reasonably... 26 Boss : Sponge Bob, what were you doing all day? Sponge : Down-loading MSO slides boss! Boss happy? (yes/no)
System boundary 28 student mentor Student Administration Subsystem iStudent Service student desk staff sys. admin Boundary defines who your actors, and what your functionalities are.
Example 29 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 students 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: 1.The use-case starts when the student requests it. 2.The system validate the students 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 :
Your consent to our cookies if you continue to use this website.