A use case is a sequence of actions that describes the way in which real world interacts with the system. A System Use Case Assignment (SUC) helps in implementation of business decisions in a system as it helps to understand the behaviour of the system with respect to the external factors. Before designing the SUC diagram we need to understand the business requirement and, therefore, understanding the Business Use Case (BUC) is important. Understanding the BUC helps us to gather requirement from the point of view external to the system. We also need to think from the system point of view like how the data will be populated into the system, what are the limitations of the system and is it possible to implement the given requirement in the system. Thus, the complete analysis should be done so as to check whether the SUC covers the entire BUC requirement or not and what all additional information management to user and system can be provided.
The reason for choosing the SUC is that it allows to more things to write and draw apart from the system scenario. Keeping in mind the above factor we decided to initially draw the SUC diagram with customer and provision team as boundaries of the open system but eventually we changed the boundaries and kept only provision team as the boundary instead of customer service and provision team as provision team is the ones who will be using the system. There were many drafts prepared before settling for an SUC diagram.
After the System Use Cases were prepared we selected two use cases on it and explained in detail their description. The two system use cases are:
1- Create Sales Order
2- Trace Order
The main reason for selecting above two use cases is that they are large and have more details thus they provide a better opportunity to discuss and ponder about.
Create Sales Order:
Initially, the Create Sales Order had the primary actor as a customer and the supporting actors as provision team & service team but as stated above that after discussing as a group we decided to change the boundary to provision team from the customer as they are the one who will be using the system. As a result of above changes we also changed the supporting actors from provision team and service team to N.A.
After finishing the description of Create Sales Order we began describing business marketing and Trace Order use case. We changed the primary and supporting actor in Trace Order as well. Initially, the primary actors were customer & service team and the supporting actor was provision team but as the provisioning team is the one who will be using the system so we changed the primary actor from customer & service team to provision team. This, in turn, required changing the supporting actor from provision team to N.A. Then, we decided to rename the use case from Trace Order to Arrange Part Collection. Under the new name (Arrange Part Collection) more areas were covered. Thus, allowing more things to draw and write which otherwise was not possible and hence we renamed Trace Order. As a consequence of renaming the use case we were changed and added more points to basic and alternative flow.
Limitations and Problem Faced:
- The major difficulty was in defining the System Use Case as understanding the complete Business Use Case was the pre-requisite for this. Then analysing whether all the requirements of Business law Use Case can be implemented in the system or not. This sometimes required compromising with either system or business. These changes in Business Use Case and system made it difficult to design a System Use Case and the complete process took a lot of time.
- As I have been working on BUC hence shifting from BUC to SUC was difficult because I need to completely change my perspective of looking into the scenario from business to system point of view. Initially, I faced a lot of confusion in understanding the difference between the two. Only after reading various books on this topic and reviewing the lectures on SUC and BUC I was able to grasp fundamentals of both. The group members also helped me in understanding the SUC which otherwise would have been a difficult task.
- We faced difficulty while deciding the primary and supporting actor for Create Sales Order as with every meeting the either basic flow or the alternative flow was changed. It was only after a lot of brainstorming by comparing each and every possibility we were able to reach consensus.
- As we renamed the Trace Order to Arrange Part Collection we were required to make changes in the basic flow and alternative flow. This increased the amount of work and this section took a lot of time as it was difficult to get on a consensus with the basic and alternative flow. With each meeting, we made a lot of changes in both SUC and BUC which further added to the amount of work and brainstorming required by the group.
- Due to confusion in understanding BUC and SUC, I faced a lot of difficulty in writing the basic and alternative flow of Arrange Part Collection description.
- As the System Use Case is at a higher level and more complex than the Sequence Diagram and it contains more details so if we want to draw a good Sequence Diagram we should be first clear with the understanding of the System development. This was the major limitation for drawing the Sequence Diagram.
Some of the issues faced are already discussed above. Apart from these issues, we also had to select the format and style for description. We adopted the one that is explained by Satzinger, J. W., Jackson, R. B. and Burd, S. D. (2005) in Object-Oriented Analysis and Design with the Unified Process, Thomson, Boston and Massachusetts as an example. This format provides more clear and easy understanding of the description.
Selection of the primary actor in the Arrange Part Collection use case description was a very difficult task as it is the customer who will ask the provisioning team to do appointments and without customer the system will not work therefore customer should be the primary actor. But eventually, we reviewed the work and decided to select the provisioning team as a primary actor because provision team will be the one using the system and the system will not interact with the customer. Moreover, we decided to include the Reserve Part is the main use case for “Arrange Part Collection” as a customer can reserve a part without confirming the collection date but they are not allowed to make an appointment without the part.
Advantages and Disadvantages of System Use Case:
Based on the experience of working on the module following advantages and disadvantages were identified:
- It clearly defines the function of the system for the actor and thus also defines the boundaries. This helps in understanding the system in a better way and, in turn, adds value to the business impacts as one can provide better analysis and service by keeping in mind the limitation of the system.
- It helps in automation of the system and business functionality. It also assists in implementing the decisions in a system.
- They are incapable of handling non-interaction and non-functional based requirements of a system.
- The System Use Case is very complex and difficult to understand. Clarity of the system depends on the writer and not on the System Use Case. Both user and developer need time to comprehend it correctly.
- If the requirements are dynamic and constantly changes then it will be very difficult to maintain the System Use case as basic and alternative flow might require being changed which consumes a lot of time.
It was difficult for me to understand the module as shifting from the business to system perspective was not so easy. Referring to books, lectures and other sources as well as discussing with the group was very helpful. I am really delightful to have done this project as constantly reviewing the Business Globalization and making sure that all the requirements are covered makes one think from a broader perspective so as to make sure that the system completely supports all the requirements of the business process. After doing this module I can think about any company from both the business and system perspective and provide a better analysis of the situation.
Finally, working in a team not only helped me to understand the concepts as the group members answered to my queries and questions but they also brought many ideas that helped in creating a better use case. The project helped me to learn the dynamics of the group, time management (as we were bounded by the weekly task in the group) and to have patience in dealing with a situation.