Comparison of Use-Case and User Stories System Requirements

Introduction

During the whole software projects, development and processes, a documentation or a set of documentation that describes the features and the behaviour of a system or software application is required. This is known as System Requirements Specification (SRS). Besides specifying the behaviour of the system, the specification also defines the core business processes, assumptions which could be made and the major parameters which should be met by the system.  There are different methodologies (agile, waterfall) which is used and applied for SRS. System requirement specification should include a description of the Business drivers, Business Model, Functional and system requirements, Business and System Use Cases, Technical Requirements, System Qualities, Constraints and Assumptions and finally Acceptance criteria. Alternatively, it should include agile methodologies in form of user stories.

This research report will compare the two main elements of the System Requirements Specifications which is Use-Case and User Stories. It will compare the techniques of these elements and will provide advantages and limitations of each technique. Sequentially, amongst the five process models, it will provide an argument explaining why the technique is useful for the process model. This will be followed by a specific software engineering process which would be suitable for the projects which has been done during the semester. And finally, once elicitation technique will be discussed for the software engineering process which has been done during the semester. It will explain why the elicitation technique chosen is useful for the process by summarising the benefits of the technique. 

Requirements Modelling

Technique Comparison

User Stories

A user story is a short description of what the user will do when they see the website or use the software. It is a conceptual scenario. User stories is written from the perspective of a user, it uses the natural language of the business and does not tell the whole story on its own. It is also a type of boundary object which facilitate sensemaking and communication. This means that user stories help software teams understand the system and its main concepts. In user stories, each task defines one way to use the system just like use case.

Advantage:

1. User stories is a process which is informal and starts with a simple sentence. For an example: I want to be able to (function of the system), so that (goal) can be achieved. After using this statement, use case can be derived. User stories can make productive planning conferences and a useful way to enhance functions to the project.
2. User stories can help deliver the highest value by focusing on the customer needs.
3. User stories can help to increase the return on investment significantly.
4. User stories helps to bring the team members closer and work efficiently as a team.

Limitations:

1. User stories can leave out a lot of detailed information as it depends on the conversational method of transmitting details and the duration of development to the customers. It is a very time-consuming tool and documentation is often not complete before hand compared to Use cases.
2. User stories needs compliance needs.
3. User stories does not help in transferring the knowledge if the team members are replaced.
4. User stories sometimes, can be interpreted differently.

Use cases:

A use case is a set of interactions between a system and actors. Actors can be one or multiple actors. In this case, actors refer to people, other systems or could be both. Use case is a complete specification which defines all the possible situations and scenarios. Use case is also a way to apprehend the flow of the process or the stages involved in developing a report and the outcomes which could be expected. Use case is a functional requirement defines the behaviour which could be achieved but not only a certain behaviour.

Advantages:

1. Use case includes the determination of actors and the capability to split the problem down into different sub-domains.
2. Use cases is beneficial to the project as it provides upfront research.
3. Use case diagram provides a complete summary of the whole software system in a single diagram.
4. Use case provides feedback from the customers and end users.
5. Use case requires an identification of exceptional scenarios.

Limitations:

1. Use cases often leave only a small room for negotiations or project additions.
2. Use case is completely agile, hence, can be complicated and not really an easy tool for the users or for a business sector.
3. Use case do not capture the non-functional requirements easily.
4. Use case do not address usefulness and usability.
5. Muse case is avoided by most of the developers because it is time consuming and requires a lot of time to develop a complete set of application.

Similarities and differences between User Stories and Use cases

Similarity: User stories are normally expressed in users’ everyday language. User stories should help the reader to understand what the software should achieve whereas Use Cases is written in users’ everyday business language to express the communication between the stakeholders.

Differences: User stories provides a small-scale and easy-to-use flow of information with less information, thus can be interpreted through conversations where as use cases provides a narrative of how uses relate to each other and to the system and they mainly focus on the goals of the users and how the goal can be achieved when the user goal is linked to the system.

Process Models Applicability

There are five different types of process models. Each model is different than others. These models are:

Structured or plan driven model: This could be either stage-wise process or waterfall process. The structured process demonstrates a series of nine phases which occurs during the process of software development and then it would place them in a classified order and hence these phases would occur. These phases are: Operational Plan, Operational Specifications, Program Specifications, Coding Specifications, Coding, Parameter Testing, Assembly Testing, Shakedown and evaluation. As use case is completely a specification which defines all the possible situations, a way to apprehend the flow of the process d has got stages involved in developing a report and the outcomes which could be expected; use-case could be suitable for this process.

