One Use Case Diagram in Wikipedia prompted me to prepare and upload this. Many seasoned professionals also fall into these errors and do not know what is wrong. The examples, explanation, correction and citation of more detailed pdfs should help detection of errors and enable corrections. One need not make these errors at all.

1. Putcha V. Narasimham
Knowledge Enabler Systems Founder Professor & Proprietor
Temporary Address: 1924, Hillman Av, Belmont CA
kenablersys@yahoo.com or putchavn@yahoo.com
5 Typical Errors & Corrections in Use Case Modeling Page No 1 of 3
The Best Anywhere Must Reach the Needy Everywhere
TypicalErrorandCorrectionsinUseCaseModeling
Our Ref: See Footer
Date: 16 JUL 13
Being competent, effective and efficient is
90% mindset and 10% toolset.
---Roger Tregear
Typical Errors
& Corrections
in Use Case Modeling
This is an example given in wikipedia
http://en.wikipedia.org/wiki/File:Use_case_restaurant_model.svg
Without being very critical of the author (I do not know who it is), I wish to
point out typical errors in Use Case Modeling and present corrections.

2. Putcha V. Narasimham
Knowledge Enabler Systems Founder Professor & Proprietor
Temporary Address: 1924, Hillman Av, Belmont CA
kenablersys@yahoo.com or putchavn@yahoo.com
5 Typical Errors & Corrections in Use Case Modeling Page No 2 of 3
The Best Anywhere Must Reach the Needy Everywhere
TypicalErrorandCorrectionsinUseCaseModeling
Srl
No
Error Correction
1 System Boundary is
NOT named.
There is NO need to say
the rectangle is “System
Boundary”. UML graphic
conventions make it clear
anyway.
Specific system name should be given.
There may be many systems involved in
analysis and design. The “system” is
always the System Under Development
SuD in a U C Diagram.
Well named SuD helps knowing what is
within and external to the SuD
2 What is SuD here?
SuD is NOT named. No
notes on what is external
to it and what is within.
Name of SuD and notes are essential
contents of Use Case Diagram.
Tabular form of U C Diagram is more
expressive & comprehensive. See
http://www.slideshare.net/putchavn/5-use-
case-table-with-actors-goals-08-sep12
3 If Waiter, Chef, and
Cashier are external
to SuD, what is SUD?
Another manifestation of error 1 and 2.
If SuD is “Restaurant Management
Software”, it should be so named and
explained.
4 Premature detailing
through “extents” and
“guard conditions”
No need to show “extends and guard
conditions” in a U C Diagram. Those
details will not be missed.
It is much simpler and safer to combine
“food and beverages” and eliminate
redundant graphics and text.

3. Putcha V. Narasimham
Knowledge Enabler Systems Founder Professor & Proprietor
Temporary Address: 1924, Hillman Av, Belmont CA
kenablersys@yahoo.com or putchavn@yahoo.com
5 Typical Errors & Corrections in Use Case Modeling Page No 3 of 3
The Best Anywhere Must Reach the Needy Everywhere
TypicalErrorandCorrectionsinUseCaseModeling
Srl
No
Error Correction
5 Association line
segments are wrongly
and inconsistently
labeled as “actions” or
“messages” or “data-
flows”.
The line segments connecting Actors and
Use Case Ovals are “ASSOCIATIONS”.
They are never named or labeled in a UML
Use Case Diagram. That is much simpler
and safer.
6 Non Use Cases are
shown as Use Cases—
Order Food, Serve
Food, Eat Food, Pay
for Food, Cook Food.
They are NOT Use
Cases of whatever is
the unnamed SuD.
The primary error is 1 & 2. This is
another manifestation. So, 1 and 2 are
very serious.
All the UC names given are actually the
actions of Actors, NOT Services provided
by SuD to the Actors.
If there is a computer software enabling
the restaurant management, it should be
stated clearly. Ask for sample Case Study
from kenablersys@yahoo.com
7 Multiple Actors
Associated with the
same UC
This is a very serious error. Many
seasoned professionals also make this
mistake and argue about it. See
http://www.slideshare.net/putchavn/one-use-
case-one-actor
http://www.slideshare.net/putchavn/use-
casesingle-session
Cordially,
Putcha V. Narasimham
---III---