The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

UI prototyping VS. Use Case Modeling


I'm involved in a big defense software project. The
project team is composed from system analysts doing
the UI and requirements work, software developers
doing the architecture/design/implementation work and
a testing team.

Early on in the project it was decided (not by me) to use
the full blown RUP (rational unified process) methodology
to develop the software.

As you may already know - in RUP you do most of the
functional requirements work in the form of Use cases which
are exhausting narratives describing user/system interactions.

UI prototyping was considered just another document
required by the client (not something we REALLY need
to develop the system...) although the software is
highly graphical.

The current situation (which I'm trying to change) is that
system analysts keep writing every conceivable functional
behavior right into the use-case model in an effort to
nail down everything and almost no effort is spent on
using the prototype and UI people to validate things or
to elicit new ideas.

The general "wisdom" seems to be
that UI people's job is only to provide an elegant
UI "translation" to the lengthy (sometimes 30 pages long of
boring) use-case documents (written without their participation of course...)

I feel that we are using a tremendously inefficient
process to write the functional specs of the system!

If it was up to me - we would have written very shallow
use-case documents (just enough to begin prototyping
work) and do the rest on the prototype itself. This
approach would result in far less paperwork than there
is today and a much faster development process.

What's your opinion on the subject ?

frustrated system analyst
Friday, September 03, 2004
 
 
Although it sounds perfectly terrible, I don't put much stock in prototypes, either:

http://www.joelonsoftware.com/news/20030516.html

Paper prototypes are the way to go.

But to address your situation... it sounds like you're in a situation where things are done a certain way "because." Because they always have been done that way; because someone decided they would be done that way; because nobody knows any other way; because they read a book by Booch and went nuts. The only thing they're NOT doing is thinking about why they're doing what they're doing.

What can be done? It depends on your position. If you're well respected in that group and it's not highly political, you can get things done by advocating them. In a political organization or one in which you're less senior or have less clout, the more you suggest change, the more frustrated you'll get!

Getting things done when you're only a grunt:
http://www.joelonsoftware.com/articles/fog0000000332.html
Joel Spolsky Send private email
Friday, September 03, 2004
 
 
If it is GUI software, I fail to see how UI prototyping or layout specs could be less than essential.  Use cases capture activities through time, they do not capture layout through space.  Some good ideas and some bad ideas will leap out from a layout spec, but be totally hidden within a use case.  Also, use cases are very good at nailing down the tiniest details of how a system behaves ... in such a way that anyone who reads them carefully will end up in a coma.  These are some of the reasons I always push for both types of docs.
profound insights galore
Friday, September 03, 2004
 
 
The rule goes:

If you can prototype the UI, you can make it work.

Its far better to make it work at the same time as you design it, you don't fall into the trap of 'it looks good, lets do it' and you find out early on that its a bad idea.

This doesn't mean you can't use RUP.  As soon as a Use Case is sufficiently complete to describe the UI build it, along with whatever connected Use Cases upstream and downstream are also complete.

Not everything has to be complete before you start developing, but its the single most common fault in RUP or Code Complete driven projects to wait and wait, to model and model.

This is even more prevalent in large scale government on pseudo-government systems because no one wants to get to an implementation stage and have egg on their face.

However, its a truism that no matter what the methodology there is always egg and there are always faces for it to land on.  The trick is to break the eggs as soon as possible so you can make omelettes.
Simon Lucy Send private email
Friday, September 03, 2004
 
 
Amusingly enough, I also work for a company that deals with defence contracts. Our approach is to start with use-cases to get the initial high-level detailing on paper and then to proceed with prototyping the UI. Even though a dialog/screen may contain the exact requirements of the customer, it will quite often not fit in with the rest of the application.

For instance, a common problem we encounter is that a typical screen will completely encapsulate the requirements spelled out in a use-case, yet will take up far too much visual real-estate. The easiest way to relay this issue to the customer is through a screenshot, removing all ambiguity. This also puts the onus on the customer to provide a solution that is best for their company.

In my experience, this also builds confidence that tangible work is also being performed and that the company is not spending 100% of the time planning themselves behind schedule.
Mark Hiscocks Send private email
Friday, September 03, 2004
 
 
You're not going to believe this but my company has developed a specifications design tool that's easy to use, elegant yet extremely effective.  We recently accomplished two pilots;  one used narrative specs, the second Use Cases.  In both instances we identified a number of issues.  What's interesting is that in both of the pilots we ran, the software had already been written and is in production.  So it was in production with errors. These were pilots thus the reason the code had already been written.  Our tool works seamlessly with whatever specification creation process you use now. The tool is Web based and free form.  That is to say, you can incorporate the language of the user.  We recently patented the software and the issue we're encountering is that no one can believe there is a way to create specifications other then traditional (narrative, flow charts, Venn diagrams, Use Cases).  Once people see it, they're astounded.  We can create our specifications at as high a level you want or the most granular level.  Think of a Blueprint of a house.  At first glance it's just a bunch of lines with attributes.  However, if I take you through the front door, through the vestibule, take a left and into the dining area.  There are two windows.  But you want a bay window.  We can make the change right away because I've just brought you through a specific logic path.  Since we're on the Web, we can accomplish the change interactively.  In any case, if you're interested in an easy and extremely effective way to do specs that everyone can understand, are maintainable and tie directly to your QA test plans, please contact me.
walter o'neil Send private email
Friday, September 03, 2004
 
 
Yea, sounds like they're over doing it. You must work for a large company with deep pockets. Not much you can do unless your an exec.

Unfortunately, if you really dislike it, take your time and find another job.
sl
Friday, September 03, 2004
 
 
I should have added, in all fairness, that if you work for a company like a defense contractor (mentioned above), you *must* endure a more strict process.

Furthermore, RUP can produce nice results if properly used.

But overall, it's usually the company culture that's the driver for these things and unless your the CEO, it won't change.
sl
Saturday, September 04, 2004
 
 
I'm not a big fan of RUP in general. And what the OP describes happens all too often when use cases are written by a small group of people who consider themselves the Final Authority On Everything Related To The Design. Usually this type of analyst doesn't know how to write requirements so they try to describe the system in other ways (narrative, use case, whatever).

As others suggested, prototype the UI as fast as you can grind through the use case verbage, and deal with the reality of defense contracting being so process heavy it will be years before you actually write the code.
Tom H
Sunday, September 05, 2004
 
 
"As you may already know - in RUP you do most of the
functional requirements work in the form of Use cases which
are exhausting narratives describing user/system interactions."

When your use cases are always exhausting, you are doing something wrong, e.g. too many details in the beginning. I recommend the book "writing effective use cases" by Alistair Cockburn. The whole book about getting text-bases uses cases right.
Thomas Wiesemann Send private email
Sunday, September 05, 2004
 
 
Use Case Modeling does not precules UI work.

See writing effective use cases by Alistair Cockburn.

He says "only a fraction of the entire requirements set is behavioral, suited to the use case form. The other portion (including Perf, UI, Data formats, I/O formats & protocols, business rules) must be written using other forms. It just happens that the behavioral part is central, and connects many other requirements".

So, "analysis" not carrying out UI work do not do their specification writing job properly.
RedFox
Sunday, September 05, 2004
 
 
I for one really do think having both detailled use cases and UI mockups is really nice.

Having only the UI shots is too likely to be wrongly interpreted by some people (mainly users) who deduce a functionality from the way the UI is designed that is not what is going to be implemented.

Detailled use cases are quite harder to misunderstand, at least if they have been written well.

By the way, I have trouble seeing how very detailled functionnal specs can be a hassle to a programmer ... as far as the projects I've worked on are concerned my trouble has always been getting too little info from stakeholders, never too much.
Renaud Martinon Send private email
Tuesday, September 07, 2004
 
 
See "How to Fail with the Rational Unified Process - Seven Steps to Pain and Suffering" by Craig Larman:

http://www.aanpo.org/articles/articles/How_to_Fail_with_the_RUP_-_Kruchten_and_Larman.pdf
Oran
Tuesday, September 07, 2004
 
 
Defense/Defence projects have lost their charm for me, but I do know that they are specification intensive.

But my comment relates to the fact that this is not a monolithic customer - in the U.S. the Air Force has a different set of best practices than the Army and the Navy.

In the last USAF defense project that I worked (quite a while now) on the presentation layer was built FIRST. The back end was then built to make it work and compromises were made along the way. But, I repeat, the presentation layer was built FIRST.

So, there are precedents out there if you can find them and champion them.
JB Skidder
Thursday, September 09, 2004
 
 
This is exactly the problem Extreme Programming was meant to solve.

In principle, it's a good thing to have use cases separate from mock ups.  It enforces a separation between the "what" and the "how".  The upside for you is it gives you, as the developer, a lot of freedom in how to implement the system to meet the use case goals.

The problem is that this is not combined with an iterative process.  When the users see the product, they WILL think of things they didn't think of during the requirements phase, say that you misinterpreted what the use cases said, etc.  Having rapid iterations solves this, as you get this feedback early in the process and can react to it.

Unfortunately, it seems it will be difficult to change your situation :(.
Jim Rankin Send private email
Monday, September 20, 2004
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz