This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Use Case Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Use Case" Watch "Use Case" New topic
Author

Use Case

Fisher Daniel
Ranch Hand

Joined: Sep 14, 2001
Posts: 582
Dear all,
Is it true that Use Case is ideal to capture non-functional requirements (scalability, maintainability, etc ) ?
thanks
daniel
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
IMO, the best way to "capture" those requirements is in automated tests.
Automated tests do have three big advantages over use cases:
- they force you to formulate the requirements in a measurable way
- they are unambiguous: they either pass or fail and you can look into the code to know why
- if you run them often, you always know wether the system complies to the requirement
Of course, until you decided to implement the requirement, you might want to write it down as a planning token, for example. How formal that writing needs to be will heavily depend on the communication culture of your team - for some, even a couple of words scribbled on an index card might suffice.
[ November 18, 2002: Message edited by: Ilja Preuss ]

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Yogesh Deshpande
Greenhorn

Joined: May 15, 2002
Posts: 19
Originally posted by Fisher Daniel:
Dear all,
Is it true that Use Case is ideal to capture non-functional requirements (scalability, maintainability, etc ) ?
thanks
daniel

Daniel,
What I understand from Use case philosophy is Use cases are meant for capturing the exact user requirements from business per se.
Use cases should cover following (You might be knowing all of these but in case..):
1.Exact business requirement e.g Validate user
2.Various actors such as system user,business actors et al.
2.Basic flow of execution
3.Alternative path of execution incase of any errors
4.User action and system response for the system under construction.
5.Any other details which will make the particular business requirement more clearer.
Scalability,maintanability et al are non functional requirments as said right by you and I suppose they will be dealt in Architecture consideration phase.
I hope this makes sense.
Cheers
Yogesh
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Yogesh Deshpande:
What I understand from Use case philosophy is Use cases are meant for capturing the exact user requirements from business per se.

Yogesh, with all due respect, I think you are on a very slippery slope here.
First, it's neither desirable nor possible to get "all the exact user requirements" of a system up front.
It's not desirable, because you *don't need* all that exactness at the beginning of the project. At this stage, use cases are merely more than a planning token for a rough release plan. Only later will you need more details for a more detailed (iteration) plan and finally all the details for implementing the feature.
It's not possible, because the details will change while the business environment changes and customers/users/analysts develop their understanding of the system when working with early releases.
Second, depending on the communication culture of your team, not all the details need to be written down on paper. Especially for small teams with tight collaboration with the customer, oral communication might be much more effective.
Therefore, depending on the circumstances, the detailness of a Use Case might vary heavily. See also http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison (especially the comments by A. Cockburn and Kent Beck).

Scalability,maintanability et al are non functional requirments as said right by you and I suppose they will be dealt in Architecture consideration phase.

Netherless, those requirements somehow need to be communicated. If you think you need to write them down, I wouldn't mind wether I called them "Use Cases", "Meta Stories" or something else...
Yogesh Deshpande
Greenhorn

Joined: May 15, 2002
Posts: 19
Originally posted by Ilja Preuss:

Netherless, those requirements somehow need to be communicated. If you think you need to write them down, I wouldn't mind wether I called them "Use Cases", "Meta Stories" or something else...

Ilja,
I appreciate your comments.Thanks for the link.
When I say exact user requirements I am pointing for a fact that there should be a minimum gap as far as the customer requirements are concerned.I am very well aware that requirements under go changes based on many factors.
Also I am very well aware and faced that its not possible to get the exact user requirements unless and until its a migration project(from exisiting system).
I suppose the question was not pointing to your comments.
My arguement is Use cases is not best possible UML artefact to capture or note the non functional requirements mentioned above.
I suppose these non functional requirements should be communicated in technical architecture document which should be a part of scope of the project.
Oral communication is real software development project does not carry any meaning.If u r working or following any SEI CMM level 5 certifications rules then every artefact should be documented,approved and stored.So oral communication is not a very reliable way of collecting requirements.
All the approach depends upon the type,size and complexity of undertaking OO project.
Cheers
Yogesh
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Yogesh Deshpande:
When I say exact user requirements I am pointing for a fact that there should be a minimum gap as far as the customer requirements are concerned.

And this exactly what I am objecting to!
In my not so humble opinion, you should stop gathering information about requirements as soon as you know enough to take the next step. You don't need all the information to make a rough development plan, so continuing to work on detailed use cases in that phase would not only be investing in things that possibly will change later anyway, but also delaying the next, much more important step! You can continue to "close the gap" later without problems, when you *really* need to, after all. And you don't necessarily need to do that using Use Cases.

My arguement is Use cases is not best possible UML artefact to capture or note the non functional requirements mentioned above.

