Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

This is an interesting and wide ranging thread. I’d like to suggest some definitions and ideas that may help add clarity to the discussion.

I believe that part of the problem is that the UML Specification itself does not define terms well or, in some cases, not at all. Another issue is incorrect ideas about use cases have become repeated so many times that BAs believe they are true. I reference the Great BA fallacies #2: proof by verbosity posted at: http://businessanalysisonlinetraining.blogspot.com/2008/11/great-ba-fallacies-2-proof-by-verbosity.html.

We have developed a methodology over years of experience that may add clarity in this discussion. We define a use case as:

A use case is a set of interactions with a system
that provides a perceivable benefit of value
to someone or something (the user)
playing the use case's role (or part)
from the perspective of the user.

The three fundamental concepts, discussed individually, are:

A.     use case

B.     system

C.     role - yes, role and not actor

A.     Industry wide the use case concept is fairly well understood. It represents functionality that produces a benefit that is perceivable by the user. It describes how a user and a system behave to accomplish the defined goal.

 

B.     The concept of system is more problematic. The most serious problem is that system is typically a synonym for "the thing we are building." Several sub-problems are:

1.      Somehow the term system was hijacked by the IT community. For example, there are "business requirements" and "system requirements." The implication is that if it is not in code it cannot be a system. But businesses have had systems for centuries - long before IT automation existed.

2.      It is a problem that a system is thought of as a simple thing. We have never worked on a simple single system. Every project has been a system of systems.

 

In our methodology, we apply use cases for systems at any level of abstraction – so long as the behavior of the system that owns the use case is explicitly defined. The level can be the top level business system, the top level of an automated system, automated subsystems, component-to-component communication or even SOA services.

3.      The UML Specification does not give a useful definition of system. It says “A top-level subsystem in a model” which is not very helpful. A system is a subsystem?!?!

We have to go outside of the UML Specification to get a definition that applies to both business and IT. The best I’ve found is “a system is a set or group of elements that exhibit behavior collectively.” Note the emphasis on producing behavior. Without behavior, there is no system!

C.     Using roles is the biggest conceptual change that our methodology introduces. It is hard to know that roles even exist from many of the UML books that are available. However, the concept of role has been in the UML Specification all along.

Here is one excerpt. An actor is a “coherent set of roles ... An actor has one role for each use case with which it communicates.”

However, the concept of role has usually been ignored – with dire consequences.

I am happy that kmatthews mentioned the difference between roles and people in the thread.

An interesting question is, who owns a role? The short answer is there is a one-to-one mapping between a use case and a role. Additionally, the use case owns its role.

Rather than reproduce it here, I refer you to: building-requirements-consensus.com/use-case-basics.html for a detailed discussion of these three fundamental concepts.

This page is followed up with a yearlong case study, called UC Role Case Study, of a financial Transaction Auditing Program that was put into production. It was then changed twice before a third change request was made. At that point, I applied the methodology to find the real requirement.

The root cause of the thinking that led to the initial faulty requirements was using use case actors in the “industry standard” way. The case study shows how and why using roles instead of actors leads to better requirements that result in applications that satisfy, or even delight, your customers.

Sorting Out Levels of Abstraction

Some of this thread could be described as sorting out levels of abstraction, in particular, between use cases and tests. This is usually ambiguous because the multiple system boundaries at various levels of abstraction are not denoted. As a result, use cases that should belong in different systems end up on the same diagram. Visuals are powerful. Wrong visuals lead us to think incorrectly because of what we are seeing. Then we write incorrect use case steps and try to hold it all together.

To make matters worse, in the industry standard approach, the same actor is said to interact with these use cases without ever documenting the roles being played – even though the use cases belong to different systems at different levels of abstraction. Is it any wonder there is confusion on the functionality or the tests needed to validate it?

As a simple example of how the three fundamental ideas of the methodology, namely, use case, system & role, work together, consider an insurance company. It must handle claims:

1.      The processes within the claims department, a business system, that produce decisions about claims, can be described with a Handle Claim use case with the role Claim Handler.

2.      An automated process, an IT system, to verify that a policy with the right coverage was in force on the date of the incident, can be described with a Verify Policy use case with the role Policy Verifier.

3.      A service in a service oriented architecture, a SOA system, that queries a database of policies, can be described in a Query Policy Database use case with the role Policy Database Queryer.

Each use case will have its steps written with a different level of detail. Someone or something playing a Policy Verifier will see more details than someone or something playing a Claim Handler. Tests written for these two use cases will necessarily have different levels of detail.

Typically multiple tests should be created for each individual function a use case describes to cover positive cases, negative cases, random user behavior ;-) and boundary conditions.

The incorrect repeated ideas I mentioned earlier include these two that are mentioned earlier in this thread:

1.      Use cases can have preconditions and postconditions – actually, they cannot

2.      An exception is an alternate path – they are two different kinds of things

Please see the website for detailed discussions of these ideas as they do not fit within the main theme of this comment. However, they are important because writing use cases is simplified when you think about them clearly.

Hopefully, the ideas and definitions presented here will add clarity as we continue to discuss these important topics.