Use case enough ??

[AC]

Hil, I'm currently doing Use cases for a project, and I have a really newbie question; Is the use case (incl. model and "normal flow" text etc) considered the only necessary requirements specification document in RUP or other UML based methods, or is it OK to use other specs formats too?

The issue is important to me, as I need to know whether all functional/business requirements are to be included in the use case or not. If so, I guess I'll have to use quite a lot of "alternate flows" to specify the business requirements as the are very complex....

Best Regards/
AC

[Steve_Straley]

AC,

From a RUP document point of view, IMO, the USE CASE flow (basic, alternative, subs), the pre and post conditions, special conditions, external points are important from various aspects including base-lining customer expectations, test scripts, et cetera.   However, UML, IMO, goes further from a technical perspective in data states, sequencing events, and structures.   This means, to me at least, that both are necessary from a front-loaded perspective (RUP getting stakeholder support, audience acknowledgement and acceptance, and QA) and from a back-loaded perspective (UML getting down to the nitty and gritty of the actual system).

I'm doing a rather finance project here at GE at the moment and there are a lot of "alternative flows" and all need to be documented to drive to a functional requirement doc.

Just my .02.

Steve

[fwoolz]

Hi all,

Another tuppence....

I have done requirements docs using UML use case diagrams in conjunction with text descriptions following templates given in standard IEEE 830.  IMHO, not being a UML expert (yet!), I would lean toward laying out upper level requirements using use case diagrams, followed by detailed "unfolding" of requirements using plain old text.  Perhaps my feelings are slanted by the fact that most systems I work on are embedded systems that are either autonomous or have little interaction with a human user.  Anyway, as I said, it's just MHO... any pointers from the more seasoned UMLers would be greatly appreciated!

Cheers,
Fred Woolsey

[jaimeglz]

Hi ac, Steve, Fred... all,

Another two bits on the topic of use cases and requirements:

One way of viewing a software project (excluding the project management perspective) is to see it from four different points of view:

1. The user's view: This view emphasizes that what the user really sees are the interfaces with the system, such as windows, dialogs, screens...

2. The behaviour view: What behaviour should the system have? For instance, what should the system do in response to certain events.

3. The structural view: What structural elements does the system need to store and handle the necessary objects for the required behavior?

4. The technical architecture view: What platform, OS, communications, database management system... are needed or are the optimal for all of the above?

Each one of these four development tracks has its own set of requirements. So, lets ask the question: Do use cases satisfy all types or requirements? And the answer is "almost, but not quite...". For instance, there could be a formal requirement to reuse as much as possible the existing technical infrastructure of a company; so, if you are using only a use case model, you will need to produce a separate document for this sort of requirements.

On the other hand, does UML have all the necessary artifacts to handle the four development tracks? And the answer is a confident "yes", or it does so to a very high degree.

For instance, we can create a deployment diagram that depicts the existing technical infrastructure, and specify that we need to stick as much as possible to this architecture.

Or take another example: UML also has class diagrams where we can document and specify static business rules (such as what should be the relationship between a budget item and an expense). Can you model these static rules in use cases? Probably... but you will have to really stretch your model and your documentation.

In conclusion: use cases are very good to drive the modeling effort, and are considered best practice for discovering requirements; but they are not a cure-it-all.

Jaime Gonzalez

[fwoolz]

Jaime,

Hear, hear...

Cheers,
Fred Woolsey

[Steve_Straley]

Jaime,

You really ought to take a look at Six Sigma and some of the Tollgate Processes.   These are EXACTLY some of the steps outlined.   This is why I LOVE a blend of Six Sigma, RUP, and UML for a complete process that encompasses all of the "stakeholders" possible.   You can GOOGLE search on Six Sigma and see what I mean.

Steve

Hi ac, Steve, Fred... all,

One way of viewing a software project (excluding the project management perspective) is to see it from four different points of view:

1. The user's view:
2. The behaviour view:
3. The structural view:
4. The technical architecture view:

<et cetera>

Jaime Gonzalez

[jaimeglz]

Steve,

Thnks for the suggestion: I will take a look at Six Sigma (and I've already bookmarked their web page).

I picked up the idea of the user, structure and behavior views (or development tracks) from a schematic diagram that had been produced by Monique Bonaï, from Belgium, for the Unisys TeamDesign process in 1995. I was an instructor for the TeamDesign roll-out effort back then, and met Monique at a Design Scholl held at the Unisys Training Center for Europe at Milton Keynes (and got to admit some of my pupils, including her, knew more than I).

When I saw the poster with the three views, I thought it was really a neat idea: the user interface track leads to the user interface set of deliverables; the behaviour track leads to object behaviour, strored procedures, programs...;  the structure track leads to the data base...

Yourdon had originally defined the information, function and time views, but they didn't even come close to the clarity achieved by this newer, object-oriented, way of seeing things. And Martin and Odell had also stressed the idea of views, but their way of explaning it was a bit complicated.

Later, during an actual project, I added the technical architecture track out of sheer necessity.

Well, I just wanted to give due credit on where I got this idea, so I'll better not keep this too long.

Jaime

[Steve_Straley]

Jaime,

Six Sigma was originally designed by Motorola and is implemented here at GE, Johnson and Johnson, and others.

The one thing I like about Six Sigma is the "measure" aspect of the process.  It asks users to outline CTQ's (Critical to Quality) involved in the analysis and buy-in phases.   The CTQ's are then tallied and averaged to give an "weight" to the functionality expressed.   This gives a nice snapshot to management of what "is absolutely necessary" and what is "nice to have".

There are two problems, IMO, with Six Sigma.  First, it is structed in a waterfall approach through the various TollGate Review processes.   This doesn't fit well to the itterative approach; however, supporting Six Sigma is RUP and UML which helps significantly.

The other problem is more epidemic with MOST corporations.  They "talk" a good game on process but they don't "walk" the talk.   Our CEO once said that he felt customers here don't see the benefits of Six Sigma.   Well, that's probably true when you take a nicely structured process (e.g. a nice firm cube) and you start to whittle down and cut corners and by-pass the processes just to get "it" out (whatever it is).   Eventually, you have a sphere and not a cube and gaping holes in the final prodcut.

I'm putting together for EA-ReqPro a "process" flow that encompasses my interpretations and combinations of Six Sigma, UML, and UP to come with a total view.   Keep in mind that as you read Six Sigma there are probably going to be missing terms (like TollGates, PMM, ePMM, PMMPlus, CTQ's, L1's - L5's, et cetera).  Just hollar if you want clarifications.

Steve