Back to top

Tooling

An overall principle should always be to keep the things produced as simple and lightweight as possible, especially when getting started. Whiteboards, Flip Charts, and Post-it notes have many advantages when you start and have zero barrier to adoption. They promote a lightweight mindset and are particularly useful for small co-located teams.

Only look for more advanced tooling as and when the need arises, such as distributed teams, solutions that will be developed and maintained / enhanced over a long period of time, or regulated or safety-critical environments which require rigorous proof of coverage and traceability.

Creating a Use-Case Model

Creating the initial Use-Case Model is a collaborative effort and is usually a facilitated session involving various stakeholders. Starting with a combination of Whiteboards, Flipcharts and PostIt Notes allows everyone to be involved without obsessing over notation or needing a particular person to ‘drive’ a tool.

Many teams don’t have the luxury of being co-located so in that instance an Electronic Whiteboard of some kind of video/audio conferencing will be needed. Generic Electronic Whiteboarding tools can all deal with simple Use-Case Diagrams, such as Microsoft Surface Hub, Mural, or Miro. When the initial Use-Case model has stabilized then take a picture of it and capture it neatly in any drawing package or modelling tool that can draw stick men, arrows and ellipses. Most of them! A number of full UML Modelling Tools are available but any choice will be specific to your existing environments and circumstances.

Authoring Use-Case Narratives

The initial authoring of the Use-Case Narratives is best done collaboratively at a Bulleted Outline level of detail, typically during the early workshops on a flipchart.

As soon as the use case is understood though, it quickly switches to an authoring tool to write the text. As always you aim to keep it simple and lightweight, starting with the outline and only adding details as when they are needed.
The vast majority of people use Word for this as they already have it, are familiar with it and can make use of the advanced authoring, structuring and review functionality.

Organizations will find it useful to have a template to guide new authors and help with consistency. The Use-Case 2.0 Practice contains a template in the Resources section for a Use-Case Narrative that can be based as a starting point, along with templates for other items such as a Use-Case Model Survey, a Test Case, and Supporting Information.

Teams that need to manage complex requirements in regulated or safety-critical environments will often use requirements management tools such as DOORS or Jama. These manage the relationships between different parts of the requirements model and other constraints or regulations, enabling them to report on traceability, coverage and compliance.

Managing Use-Case Slices

The simplest form of managing the Use-Case Slices is in the same way many co-located agile teams work, with physical boards and cards or Post-it notes. Here we can see Post-its for each Use-Case Slice with its relationship to the flows, tests, and size estimate.

When it comes to scoping, prioritizing and keeping track of the state of items, the Use-Case Slice is used as the items on a Backlog, although with Use-Case 2.0 we also get the Bigger Picture too for context. We even have the ability to do some course-grained scoping and prioritization at the Use-Case level before we even get to the slices.

When managing and tracking the state of the Backlog we can see that the Use-Case Slices can be the items on a typical Kanban board, with the work in progress limits shown in red. The Use Case 2.0 practice has clear definitions of the Use-Case Slice states with their checklists which help fully define the criteria for the columns.

Tracking individual Use-Case Slices is the equivalent of tracking individual User Stories which many teams are familiar with. Simple tools like spreadsheets or list management tools like Trello can be used for managing them, but most teams will use their own preferred backlog management tool.

Most backlog management tools such as GitHub, Jira, VersionOne, Rally Software, or Jile will manage lists of such items with various attributes, state, and relationships to other items such as Test Cases.

Modeling Use-Case Realizations

The Use-Case Realization is a way of describing how a particular slice of a Use Case will be implemented and can take many forms, such as class diagrams, sequence diagrams, screen flows, etc. The simplest and lightest way of working would be at the beginning of a Sprint for the team to sketch out on a whiteboard how they propose to implement some of the Use-Case Slices that are not immediately obvious, perhaps those that introduce new components. This facilitates the team discussion and serves its purpose for that sprint.

If more detailed design is needed or a permanent record of the design to be kept then more formal UML models can be created using whatever modelling tool the organization has chosen. Once again keeping things lightweight should still be a goal. Illustrating and explaining interesting slices through the system that exercise key parts of the architecture is usually better than trying to model everything.

Managing Test Cases

The Test Cases, which describe inputs and expected results, will be large in number and will need some kind of tool support to manage them and their relationship to the Use Case Model and other requirements in the Supporting Information.
The Use-Case 2.0 Practice provides a starter template in the Resources section for the information captured in a Test Case.

It is expected that this information is normally managed in the tool of choice of the team and their particular environment. In many cases this will be the same tool that they choose to manage their backlog items for easier management of the relationships between the Use Case Slices and the Test Cases.

The Use-Case 2.0 Practice promotes a test-first approach and incrementally delivering value slice by slice, therefore automation of the testing becomes important as they will need to be replayed many times.