1

I have a scenario for which I have to design a use case diagram, activity diagram and a class diagram:

“I run a small computer consultancy firm with a number of employees. Along with the basic information about the employees (name, DoB, contact details, etc.) I need to be able to keep track of what type of role they perform, such as Hardware Technician, Programmer, and Software Installer. A single employee can perform multiple roles, and each role has an associated hourly pay. I need to keep name and contact details of all customers that have a contract with us. A customer can have multiple contracts at the same time, but each contract is only associated with one customer. Each contract has a name, a description, a creation date, and a job type – e.g. System Development, Software Upgrade. No details of job types need to be captured other than their name. Each contract also has a single employee designated as the project leader. One employee may be the project leader of multiple contracts.”

I have tried to draw a use case diagram and I want to know if I have drawn it correct and if there are any mistakes or any improvements that should be made:

My Use-Case Diagram

Christophe
  • 68,716
  • 7
  • 72
  • 138
Ruvindra Yohan
  • 67
  • 1
  • 10
  • In general this type of questions does not really fit the SO scope and it should be closed (I'm not voting yet). Let me just give you a hint though. Don't try to squeeze all the information into the UC diagram. Think what are functions of the underlying system. Who interacts with the system? What actions can a user do? From your list of UCs I would probably keep something like 3 in total, 2 of them with names changed. – Ister Mar 26 '19 at 08:32

1 Answers1

0

Let's analyse your requirements, to identify use cases:

  • Manage employee

    I run a small computer consultancy firm with a number of employees. Along with the basic information about the employees (name, DoB, contact details, etc.) I need to be able to keep track of what type of role they perform, such as Hardware Technician, Programmer, and Software Installer. A single employee can perform multiple roles, and each role has an associated hourly pay.

  • Manage customer data (may be included in contract management)

    I need to keep name and contact details of all customers that have a contract with us.

  • Manage contracts

    A customer can have multiple contracts at the same time, but each contract is only associated with one customer. Each contract has a name, a description, a creation date, and a job type – e.g. System Development, Software Upgrade. No details of job types need to be captured other than their name.

  • Assign project leaders (may be included in contract management)

    Each contract also has a single employee designated as the project leader. One employee may be the project leader of multiple contracts.”

Now, more use case may be hidden behind these sentence and could be deduced. However, let's see critically if the additional ones you've identified fit.

The following seem ok at first sight:

  • Make contract (more precise than manage contract. On the other hand, what with contract modification and termination?)
  • Give contact details (par of manage contract)
  • Keep customer details (similar to manage customer data) but who 'd be the owner ?
  • Assign a project leader (see above)
  • Assign other members (excellent: not explicitly mentioned , but if employees are assigned to roles and hourly pay, it's certainly because it's relevant to assign them to projects)
  • Assign employees to project (see previous bullets)

The following use case are questionable:

  • Accept contract: will the owner of the contract (who is it: the customer ? the leader ? s.O. else ?) really accept it IN THE SYSTEM ?
  • Perform role: is it implied here, that the employees will use the system to perform their role ? Or will they just register some time for the projects ? Or will they not interact with the system at all ?
  • get paid hourly (same question)
  • Leading the project: will the project leader interact with the system to lead the project ? or is he/she just registered as leader for administrative responsibility purpose ?

Finally, some of these requirements go beyond the (goal oriented) use case, and describe the class model. Don't get trapped by this: the use case should focus on the actor interaction with the system.

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • Thank You very much. This helped me very much with many doubts I had with Use Case Diagrams generally. I really appreciate taking your valuable time to write this answer for me. – Ruvindra Yohan Mar 27 '19 at 03:10
  • But I have a problem. With the use case modifications you have suggested above, there are no any **include** use cases. Is it okay? – Ruvindra Yohan Mar 27 '19 at 03:22
  • @RuvindraYohan the main purpose is to show the main goals of the system and the actors wha are really involved. So I went to the essential. Of course if there are some common parts in the goals that can serve several purposes, the includes are fine. I’m not a big fan of them since very often they just lead you to present in the diagram UC that are at different levels of details, and once you start you’re tempted to add more such details and end-up with a cluttered diagram that is difficult to understand when being discussed with users. – Christophe Mar 27 '19 at 06:57
  • So as you have pointed out that _Perform role_, _get paid hourly_ and _Leading the project_ use cases are questionable and if I remove those, that means both **Employee** and **Project Leader** are removed from the diagram. So that means they don't have to use the system? – Ruvindra Yohan Mar 27 '19 at 11:24
  • @RuvindraYohan that’s exactly the question: the only user identified in the narrative is the company owner. Is there anything that suggest that other users would use the system, and if yes for which purpose ? A candidate could be the project leader. But what would he/she do in the system ? Another candidate could be other employees (e.g. for recording their billable time), but there’s nothing in the narrative to tell us. So in my view some further q&a, interviews or workshops would be needed to elicit such possible but yet unclear requirements. – Christophe Mar 27 '19 at 12:37
  • Ah ha. Now I understand. Thank you very much for your support. Sorry to have this conversation this long. But can you please see this [image](https://imgur.com/a/0FZJgXn) of the updated UC Diagram and give ur ideas. – Ruvindra Yohan Mar 27 '19 at 18:23
  • @RuvindraYohan this seems ok to me, considering the narrative of the requirements. – Christophe Mar 27 '19 at 18:54