Difference between requirement, use case, and scenario?

great question. In my answer I want to give a stylized example to showcase why the various concepts of scenario, UR, FR, etc. exist.

Before one designs (builds) a system, one needs to have a set of requirements. These may not completely restrict the implementation, but specify it enough to fulfill the needs of the imagined end user. Ha! so one needs to imagine a user, and specify her needs.

So here's an example of a functional requirement:

New questions shall immediately become visible to all other users.

The concepts of personas, scenarios, use cases serve as a way of generating such requirements. It's all structured creative work; so there aren't any strict rules about this, but I hope that you'll get the drift.

First, one specifies a persona, like a short CV:

Tom is a senior software engineer that starts to assume managerial roles. In the new role he'll need to acquire lots of new skills on demand ..: Does he typically use the internet via his smartphone etc? What's his technical skill set, his personality? Anything that might be important.

Here comes a scenario with Tom, i.e. a user need derived from his persona:

Tom needs to quickly understand the difference between scenarios and use cases so that he can better communicate with his new manager colleagues. ..more details about Toms circumstances.. . So he visits stack exchange and asks about it .. .

From such a scenario for the persona Tom, we can derive several use cases, for example

Knowledgible users should be able to view and answer new questions as soon as these are posted to the platform.

Again to drive home my main point: personas, scenarios, and use cases can be used to derive and justify functional requirements of a system. Backtracing such a stack will inform you on how the users might be effected when changing a requirement. In medical design, essential requirements trace back to hazardous scenarios; so one knows better not to change these.

In common SW test process use cases do not descend from requirements. But it is true the opposite: by identifying use cases it is possible to define SW requirements.

A scenario is the definition of a setup or a state in which one or multiple requirements are tested.

Examples

Use Case: the unauthenticated users can access the knowledge base but only for the public areas

Requirement: the main menu for the anonymous user level shall be populated with the knowledge base public areas labels

Scenario: access the system as an anonymous user and then perform the tests for reqx1, reqx2 etc...

It is very important to understand the difference between requirement, use case, and scenario if you are working for a software testing solutions provider.

Requirement is the new or updated functionality that is to be introduced in an application which currently is not present. For example: A feature for customers to submit a checklist via forms and receive email according to the best criteria to which their requirements are catered.

Use Case is the flow where this requirement is meeting the objectives of the clients. For example: A customer is able to submit the checklist and back-end system provides the solution according to customer's requirement.

Scenario is a specific flow that is being performed to check if the system works fine for diverse clients using different platforms. For example: User should be able to submit the checklist via Mac system and safari browser with same results as when submission is done via Android phone and chrome browser.

Personally I would interpret the top 3 entities as follows:

Epic/Feature > User Story/Use Case > Acceptance Criteria

So for example:

Epic/Feature E1: Permission, the system should allow the restriction of access to data and actions to specific group of people.

Use Story/Use Case UC1: As an salesperson, I want to be able to access the list of clients assigned to me so I can view their orders

Acceptance Criteria UC1-AC1: Given that I am a logged in as a user who is a sales person assigned 10 clients, When I click on show me the list of clients Menu Item Then the list of 10 clients that are assigned to me should be displayed.

Acceptance Criteria UC1-AC2: Given that I am a logged in as a user who is a sales person assigned 10 clients, When I click on show me the list of clients Menu Item Then no clients that are not assigned to me should be displayed.

Use Story/Use Case UC2: As an Regional Supervisor, I want to be able to access the list of clients that belongs to my region so I can view their orders

Acceptance Criteria UC2-AC1: Given that I am a logged in as a user who is a regional supervisor for region A, When I click on show me the list of clients Menu Item Then the list of clients that belong to region A should be displayed.

Acceptance Criteria UC2-AC2: Given that I am a logged in as a user who is a regional supervisor for Region A, When I click on show me the list of clients Menu Item Then no clients that do not belong to region A should be displayed.

In software industry Requirement defines what our end goal is that customers exactly need and what will make our company to increase its business.It could be a product or service company which makes software products or offers services in various software fields, the most important thing is the requirement and how well the requirements are met.

Under Waterfall model, the Requirement documents are huge docs as the whole product is implemented in one phase. But this is not the case with Agile/SCRUM because in these methodologies the requirements are given for small functionalities or features as the product is prepared in a step by step manner.

User Story: A user story is a requirement for any functionality or feature which is written down in one or two lines and max up to 5 lines. A user story is usually the simplest possible requirement and is about one and only one functionality (or one feature).

It will be developed by Business Analyst based on the requirement specification. It is a detailed description of the Specification in a simplified version with realtime scenarios. The most commonly used standard format for a User Story creation is stated below:

As a (user role/customer), I want to (goal to be accomplished) so that I can (reason of the goal).

Scenario: While writing a test case for a module, you write different tests for that module say, Creating a user.There may be several ways to create a user like, creating a user through wizard or through uploading set of users. These are all the things we can call as a scenarios.

Based on Use case and scenarios, test cases will be written by the testers in software testing company.

One more thing, user stories aren't just single sentence affairs. The product owner also writes acceptance criteria, which define the boundaries of a user story, and are used to confirm when a story is completed and working as intended.

An acceptance criterion is a set of accepted conditions or business rules which the functionality or feature should satisfy and meet, in order to be accepted by the Product Owner/Stakeholders.

As a QA it is very important to understand the user story and its acceptance criteria profoundly with not even a single doubt remaining at the ‘start of testing’.

A scenario is a particular instance or set of steps for one path through the use case. A use case is a goal oriented process done by the system.

Considering your description, the clarifications can be given as :

Requirement : It is the changing need of the stakeholders which is tried to fulfil by the development team at the time of developing the product

Use case : After the requirements are clear, then the use cases can be designed/decided which will clear the overall flow of the system to developers first and then they can design the system accordingly. Once the flow is clear to them, then it becomes somehow simple to test the system by QA.

Scenario : It is the real-life situation in which the end-user/customer uses/interacts with the system and came across various failures(if there are any). Hence we generally used to say Real-world scenario.

Example: For a particular project the requirements are first being made clear by the Business Analyst. In the documentation and SRS part the Use cases can be found out and the development tasks can be allotted to various developers according to that. When a user uses the system, then it becomes a scenario.

A requirement is typically a general statement, whereas a use case is typically a specific statement implied or derived from the requirement. A requirement may map to multiple use cases. A scenario might be a set of background assumptions that put a use case in context, or it might be grouping of use cases.

Here is a contrived example. The requirement is to provide an API that converts a CSV file into a tab-separated file. A scenario might be, "John is a Java developer who deals with potentially large CSV files that are sometimes empty." A use case might be "If the input file is empty, the output file will also be empty" or "The API does not run out of memory while processing a 500Gb file".

Finally, SQA gets a lot of "What is the different between these terms" kinds of questions. If you hear someone utter some ambiguous phrases, and it's important to understand what they mean (e.g. because a co-worker or your boss used them), ask them what they mean. Among reasonable people, it is always OK to say, "Different people use that phrase to mean different things, so can you be more specific about what you meant?" If you've never heard the phrases before, or you lack confidence, you can do a Google search first, come up with a first approximation of what they mean, and then ask that person to clarify what they meant.