Incremental model: Incremental model is a process of software development where the requirements are broken down into multiple modules. Incremental model has different steps which are analysis design, implementation, testing verification. This model could be distinguished into two main categories which is Unified Process and Object-Oriented Process Environment. The Unified process is completely use-case driven and incremental development process framework. Unified process as an incremental model can be said that it is use-case because in a use-case system, the requirements and specification of the software is collected which relates to unified process of an incremental model. Similarly, some of the high-end functions are designed in use-cases which supports this process model. 

Agile model: Agile method can be distinguished into different methods such as Scrum, Extreme Programming, Crystal, Dynamic Systems Development Method, Feature Driven Design and Adaptive Software Development. A user story is the smallest unit of work in an agile framework. Additionally, User story is implemented all in a single iteration of an agile project. During a sprint, each story in User stories goes through several stages such as: not started, started, in testing, finished and delivered. User stories requires the tasks to be prioritized to satisfy the customer, it can be longer or shorter in nature because of the development of the software.

Lean Model: Lean model is more philosophical than it is a process. It more relates to thinking big, acting small and hence fails fast as well. Use case mainly relates to lean model. Applying the lean philosophy of the waste reduction to the use case concept develops a stronger tool for the communication to and within a lean Software development team. The main purpose of both use-case and lean model is to satisfy the customers. Lean process model requires to improve the delivery, control the production and improve the process lead time and  while using use case, it delivers the same assets.

Formal Model:  Formal System Development does not uphold a well document but there are certain processes that share the mathematical formality as the core practice. Formal process and methods share the belief that software development is an inherently logical activity and can be conducted at its best by applying formal logic. Since, neither use case nor user stories require formal logic or a formal process. Neither one of those is applicable for a formal model. 

Process Selection

MyTrip Website

To implement this project efficiently, the agile process model should have been a best suit. This process model utilises the concept of user stories efficiently and the project itself is better done as a user stories project. One of the best approaches for this project would have been the usage of Scrum. Scrum is a collection of values, team roles and rituals used to develop repetitive products. My trip website allows user to choose destination, book a flight and plan their journey. To make this website, different team with different roles is needed. This is a repetitive process and Scrum would help achieve the website at its full potential. Business such as websites, travel blogs, social media uses Scrum for their product development. Scrum at its best helps to solve problems by avoiding the specific steps of instructions. Scrum is a way of approaching projects with flexibility. My trip was based completely on user stories. User stories allows flexibility to the users. For an e.g. If this is not done, then this can be done. Scrum has its own principles and guidelines for working together as a team, they are: Courage to solve hard problems, focus, commitment to shared term goals, openness about work and any challenges that might come up.

So how can we relate MyTrip Website to Scrum?

MyTrip website has some features which would require to solve a problem. Let us take an example as, “A customer who has travelled to Hungary wants to change the ticket because he wants to stay in Hungary for two more days.”. This requires MyTrip website to look for the best possible solution for the customer. Hence, this can be related to solving problem. During the development phase of MyTrip website, the software developers would need to focus on achieving their daily goals and their achievements. This website requires team members to work together to achieve a specific goal together. They would need commitment to work with each other better and hence, achieve the same goal which is the completion of the development phase of the website. And hence, the team member, project managers and the project team should be open towards any work they do and the challenges they might have to face in the future.

Hence, this results that Scrum process of Agile Process Model would be a best suit for this specific project.

Hospital Patient Records System

Hospital Patient Record System followed a use-case technique. This whole system leaned more towards an Incremental Process Model. Incremental Process model is completely use-case driven. Incremental process can also be known as successive version model. First, a simple working system with few basic features is implemented in an Incremental Process Model. Here, in this HPRS project’s case, simple working system for HPRS was being made with few features like Accessing the patient data, managing the patient data, Manual Data Entry, etc. After these are implemented in an incremental process model, then multiple versions are created by adding, changing or deleting actors or the use cases in the system. Hence, the final version is then implemented and then delivered to the customer which in HPRS, the final version was being delivered to a hospital.

The diagram below shows the incremental process as A, B and C.

In this HPRS system project, requirements of the software were broken down into several modules to construct and deliver incrementally. For the next increment, the plan was made. The plan was not made for a longer term. Nevertheless, it was easier to change and alter the version as the customer would need it to be. Core features as described above was developed by the development team. This followed by increasing the levels of capabilities by adding more functions in the new versions.

After every requirement was made, feedback from the customer was taken in the HPRS project and hence, the feedback from the customer was taken into action and updated in the other versions. Each version of the software has additional features over the ones done previously. This is then documented as version 1, version 2 and so on.

