ISMA 02 - Use Case Diagrams

October 23, 2017

Today, first I explain what use case diagram is, second I share my homework "Use Case Description".


Use-Case Diagrams:


In order to build a system, you need function and non-functional requirements. Functional requirements is essentially what your system should do while the non-functional requirements specify how your system should do. Functional requirements are description of your functioning behaviors of your product. They specify functions that your system component must be able to perform. Any other requirements than functional requirements are non-functional requirements. Non-functional requirements specify the performing criteria of a particular system.


For ex:

F-R:    When user clicks "Make Payment" button, it should be navigated to "Verification Page".

NF-R:  The customer shall take notification e-mail in 60 seconds after verification is made successful. (This might be considered under Software Requirements or Performance Requirements).


The main purpose of Use-case diagram is to help development team to visualize the functional requirements of a system, including the relationships of actors to essential processes, as well as the relationships between different use cases. Use-case diagrams generally show groups of use cases — either all use cases for the complete system, or a breakout of a particular group of use cases with related functionality (e.g., all security administration-related use cases).


In the example above, we see roles and relationships in use cases.

Actor: The role played during interaction with a use-case. It can be personal or non-personal, an additional service or system. They are represented as stick-man.

Use-case: The action in the system done by actors. They are drawn by texts inside spheres. Naming is the crucial part of Use-Case diagrams. You should check the function and naming according to CRUD;






In the example, "Client Register" is not good enough. Instead, you need to write "Register as Client" to make it clear. Use-case naming should be in commanding/ordering format to be easily understood even by a stakeholder who is not a member of development team. 

Relationship: They are semantic links between the elements of a model. In the example, we have three of them.

*Generalization: It is the parent-child relationship between actors or use-cases. They are shown by arrows pointing the parent. 

*Association: The relation between actors and use-cases, drawn by lines. ex: "New Customer should View Items"

*Dependency: It represents statements dependent on each other. In this example, we see "include" dependency. "Registered customer has to View Item in order to Make Purchase". It means that making purchase depends on viewing item. Unless the registered customer views item, he/she can't make purchase. There is also "extend" dependency which tells that there is an alternative for the pointed use case. It is not covered in this example however you can see it that "Register with Google account" is an extended (alternative) way of registering the system on my homework.


Use cases are documented in a specific way which is called "Use Case Documentation". You will see how to do on my homework.


Now comes the part about my homework. I am asked to come up with an information system idea, a name, brief description of the system, at least 20 functional requirements, a use-case documentation and a use case diagram. I show you only two use-cases here. The whole document consists of 12 pages. You can download it here.


My Homework:








Logoit is an online marketplace that provides custom logo service in 24 hours by freelance designers around the world. A customer, who wants to order a logo for his/her own needs, logs in the system, see the news feed including the latest freelance jobs, can pick a specific freelance designer by observing his/her portfolio, can post a public logo request for his/her logo need and make the best choice among the design offers made by designers.


On the other hand, a freelance designer can create his/her own profile, see the public requests and offer customers draft logo designs. Freelancer can improve their portfolio by selling more logos and make customers choose him/her first.


Logoit’s mission is to make customer happy in 24 hours. Once a public post is published or a private order is made, freelancers have only 24 hours to reply with draft design.


Some Functional Requirements:

1. User should register.
1.1. User cannot register as both customer and freelancer.
1.2. User should be able to register with Google account.
2. User should log in the system.
2.1. User should be able to renew the password if he/she forgets it.
2.2. User should be able to log in with Google account.




LOGOIT Use Case Documentation






Please reload

Featured Posts

ISMA 02 - Use Case Diagrams

October 23, 2017

Please reload

Recent Posts

January 31, 2018

August 2, 2017

June 10, 2017

April 13, 2017

Please reload

Please reload

Search By Tags