UML - Where does performance go in use cases

[Paul Doherty]

Hi,
I am currently working on writing my use cases based on the requirements for a Java based SDK. There is a requirement stating that the performance of this SDK at runtime should be a certain level. I am not sure exactly how this should(if at all) be represented in a Use Case, or indeed where in my UML this should be put.
Just new to the UML - and havent seen this in any examples to date. Hope someone can help.
Regards,
Paul.

[Reid M. Pinchback]

I guess I would argue that use cases are not quite the same as requirements management. Use cases are useful (sic) for uncovering requirements and major system interactions. Specifying performance expectations is a good thing, but I'd have to wonder if you could place them effectively in a use case. At best, they'd have to be indications of the performance expectations of the user (i.e. gui responsiveness on a task). I don't see them as a way of indicating things like server load/utilization metrics.
Maybe this comes down to distinguishing functionality from constraints in your requirements. Use cases I don't think present constraint information very effectively. I think you need a requirements doc, apart from the use cases, to capture that information.

[Ilja Preuss]

I agree with Reid.
Notice also that UML Use Case Diagrams and Use Cases are *not* the same. Use Cases are typically in text form, whereas Use Case Diagrams are only a simplified representation of the collection of Use Cases.

[C Wong]

Larman suggests that performance constraints be defined in "Supplementary Specification". 2ed p88

[Reid M. Pinchback]

Originally posted by Ilja Preuss:
I agree with Reid.
Use Cases are typically in text form, whereas Use Case Diagrams are only a simplified representation of the collection of Use Cases.

Also, some writers emphasize the distinction between a use case, as Ilja has described, and a use case scenario. The former is a higher-level abstract description of the interaction. The latter is a specific situation, preferably grounded in a real-world example.
The reason for making the distinction is important. You hope that the high-level abstraction captures the issues, but sometimes it doesn't. People can make unwarranted assumptions if they don't periodically use a real problem to ground the requirements capture. Scenarios are viewed as being a more robust way of keeping you in touch with the real facts. After you get some scenarios you step back and try to create a reasonable abstraction in the use case.
It might be that performance issues could have been raised in discussions with an end-user during scenario capture. A high-level use case discussion (probably with a supervisor instead of the real do-er of a task) may never reveal the constraint.

[Anjana Rao]

Hi,
If one follows Rational's Approach, then we can say that the interactions of the system with the external enviornemnt is represented by use cases. So we can say the functional requirements of the system under considerations are captured by virtue of use case diagrams, and the non functional requirements of the system under consideration shud be put into a document called Supplementary Specifications. So at the end of the requirement analysis stage, what one has is a use case model which comprises of use cases, supplementary specifications and glossary.
I hope this piece of info helps u in some regards. You can put ur performance requirement in ur supplementary specification document.