Chapter 4. Analysis

This chapter describes the Theme approach to requirements analysis. In earlier chapters, we described what a theme is: an encapsulation of a concern. In this chapter, we look at themes at the requirements-level. Requirements describe behavior associated with concerns. Portions of a requirements document may all describe a particular concern. Grouping those portions encapsulates them in a requirements-level theme. Requirements may describe more than one concern, and so may seem to fit in more than one theme's group of requirements. Some care must be taken to try to achieve theme-orthogonality: themes should not overlap in their requirements groups. At times, rewriting the shared requirement is needed, and at other times, handling the overlap in design is necessary.

An aspect is a special kind of theme: a concern that is triggered by one or more other concerns. So, at this point, we take a requirements-level view of aspects: We consider aspects to be concerns that possess four main traits:

• a concern whose description within a requirement is tangled (irreparably) with the description of other concerns,

• the dominant concern in the tangled requirement,

• concern functionality that is triggered by the other concerns in the requirement,

• concern functionality that is triggered in more than one situation as described in the requirements.

Figure 4-1 depicts scattering and tangling in requirements taken from the set of requirements for the Crystal Game (see the sidebar "Crystal Game" and the appendix). In this figure, some of the pieces of functionality are circled. If they're in more than one requirement, then their circles are linked with a solid line. The solid line indicates scattering of functionality between requirements. If two pieces of functionality appear together in a requirement, they are linked with a dashed line to indicate tangling. This is just a small example, but it conveys the difficulty of trying to mentally disentangle requirement-level relationships. For instance, it takes a minute to see that the "shown" functionality is indirectly related to the "duel" functionality. The purpose of Theme/Doc is to help you better visualize the relationships between tangled functionality and make decisions about how it should be encapsulated in your system.

Figure 4-1. Concerns mixed between requirements.

Crystal Game

The Crystal Game is a location-aware game. Each player is equipped with a handheld device (PDA) through which they interact with the game world. Players explore the physical world using their PDA to tell them which game elements are present in sensor-equipped locations.

The Object of the Game

The object of the game is to collect as many virtual crystals as possible before time runs out. Virtual crystals are distributed around the game-play area at the start of the game. There are also magical items scattered around the game-world. Those figure differently into game-play.

Players

Players can take on three roles: wizard, warrior, and sage. There are also nonplayer characters (NPCs) in the world. NPCs are also wizards, warriors, and sages.

Starting a New Game

One player (the "host") creates a new game. Other players can then join the game. When the players join, they are sent to locations around the game-area. The host's location becomes the "throne room" that figures into the end of the game.

Game Play

Crystals can be discovered by players when they enter a new location. Players can (nonviolently, of course) duel one another for crystals. The winner of the duel receives the wagered crystals from the losing player.

Players interact with NPCs in different ways depending on their role-type, and the role-type of the NPC.

NPCs sometimes demand that players locate magical items in order to receive a crystal that the NPC is hoarding.

As the game progresses, players lose or gain energy. Different acts cause energy levels to go up or down.

Winning and Losing

When the game time is up, all the players must go back to the location deemed to be the throne room to find out who won. The player with the most crystals wins. If two players have the same number of crystals, the one with the most energy wins. If there is still a tie, a duel decides the winner.

Refer to the appendix, "The Crystal Game," for a complete set of requirements.

In the "Finding the Themes" section of Chapter 3, "The Theme Approach," we walked through a simple example of how to identify themes in a set of requirements. Finding themes is a broader task than finding aspects. Finding themes involves identifying groupings of functionality that make sense. As we discussed in Chapter 3, some of these units may be aspects, and some may be base. We looked at how to find a starting list of possible themes, how to narrow those down to a list of actual themes, and then how to decide which themes are crosscutting (aspect) themes and which are base themes.

In this chapter, we delve into these concepts in much greater detail. As a basis for this, we use the Crystal Game example system, described in the appendix, "The Crystal Game." As you will see, the requirements for the crystal game example are not as simple as those we use in the EES from previous chapters. This chapter walks you through applying the Theme/Doc part of the Theme approach when faced with requirements that are not ideal.

We also go over how to know when you are done with the analysis process, or at least when you are "done for now."

First, however, we go over some basics of the Theme/Doc. We start by describing the Theme/Doc views that are used as well as the tool support available to create those views. Then, we take a high-level look at the Theme/Doc process.