Use cases - a waste of time? Søren Lauesen, Februar 2010 IT-University of Copenhagen

First level: Handles 80% of requests. Second level: Handles 10% within a short time. Want to improve existing support system or buy a new one. 2. Hotline case Experiment: Analysis report describes the case - 4 pages and a screen. Write requirements with preferred use case, task, scenario, user stories - and maybe data requirements. Don't care about quality requirements. 8 replies with use cases - many styles 3 replies with tasks 6 seasoned consultants/developers 1 Indian software house on contract 3 research teams 1 PhD student

3. Hotline case - overview of three replies

4. Petersen - dialog steps in one column. Myopic use case Write note + transfer request: Inconvenient dialog Easy to read - almost

5. Paech - dialog steps in two columns. Program-like Complex, but closed task Rather free sequence

6. Lauesen - task. No dialog. Problem as requirement Requirement: Support subtasks

Use cases: Oops - we described the new system to be built 7. Verify requirements - compare systems Indian developers: Make a decision matrix e.g. Automatic request state management Petersen: Define test cases Including all dialog steps? Or only the key part = one task step? Tasks: Test that all task steps are supported Rate how well - notes to the right Our hotline expert verified the existing support system anyway

8. Petersen - verification by hotline expert OK Missing: send mail to him

9. Paech - verification New OK

10. Lauesen - verification New OK

Dialog steps not true requirements - or a bad dialog 11. Correctness - any false requirements? Rules and preconditions invented - the fields are there and the gurus... Example: R1. Only problems with high priority may be requested via phone or in person. R2. For statistical purpose it is not allowed to create a request for more than one problem. Precondition: At least one request must be in the list.

12. Completeness: skills, time spent + problem coverage Problems without solution ignored

One screen per step? No. Maybe 6-10 screens. Dialog as specified? Well not quite. 13. New user interface Not my business ! Use cases are functional requirements and have nothing to do with UI Problems are lost - nobody cares to solve them Tasks + Virtual Windows: All three task replies made three screens: List of requests All about one request List of supporters and their current role Next, add functions to the screens to support all steps Checking that everything is okay? Write a use case

Don't specify a dialog Don't define your solution as a requirement - others may have better ones Allow problems to be requirements Don't invent rules Don't invent preconditions You can't prevent the user from trying. Checking is part of the use case 14. Conclusion In other words: Use tasks Don't waste time on use cases