Sorry, I have to correct you here: Use Cases *are not* an UML artefact. They are a (more or less formal) textual description of user requirements. Use Case *Diagrams* (which are part of UML) are nothing more than a rough graphical overview of the actual Use Cases.

I suppose these non functional requirements should be communicated in technical architecture document which should be a part of scope of the project.

Well, those requirements probably need to be considered in such a technical document. But I think a technical document is far from ideal for communicating requirements between the customer and developer side. After all, we need to somehow remember those requirements even before we started to think about the architecture...

Oral communication is real software development project does not carry any meaning.

My experience is quite contrary - oral (face to face) communication is the most effective communication channel available. And there are many teams out there using that to their advantage.
A. Cockburns book "Agile Software Development" has a very good chapter about this...

If u r working or following any SEI CMM level 5 certifications rules then every artefact should be documented,approved and stored.So oral communication is not a very reliable way of collecting requirements.

I don't follow your reasoning. Just because CMM requires you to produce tons of paper work doesn't mean that there aren't any other ways of getting the same (or even better) reliability. AFAIK, CMM is mainly targeted at *repeatability*, and I would strongly suggest that there might be more effective ways to get reliability than that...

All the approach depends upon the type,size and complexity of undertaking OO project.

Certainly, yes! And there are *many* projects out there of the size a team of a dozen developers could handle. Experiences of agile teams seem to suggest that most of those projects could be run without much more written down than code.
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
I suppose these non functional requirements should be communicated in technical architecture document which should be a part of scope of the project.
In my opinion there should be no such thing as a "non functional requirement". Use of the term is a common sign that a problem has not been analysed properly, and a big indication of why so many projects go over time and over budget.
In my experience, the phrase "non functional" is always used to imply "non testable". If something can not be tested it can only be a "goal", not be a "requirement". If you allow non-testable requirements, you can never really know if/when the product is completed. In the limiting case, if there is no acceptance test for something, then there is no point writing the code for it.
I think Ilja had essentially assumed this axiom, and gone on to discuss approaches to making traditionally "non functional" requirements testable, and thus implementable.
Oral communication is real software development project does not carry any meaning.
You must be working in a very different environment from me, then. Do you never speak to your colleagues about work at all? Do you never have meetings where you talk through requirements, designs or fault issues? Do you never ask questions or make casual suggestions?
In my experience, oral communication carries all the subtle meaning, and the written documents often simply document a pale imitation of the information the oral discussions contained.
If u r working or following any SEI CMM level 5 certifications rules then every artefact should be documented,approved and stored.So oral communication is not a very reliable way of collecting requirements.
I think we need a distinction here. I would be willing to agree that oral communication is not a good way of storing requirements. I'm not sure UML diagrams are a lot better, though.
I still find it astonishing to think that any working analyst might refuse to talk to customers, users or developers, and require all communication to be written down. Gathering requirements is all about people - how they work and what they need. In the general case this is bound to have an oral component, as well as written. And probably also drawings, hand and face gestures and so on.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Yogesh Deshpande
Greenhorn

Joined: May 15, 2002
Posts: 19
Originally posted by Ilja Preuss:

Certainly, yes! And there are *many* projects out there of the size a team of a dozen developers could handle. Experiences of agile teams seem to suggest that most of those projects could be run without much more written down than code.

Ilja/Frank,
Guys thanks for comments.I suppose this is unending debate.At the moment I will take all good points raised by you guys.
These requirements are called as Non functional requirements only as far OOAD goes..anyways..
I suppose you are misinterpretting my point in gathering requirements.
I am not against of oral communication between the customer or team,my point of view is it is risky to take only these communications as a standard in going ahead with the requirements.
Anyways...I got all your points.Once again thanks!
All the best!
Cheers
Yogesh
Michael Zalewski
Ranch Hand

