User Story and Use Case - Thinking and Discussing

While working with an agile team you surely will meet the definitions like Use Cases or User Stories. Let’s define what it’s all about and what is the difference between these two instruments.

Use Case is a scenario technique for describing the interaction. Using a case, a user requirement can be described, as well as a requirement for the interaction of systems, and a description of the interaction of people and companies in real life.

In general, using the Use Case can describe like the interaction of two or more participants with a specific purpose, for example:

• purchase of goods in a store (Buyer-Seller)
• sending a letter by e-mail (Addressee-Mail client)
• page request by browser (Browser-Web-server)

In a use case, synonyms of human requirements for a user to solve problems in the system are often found. To develop functional requirements for the system, we write a whole set of Use Cases, taking into account the user goals. This set allows you to ensure the completeness of user requirements for the system.

Using Casein itself is a natural way to describe a dialogue, it is understandable to a person without preparation, Use Case usually does not contain implementation details and is written in the language of users' goals. Therefore, it is convenient to coordinate the Use Case with the Customer as a “delivery unit”: an element of planning work on the system and delivering the project.

Use Case does not provide completeness of all functional requirements if complex business logic should be incorporated into the system, i.e. information processing in the system depends not only and not so much on the actions of users, but on the internal rules of interaction of objects. For example, work with systems such as “tracker” is defined by rather simple and standard Use Case: “Create a task”, “Assign a task”, “Mark a task as completed”. However, there are a lot of task trackers, and this is justified by the fact that each has its own capabilities for setting task life cycles, their types and relationships. And this internal logic of working with tasks makes no sense to describe in the form of a Use Case.

The same applies to account programs, decision support systems, professional systems for engineering and design. Use Case is important to them, but will not cover a fifth of the requirements for functionality.

User Story is, first and foremost, a guide to creating, optimizing and promoting a product. Secondly, it is an opportunity to once again evaluate the prospects of the product. In a large WEB and among software developers, User Story functions successfully replace functional specifications.

Three reasons in favor of User Story compared to specifications when developing a mobile application:

• During the creation of a user story, developers think about how to solve a number of problems before the development process begins. User Story is great help to take a look at the whole system.
• User stories are the result of teamwork, as opposed to specifications. As teamwork result, user stories help to identify all the weaknesses of the product and solve all problems in the implementation of the idea before developing in the format of live communication.
• User Stories are created including for testers. They contain user scripts that will become the basis of testing after the completion of the project.

Correctly written user stories avoid many common problems, the main one of which is the incorrect presentation of the final product by the developer. The situation, by the way, is quite common. And in the interests of the publisher, so that the result of the development of a mobile application fully meets the requirements and expectations of the user, which means that special attention should be paid to the creation of User Story.

Your ideal story should be written in the following way:

Like, <user role>, I <want to get something >, <for such a purpose>

You have now formulated the business value for the user of your product. But the charm of the user story is that it formulates not only business value, but also the requirements for development and testing. In other words, you can add acceptance criteria, technical notes, a description of error handling that summarize all the tasks you need to do.

Here's what the user story could look like in a shorter form:

As a driver with a lighted gas lamp, I want to quickly find the nearest good gas station to refuel with a high-quality gasoline.

Acceptance Criteria:

• As a driver with a light on, I can see all the upcoming gas stations.
• How ... I can choose gas stations for the brands of gas stations suitable for me.
• How ... I can see the upcoming refueling of the selected brands list.
• How ... I can see the nearest gas stations selected on the map.

With an understanding of how User Stories and Use Case could be used in your project it could be successfully used and save budget, time, resources and also help the team to catch up on what is software product all about.