After Requirements gathering and specification, requirements are then spitted into several different versions starting with version-1, in each successive increment, next version is constructed and then deployed at the customer site. After the last version (version n), it is now deployed at the client site.  After the completion of the gathering of requirements and specification, requirements are then finally spitted in numerous different versions which would look like version-1, version-2, etc. The whole HPRS systems shows this in the project done during the semester. If there is any increment, then again next version is made and deployed for the customer.

This incremental process described using the concept of HPRS project could be said as Parallel Development model where different subsystem are developed at the same time. If the project has enough resources then the time anticipated for the closure of the project can be decreased.

This describes the whole incremental process model and shows that HPRS system was based more on the Incremental process model utilising the Use-Case technique. 

Elicitation Technique

The success or failure of a system development is solely dependent on the requirements that has been chosen. Elicitation technique is all about learning the needs of the users and communicating those needs to the system builders. Requirement elicitation is known as one of the most perilous, knowledge-incentive activities of software development. Poor execution of the elicitation technique could result in a project failure. Hence, elicitation technique is required for the software engineering process. In every step of a software development cycle, the first phase is to determine the requirements. Hence, for the Incremental process Model as a software engineering process discussed above, brainstorming could be really very useful. Brainstorming in simple terms is the problem-solving technique which shows many different spontaneous ideas from the members of the group. Every idea during the brainstorming is encouraged even if it is outside of the box. Brainstorming is a group related technique. It is planned to generate many different ideas to provide a platform to share views. Brain-storming requires every idea to be documented which In the case of HPRS system as an incremental process model, all of the actors, system, external actors and the way the system works is documented. Finally, a document which is prepared will show all the requirements of the project and when releases, its priority is also being shown.

Incremental process model’s main principle is to gather the requirements; hence, brainstorming could result in a good way to make the project efficient and better. In the incremental process model, all the activity is done in a group but not individually. Incremental Process Model in HPRS system consists of many different organizational stakeholders where brainstorming requires stakeholders to develop new ideas. Incremental Process Model or a Parallel Development model aims at resolving the issue by getting feedback from the customers and then new versions are created, changed and updated. Brainstorming helps to resolve the issue. It helps to identify what is stopping the organization from moving ahead with the development. During a software development by using Incremental Process Model as the process, brainstorming can help in every stages of the project cycle. It will help to identify the stakeholders (for an example, Doctors, medical practitioners, external doctors in an HPRS system). Database analyst in an HPRS system; an incremental process model could bring insight about information storage which nobody else can do in the development cycle.

Summary

In short, brainstorming has its advantages as well as limitations for the process model chosen above:

Advantages of using brainstorming:

1. Brainstorming gives idea and perception where these fundamentals may not have been thought about before.
2. Spontaneous thinking can help look for an alternative solution to the problem.
3. Brainstorming helps to get rid of the conflicts and gives a chance to every member in a group to put their ideas without judgements.

Limitations of using brainstorming

1. Brainstorming is time consuming. So is the Incremental Process Model.
2. Sometimes the ideas developed may not work. In the HPRS system, patient was an actor for a long time. But it appeared that patient was not really the actor in the system. 
3. There might be conflict in creating ideas and accepting each other’s ideas.
4. Brainstorming requires a leader or a facilitator to take control of the ideas.

Conclusion

In conclusion, this report compares and contrasts the two different technique; user stories and use-cases which has been applied to describe the requirements for the two projects done during the semester. It highlights the advantages and limitations of each technique used over the semester. Five process models plan driven, incremental, agile, lean and formal process are being discussed and which technique amongst the two technique best suits the process models. Each has their own pros and cons which has been outlined in this report.

A process model is being chosen for the two different projects which was done during the semester and it has been explained why the process model is a suitable one for the projects which was done during the semester. Again, each process has its own advantages and limitations which has also been outlined. Hence, a requirement elicitation technique has been chosen for the process model outlined above and why is it suitable for the process model.

References

[1]”A Guide to the Business Analyst’s Body of Knowledge”, Cs.anu.edu.au, 2006. [Online]. Available: https://cs.anu.edu.au/courses/comp3120/public_docs/BOKV1_6.pdf.

[2] H. Podeswa, UML for the IT business analyst. Boston (Mass.): Course Technology Cengage Learning, 2010.

[3] H. Jansesn, “The Pros and Cons of Brainstorming, and the Best Alternatives – Boardview”, Boardview, 2016. [Online]. Available: https://boardview.io/blog/pros-cons-brainstorming-best-alternatives/.