Forums for the Business Analyst

  Modern Analyst Forums  Business and Sy...  General  Use case verification required
Previous Previous
Next Next
New Post 12/12/2013 9:25 PM
User is offline prasad
3 posts
No Ranking

Use case verification required 

 Hi Guys,

I am new to use case. I have created use case for automation of confirmation appraisal process. Can you please let me know if I have made any mistakes? or any suggestions related to it ?

Please check the use case here :

** Please note that the trigger point for the below flow is when people-mine system sends intimation mail to employee.

5.a Basic Flow


1.    The use case begins when employee receives e-mail with the link to appraisal form & intimating that the self- appraisal process has started & hence employee should complete the appraisal.

2.    Employee logs into People-Mine system by clicking on the link in the mail.

3.    Employee fill the appraisal

4.    Employee submits the filled appraisal

5.    Appropriate message will be shown to employee

6.    Manager will receive intimation mail once the employee submits appraisal

7.    Manager logs into People-Mine system.

8.    Manager reviews the filled appraisal.

9.    Manager approves the appraisal & decides confirmation status

10. Appropriate message will be shown to manager

11. Manager submits the appraisal.

12. HRBP updates the database accordingly.

13. The use case ends successfully.



5.b Alternate Flow




Manager disapproves the employee filled appraisal form:


If in step 9 of basic flow, manager disapproves the appraisal then-:


1.    Employee receives email stating that the appraisal is been rejected by manager and needs to be re-submitted.

2.    Employee logs into People-Mine system by clicking on the link in the mail.

3.    Employee edits the already filled appraisal & re-submits.

Next steps should start from step no.5 of basic flow.



New Post 12/17/2013 3:24 AM
User is offline Kimbo
453 posts
5th Level Poster

Re: Use case verification required 
Modified By Kimbo  on 12/17/2013 5:27:30 AM)

Hi Prasad,

Seeing you asked for help I'll be blunt with the response.

There are some fundamental errors in your use case. Most glaring ones are:

1. Your use case assumes a solution. Use cases should be solution agnostic

2. A use case describes a conversation between one actor (you have at least 3) and the system. Generally written as action by the actor / response by the system continuously alternating.

3. Line 1 is your trigger or pre-condition which is not part of the Basic Flow.

4. Use cases are actions taken by an actor to achieve a goal that is of value to the actor. What is the goal here? I can't see one clear goal. Looks to me like there are many goals for each actor.

5. etc...

As a basic suggestion, think of a use case as something one actor will do in one sitting e.g. enter an invoice; write an email.

Lastly, I think this would be better described as a business process diagram with swimlanes for your actors e.g. employee, manager - I use BPMN for this. NOTE: the system you are defining is never an actor in your model!! Then each activity in your diagram can be described in a use case.

Omit solution from your business process otherwise you'll continue to have trouble.

Good luck


New Post 12/18/2013 7:35 AM
User is offline prasad
3 posts
No Ranking

Re: Use case verification required 
Modified By Chris Adams  on 12/18/2013 10:46:21 PM)

Thanks Kimbo.. Your review would help a lot.. 

I have still some questions.

1st Q:

I have seen many uses cases with multiple actors.  

( For example consider following use case:

But as per you, use case should have only 1 actor. So, I am a bit confused. 


2nd Q:

So, according to you, shall I have to prepare different use case for different actors?  


3rd Q:

For the basic flow & alternate flow I have mentioned above, use case won't be the solution?  Shall I omit use case completely ???



New Post 12/21/2013 11:50 PM
User is offline Kimbo
453 posts
5th Level Poster

Re: Use case verification required 

 Hi Prasad,

1st Question: the use case diagram in your link breaks UML conventions. It is actually a poor example of a use case diagram. There are no arrows on lines on a use case diagram. The use cases Maintain ATM and Audit have no triggering actor. I should qualify what I said about one actor per use case. There is one actor that triggers actions on the use case. Other actors can be involved e.g. they receive a notification as a result of some action undertaken by the triggering actor. the convention is that triggering actors are on the left and associated actors are on the right. This use case diagram breaks that convention too. "Audit" is a poor name for a use case and a very lazy way of saying things are audited. The convention for a use case name is verb name e.g. "maintain ATM".

Whoever did this diagram does not understand UML or use cases and is a poor practitioner of business analysis. 

2nd Q: yes prepare different use cases for each actor

3rd Q: In my opinion you are best describing this as a business process diagram. Not a use case. The activities you describe occur over a period of time involving multiple actors.  Something like "enter appraisal" is a use case for you to describe - it is part of the business process and something the actor will do "in one sitting".


New Post 12/30/2013 10:15 AM
User is offline fred
13 posts
10th Level Poster

Re: Use case verification required 

 What you haver written is a business process with technology assumptions. There are possibly several use caes here, filling in and approving the appraisal are two of them if you want to look at it that way, The bigger question is what is the goal here? A use case is an atomic set of functionality that delivers a specific value to the actor. When you can state you have met that definition then you have a use case. You should probably step back and look at your functional requirements to determine the use cases.

Previous Previous
Next Next
  Modern Analyst Forums  Business and Sy...  General  Use case verification required

Community Blog - Latest Posts

Is Agile a reason to avoid documentation? I bet this question shows up again and again while working with product requirements. On one side, we have got long specifications, complicated diagrams, mystical technical design, too many prototypes and pretty obvious for engineers user guides (do we really need so much?). On the other side, can we actual...
The cloud-native application development has helped enterprises all around the globe reduce time-to-market, enhance performance, and develop agility and flexibility. Several enterprises are achieving these results by migrating their systems or traditional monolithic applications to the cloud. But to gain from the real benefits of cloud technology, ...
So you’ve found the perfect time and place to study and you’re ready to finally get some work done. You’ve pulled out your laptop, your textbook, and your notes, and four different highlighters. After five minutes of reading your textbook, you start zoning out and thinking about puppies. Then, you go on Tumblr and look at cut...


Upcoming Live Webinars


Copyright 2006-2021 by Modern Analyst Media LLC