Ivar Jacobson on Use Case 2.0

Show Notes

• 00:13 Introduction
• 00:28 Introducing Use Case 2.0
• 00:36 Use Case 2.0 has been adapted to work well with agile teams to find elements for the backlog 
• 00:51 These ideas have evolved over the last seven years
• 01:04 Use Case 2.0 expand on the ideas embodied in user stories
• 01:18 Requirements in any format have a huge impact on what is built
• 01:26 This does not mean you need a written requirements specification document
• 01:35 Requirements can be tacit knowledge but they should be made explicit in some form because they play such a key role in software development
• 01:47 They are a key input from business analysis – will the product you plan to build make money?
• 02:00 Clear requirements are important for creating a useable architecture – you don’t want to have to constantly redesign the architecture of the product
• 02:14 Some up-front design is needed in all software development projects
• 02:27 You need the skeleton system that has the key requirements embodied in it
• 02:36 With this approach, as you add more requirements you don’t need to change the skeleton, you simply flesh out the rest of the product
• 02:44 To be able to test a product you need to have requirements to test against  
• 02:51 Testing is impacted by the ability to communicate good requirements 
• 02:57 Reusability is another important focus for requirements
• 03:12 User stories are good as backlog elements in modern software development
• 03:31 Use cases serve multiple roles from ideation through design and development to testing
• 03:45 Use cases give you the big picture
• 03:52 Product inception activities include identifying who the users are and what the system needs to do for those users – these are the use cases
• 04:01 This does not need to take a long time to do – within 3-4 hours you can get a good picture of why the key users are and what they need from the system
• 04:14 This big picture is very valuable for the whole team to understand
• 04:28 From these big-picture use cases you can slice them into small, meaningful value-contributing pieces called use case slices
• 04:36 A use case is a set of use case slices.  Each use case slice is the equivalent of one or two user stories
• 04:43 Use case slices populate the product backlog
• 04:48 You continue breaking them down progressively until you get to elements that can be implemented in one sprint
• 04:55 The people who need to see the high-level picture get the use case model, the people who need the detail get that detail as they need it
• 05:08 Any system should be able to be represented by between 10 and 20 key use cases
• 05:30 This size is a product that will take a reasonable amount of time to build and will add value to the organisation
• 05:36 The big picture is understandable by senior leaders and they can identify important missing elements and see where customer value is derived
• 05:53 You can communicate the ideas to customers using the higher-level use case models
• 06:02 At the detailed level, use case 2.0 supports test-driven development
• 06:13 The use case model provides persistence of understanding over time and supports multiple releases of a product
• 07:16 The progressive elaboration nature of use case 2.0 allows an initial understanding of the big picture with an evolving understanding of the detail as work progresses
• 07:36 These use cases are not just useful for the development team, they are understandable by other stakeholders who contribute to product success 
• 07:48 Salespeople can use the use case model to communicate with customers or potential customers
• 08:01 The use case model helps identify the product architecture – the highest priority use cases and their most important slices form the basis for the architecture
• 08:36 The term Use Case has become commonly used because it conveys the intent clearly
• 08:56 There is great value in seamlessly moving identified use cases into a development environment
• 09:11 Use cases provide common context and clarity of understanding across different interested parties
• 09:57 How use cases identify and address identifying the non-functional or quality aspects of a product
• 10:12 Describing the structure of a use case using a banking transaction example
• 10:45 Some non-functional requirements are common across the whole system and these need to be articulated separately
• 11:04 Most of the non-functional requirements in a system are use case specific and can be communicated in the use case text
• 11:31 All use case slices for a single use case will inherit the non-functional requirements from the parent use case
• 11:56 Use cases are discrete and independent from one another; use case slices are very dependent on one another and on the parent use case
• 12:08 There will be a logical sequence to the use case slices used to build the product
• 12:51 Introducing the idea of a scenario as a described path through a use case
• 13:15 The ebook on Use Case 2.0 is freely available
• 13:25 There is also elearning available for Use Case 2.0
• 13:47 There is an online portal available with lots of use case content freely available
• 15:05 Use cases, user stories, Scrum and other techniques are just practices – the work on Essence is about creating a platform for all practices so practitioners can find the ones that work best in their context

Mentioned:

• Ivar Jacobson International
• 1st Part of this interview – The Essence of Software
• Use Case 2.0 ebook
• Use Case 2.0 eLearning
• Use Case Portal
• The Essence standard