Joined: Apr 23, 2002
Posts: 168
I wonder what you mean by 'non-functional requirement'?
In my experience, it means any requirement that is not directly visible to the end-user or describable as a function of the system. For example, my favorite is 'The database will be normalized'. Other examples could be 'All .java source file will have complete JavaDoc comments'. 'The system will be deployed on an Oracle 8i database'. 'The design of the system will accomodate 1,000 simultaneous users (even though our first roll-out will need to support only 100 simutaneous users)'.
In my opinion, you *can* test these kinds of requirements. But the results of your test will not be a simple PASS/FAIL. For example, almost any non-trivial database design could be criticized as being non-normalized. Even if you alter the requirement to state that 'All tables will be normalized, and then de-normalized only where necessary to optimize queries and response time', two designers can have different opinions. However, two designers can reach a concensus, and agree that the database is 'adequately normalized'. My point is that you probably cannot really say that a database is 'properly normalized', because different people will disagree on what is 'proper'. But you should be able to reach a concensus, or perhaps a majority vote among the designers.
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
For example, my favorite is 'The database will be normalized'. Other examples could be 'All .java source file will have complete JavaDoc comments'. 'The system will be deployed on an Oracle 8i database'. 'The design of the system will accomodate 1,000 simultaneous users (even though our first roll-out will need to support only 100 simutaneous users)'.
These are indeed the sorts of things people have tried to pass off as "non functional requirements", including even vaguer attempts like "the system will be robust, maintainable, and scaleable".
In my opinion, you *can* test these kinds of requirements. But the results of your test will not be a simple PASS/FAIL.
I don't want to sound harsh here, but if the result is not a pass/fail, it's not a test. At best it might be a measurement, at worst it's just an opinion.
For example, almost any non-trivial database design could be criticized as being non-normalized.
This "requirement is really just as vague as "the system must be robust". It doesn't even give a hint as to which normal forms are acceptable. One developer might assume this means third normal form, another might assume fourth or fifth is OK.
Even if you alter the requirement to state that 'All tables will be normalized, and then de-normalized only where necessary to optimize queries and response time', two designers can have different opinions.
Which, to restate my point, is why this is not a testable requirement.
I try and get my customers to agree such desires as "goals" rather than requirements. That way they can still be useful in subjective assessments of quality (eg. release 5 is better than release four because we think the database is more normalised, and more methods have up-to-date javadoc), but can't be used to confirm or deny that the software is acceptable for release.
Now, imagine these requirements were stated as "the database schema must have a Hergenflurt weighted normalization index greter than 0.8". or "running the Bambleweeny javadoc analyser over the final source code must give a result of 'green'". These would be testable. But I'm still not sure they are useful.
Imagine what a real paying customer might say if you gave them a tough choice: "we have completed and tested 16/20 "requirements" for this release, but we only have enough manpower for two more before the system deployment on Tuesday. You have to decide whether to postpone the 2003 tax rules, the change to the corporate logo, the database normalization index calculation or the updating of the javadoc"
To me, the benefit of treating such intangibles as "goals" rather than requirements, is that it allows developers to concentrate on meeting the real user needs using the most appropriate design. As a side effect, it also encourages analysts to formulate their output in a testable form, and facilitates real user dialog ("so what is the maximum acceptable response time for posting a new record at peak load?") and decision making.
Wilfried LAURENT
Ranch Hand

Joined: Jul 13, 2001
Posts: 269
Franck,
When talking about communication, I like very much the graph in Alistair Cockburns (I have a keyboard shortcut on his name ) articleon the effectiveness of the communication modes

W.
[ November 26, 2002: Message edited by: Wilfried LAURENT ]
[ November 26, 2002: Message edited by: Wilfried LAURENT ]
Wilfried LAURENT
Ranch Hand

Joined: Jul 13, 2001
Posts: 269
Daniel,
You wrote
Is it true that Use Case is ideal to capture non-functional requirements (scalability, maintainability, etc ) ?

I quote Alistair Cockburn from his book "Writing effective use cases":
Use cases are typically offered as a way to capture and model known functional requirements.
W.
Wilfried LAURENT
Ranch Hand

Joined: Jul 13, 2001
Posts: 269
Ilja,
You wrote

My experience is quite contrary - oral (face to face) communication is the most effective communication channel available. And there are many teams out there using that to their advantage.
A. Cockburns book "Agile Software Development" has a very good chapter about this...

The same A.Cockburn also wrote :
"Common sense tells us that oral tradition is
insufficient."
W.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Wilfried LAURENT:
The same A.Cockburn also wrote :
"Common sense tells us that oral tradition is
insufficient."

That seems to tell us that common sense is insufficient, doesn't it?
BTW, when and where did he write that, and in which context?
Wilfried LAURENT
Ranch Hand

Joined: Jul 13, 2001
Posts: 269
Ilja wrote
BTW, when and where did he write that, and in which context?

It is in his book "Agile software development ". I can't tell you the ref. in the hard-copy but it can be found in the avalaible pdf draft version #3. Chapter 5. P.147, 2nd � under the caption "Light but sufficent".
W.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Wilfried LAURENT:
It is in his book "Agile software development ". I can't tell you the ref. in the hard-copy but it can be found in the avalaible pdf draft version #3. Chapter 5. P.147, 2nd � under the caption "Light but sufficent".

Oh, ok - found it (p. 175). Interestingly, all the examples he cites in that chapter seem to be situations in which oral communication was insufficient because oral communication was impossible.
He also writes a few paragraphs later: "The correct amount of documentation is exactly that needed for the receiver to make her next move in the game. Any effort to make the models complete, correct, and current past that point is a waste of money."
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Use Case
 
Similar Threads
Starting Oracle services through java
Requirements clarification
how to instantiate anonymous inner class?
constructor question
How to depict a use case in UML in sequence diagram