Claim Analysis

Background & Scope

We try to think of Claim Analysis in the context of SBD (Scenario Based Development Framework).

Please take a look at Figure 1.6 at Page 25 in the book a diagram of the structure of SBD.

In SBD (Scenario Based Development Framework), there are two kinds of claim analysis

1. Claims about current practice (We use it in the requirements phase to understand the current problem)

2. Claims about usability (we use it in the design phase to understand the usability of the new product, application, or solution)

In reality, these phases are not clearly separated. It's an iteration process.

The claim analysis we are talking about today is on current practice.

What does claim analysis do?

Definition in the book: identify features of a situation that have important effects on the actors. (Page 72, third paragraph)

More details of Claim Analysis on Problem Scenarios

Features with good and bad effects

Related to tradeoffs (with upsides and downsides), but claims are tied to specific artifacts and activities, can be regard as a kind of tradeoff. (Page 72, third paragraph)

One rule to remember, and it's a key aspect of SBD: even though we are most interested in "fixing" problems, we want to make sure that we do not "break" things that are working well.

In short: Maximize the positive effects, minimize the negative effects. This is easy to say than do, so claim analysis will help us to achieve this goal better.

Why do we want to do Claim Analysis on current analysis?

In short, we try to find out the good practice of the current situation and keep it as much as possible while trying to improve or get rid of the bad practice we have today. Doing Claim Analysis will help us to understand the pros and cons of the current approach.

Benefits of doing claim analysis on problem scenario (The exact sentences are described at bottom of Page 72)

* Elaborate a set of scenarios (How features impacts on actor

* Documents why one/more scenarios were written, by isolating the most important features of the narratives.

* Extend the scenario. Points out more things from this scenario

* Balanced view of situation. Help you to think on both sides of the equation

* These claims will try to motivate design reasoning - minimize negative reasoning, while keep or enhance positive reasoning

How to do claim analysis? (Page 74)

First, identify the "interesting features" of a scenario.

Remember: during requirement phase, a claims feature is anything in the situation that has notable effects on an actor's experience -- an object, a procedure, even another person

* Think about objects, procedures, and people

* Some features may emerge during theme analysis

* Think of the technology you want to apply, so talk about the existing technology you want to replace.

Second, consider its consequences for the actors, and write the positive as well as negative effects down.

Let's work on Krista's example.

What are some of the objects?

Have a small device to test blood sugar level

+ Inexpensive, easy to replace if lost

+ Easy to carry around

- Hard to read with small display

- Easy to lost since it's small, can be put in any place and get lost

(In class, we have talked about some other examples such as telephones, etc.)

What are some of the procedures?

Senior check her blood sugar level everyday

+ Will notice problems quite fast, everyday

- Have to remember doing it everyday, can be difficult for seniors with bad memory

Write down testing results and keep a record of the blood sugar level history

+ Will have a record for the senior so doctor cans analysis when needed

- Have to remember doing it

- Waste a lot of paper, and can take a lot of storage room

- Extra work is need if the doctor wants to compare a large number of records, he/she will have to enter the data into the computer for analysis.

What are some of people?

Have Liz around to remind Sally to do the blood tests

+ Can help when Sally forget to do the test

- Sally start to depend on Liz, and start to take less responsibility to obey the test schedule. When Liz forgets or is busy, the chance for Sally to forget is even higher.

Ok, how many scenarios and claims are enough, and how do we know if they are the right ones?

The answer is: there is no simple answer

SBD is an inquiry method -- it raises questions that promote rich discussions and understandings of people and activities. (Page 75, paragraph 2)

The goal is trying to understand the problem (current practice) as much as you can so that you can design something to improve the current situation. The more prepared you are, the better and easier you will be in the later stage, but when you have a deadline, you need to think of how much time and efforts you are going to put into this phase.

A few guide lines

* Write at least one scenario for every stakeholder

* Analyze at least one or two claims from each scenario

* For stakeholders with many tasks or with tasks that are complex, write multiple scenarios.

* If an exhaustive analysis is demanded, more systematic methods such as hierarchical task analyses or use cases should be developed (Page 75)

Extra notes:

Problem scenarios and claims are not requirements specifications

They express requirements only implicitly by describing the needs and opportunities in the current situation. In class, we talk about the debugging example. Know where the bug is, and how the bug behaves doesn’t give the solution to fix the bug, but in order to fix the bug, you definitely need to know where the bug is and how it behaves. Same thing here, knowing the problem space doesn’t give you the specifications for your new product, and without knowing the current problem, there is no way you can improve it. In summary, Claim Analysis helps you to understand your problem well, but understand your problems well doesn't tell you how to design your new product, although it helps.