In practical test design, how are test scenarios and use cases typically derived, and what kind of contents and format should they include to describe system behaviour effectively?

Introduction / Context:
Deriving test scenarios and use cases is a central skill for testers and analysts. This question checks whether you can connect written requirements and business processes with practical, readable artefacts that guide detailed test cases. Good scenarios and use cases give a clear and shared understanding of what needs to be validated without drowning stakeholders in low level technical details.

Given Data / Assumptions:
- Requirements, user stories or business process descriptions are available.
- The goal is to derive scenario level descriptions and use cases before writing detailed test cases.
- The focus is on structure and contents, not specific tool formats.
- No numeric calculation is needed; the answer is conceptual and process oriented.

Concept / Approach:
Typically, testers and analysts study requirement documents, user stories, interviews and process diagrams. From these, they identify major user goals such as register account, place order, cancel booking or generate report. Each goal becomes a test scenario or use case. A well written use case format usually lists the actor, preconditions, triggers, main success path and alternate or exception flows. High level acceptance criteria can be attached to each scenario. Later, detailed test cases expand each path with specific data, steps and expected outcomes.

Step-by-Step Solution:
Step 1: Recognise that the correct option must describe a link from requirements and business workflows to scenarios and use cases. Step 2: Remember that structured contents such as actor, precondition, main flow and alternate flows are typical in use case templates. Step 3: Examine the options and reject those that ignore requirements or that rely only on source code. Step 4: Option a clearly mentions deriving from requirements, user stories and workflows and lists structured elements. Step 5: Conclude that option a accurately describes how scenarios and use cases should be derived and documented.

Verification / Alternative check:
To verify, imagine a project where user stories are written in the format “As a customer, I want to place an order so that I receive products.” The scenario derived from this story would follow the main path of placing an order, while alternate paths might cover out of stock items or payment failure. Option a allows this natural mapping and includes acceptance criteria to confirm completion, so it passes the check.

Why Other Options Are Wrong:
Option b wrongly claims that only source code is used, which defeats the purpose of early test design and stakeholder communication. Option c postpones scenario creation until after coding, which is against best practice because it reduces the chance to find requirement gaps early. Option d implies that structure is unnecessary, which leads to confusion and difficult maintenance in real projects.

Common Pitfalls:
A common mistake is to create scenarios that are too technical or too narrow, such that they look like test cases instead of high level stories. Another pitfall is failing to maintain traceability between requirements, scenarios, use cases and test cases, which makes impact analysis hard when changes occur. Using a clear, consistent format as described in option a helps avoid these problems.

Final Answer:
They are derived from requirements, user stories and business workflows and described in a structured format that includes actors, preconditions, main flow, alternate flows and high level acceptance criteria for each scenario.