Why Use Use Cases?

The use case diagram is part of UML (see Chapter 5). It is a simple diagram for stake-holders to review and can help to ease the communication between business stakeholders and technical stakeholders. Like many analysis techniques, this one appears much more simple and straightforward than it is. The resulting diagram is not as important as the discussions and decisions that are made during its development. This is a great technique to use with business stakeholders, specifically decision makers, because it requires decisions about how people (actors) will work with the software. A simple line on this diagram between an actor and a use case could completely change a business person’s job. It may necessitate job description changes, responsibilities changes, and new procedures.

Use case descriptions—especially the primary and alternate paths—are great for brainstorming with software users about design options. Working through the specific interactions between the user and the software helps design a system that more accurately mirrors the natural workflow of the user. Even when the team thinks it has a consistent vision of the solution, writing down these specific steps/interactions points out different views and allows decisions to be made before coding begins.

In addition to changing a person’s job, design decisions often change external interfaces also. With almost universal access to the Internet, many organizations are putting more functionality in the hands of their customers. The customer is an actor whose role is changing significantly. Customers do not have job descriptions or procedure manuals.

They are not paid by an organization to do work. Be aware that shifting an interaction with software from a business worker to the customer is a significant change. It has occurred with banks (ATMs), retail stores (credit card scanners), order processing (over the Internet), and many customer service departments (voice prompt phone systems). Turning the processes of the organization over to the customer requires that the processes be very well defined and the software automation be extremely usable and intuitive. When the customer becomes your actor, new procedures need to be developed to support this actor. Employees shift their focus from the original process to answering customer questions and helping the customer navigate the technology.

Case in Point

I discovered the value of use case descriptions when designing a Web order processing system. Some team members assumed that customers would be required to log in before browsing the product catalog. The marketing stakeholders disagreed. They wanted to allow anyone to browse products without having to set up a login ID. This difference of opinion was discovered on the first step of the use case description: order product.

Prototypes/Simulations

A prototype is a model of a user interface in an automated system. It may be a screen layout, report layout, or data entry form. It is built as part of a software design to show the stakeholders what the software will “look like.”

When a proposed solution (to be) involves the addition of or update to an online screen, analysts often create a prototype that shows the screen design, along with a storyboard or simulation that demonstrates how the screen interacts with other screens.

Along with the prototype, functional requirements must include a description of how data entry fields are edited and validated, along with business rules that should be enforced for users of the screen. Warning messages, error messages, and other informational text to be displayed must be specified by the BA in conjunction with the SME. Messages written by developers often are not understandable to business users.

A storyboard shows a series of screens and how the software user should be able to navigate between them. See Figure 6.7 for an example of a storyboard diagram created using the iRise Studio™ simulation tool. Each rectangle on the diagram represents a screen and has an associated screen design.

Figure 6.7: Sample Storyboard

A screen layout can be created using a simulation tool like iRise, a development tool like Microsoft Visual Studio®, a graphic design tool like Microsoft Visio, or simply on paper. The design should show data fields in their relative positions, field length, field labels, text boxes, menus, selection buttons, etc. The more detailed the prototype, the more accurate the requirement and the faster the reviews and development. See Figure 6.8 for an example of a screen layout.

Figure 6.8: Sample Screen Layout

Simulation means “something that looks or acts like something else.” Simulating a screen or series of screens allows the user to actually enter data on screens, click on menus and selection fields, navigate between screens, etc. It mimics the desired online functionality to confirm requirements with the SMEs and provide clear specifications to the developers.

Report layouts are similar to prototypes in that they show how software will interface with a user. The report layout specifies how data from the database will be presented to users, including formatting, column headers, and pagination. Report layouts are excellent communication tools for developers because they specifically show the end product expected by the user. Report layouts are accompanied by descriptions of the calculations, summarizations, etc., along with the names of the database tables and columns to be used.

Prototyping is such an effective requirements analysis and presentation technique that it is used on most software development projects. Even a simple screen change can be implemented incorrectly without a clear visual requirement. There are a few cautions when using prototypes. The first caution is not to create or present prototypes too early in a project. Business requirements should be clearly understood first, and the analyst should be sure that a software solution, specifically an online screen, is the most appropriate approach to answering the business need. When users start reviewing a prototype, they can get very distracted with its aesthetics and forget to review it for core business requirements. Prototypes may be presented early in a project when business stakeholders don’t have any idea about what their potential solution might look like or when the team is working on the feasibility of an idea.

The second caution is to be careful not to set unrealistic stakeholder expectations. When a user sees a prototype on a computer screen, he or she may believe that the application is complete and functional. The user may assume that the project is nearing completion and anticipation may rise. BAs must be sure to clearly explain that the prototype is simply a picture or mock-up of the final software. An analogy would be the Hollywood house. When moviemakers need a particular style of home or building for a scene in a movie, they build a façade that looks exactly like the building in the story. But if you were to walk through the front door, you might see two long poles propping up the façade, with no ceiling or walls. This is a good description of a prototype.

Finally, a third caution relates to the application software development. Prototypes built by developers are often considered “quick and dirty.” They often do not follow enterprise coding standards or best practice software development principles. They are intended to be used as requirements deliverables and then thrown away. They are not production-quality software. Once the requirements have been approved, the development team should build the software based on the requirements using the standard tools and best practices expected. It may be tempting to use the prototype as a starting point for the software development because it would appear to save time, but when the prototype is used to finish the application, the resulting software is often poorly structured and difficult to maintain. Imagine building a real house around the Hollywood façade. Walls would be forced to fit into a front that wasn’t designed as a part of the whole (van Duyne et al., 2006).