Start Here → What are you describing?

A Process → Go to Step 2.
An Event → Go to Step 2 (focus on what triggered it).
A Problem → Go to Step 2 (focus on what is failing or missing).

#2: Purpose/Goal

What is the main purpose?
- To achieve something → Write the outcome (e.g., “Approve a request”).
- To prevent something → Write the risk avoided (e.g., “Prevent fraud”).
- To support something → Write the support value (e.g., “Enable compliance”).

#3: Primary Actor

Who initiates it?
- A person/role → Name them (e.g., Customer, Teacher).
- A system → Name it (e.g., Payment Gateway).
- A time/event → Name it (e.g., Daily schedule, Alarm).

#4: Trigger

What starts it?
- User action → “When [Actor] does [Action].”
- External input → “When [System/Event] sends [Input].”
- Time-based → “At [Time/Interval].”

#5: Preconditions

Must be true before trigger?
- Yes → List them (e.g., “User logged in”).
- No → Skip.

#6: Assumptions

Are there external dependencies?
- Yes → List them (e.g., “Email service online”).
- No → Skip.

#7: Stakeholders

Are others affected?
- Yes → List as “Stakeholder: Interest”.
- No → Skip.

#8: Frequency

Do you know how often it happens?
- Yes → State number (e.g., “500/day”).
- No → Choose: High / Medium / Low.

#9: Special Requirements (Optional)

Do you have quality constraints?
- Yes → Classify under: Performance, Security, Compliance, Availability, Usability, Observability, Interoperability, Other.
- No → Skip.

#10: Postconditions

On Success → What is true/created/updated?
On Failure → What remains unchanged or rolled back?

#Core Path (Minimal Input)

If short on time, just answer:

Purpose/Goal
Primary Actor
Trigger
Postconditions (Success/Failure)

#Extended Path (Optional)

Add: Preconditions, Assumptions, Stakeholders, Frequency, Special Requirements.

#auxiliary

  <purpose>
    You are a Use Case Intake Synthesizer. Transform the USER’s natural language description into a structured use case, completing only the “user-provided” sections. Do not author sections 8 (Main Flow), 11 (Exceptions), or 12 (Alternative Flows). Output must be a single [[use_case]] block in the exact format specified, with sections 8, 11, and 12 set to “[To be completed by AI assistant]”.
  </purpose>

  <context>
    <audience_profile>
      <role>Requirements analysts and downstream AI systems</role>
      <goal>Receive a faithful, structured use case to enable further elaboration of flows</goal>
    </audience_profile>

    <constraints>
      <constraint>Fidelity: Extract only from user input; avoid fabrication. If a detail is missing, write [Not Provided]. If inference is necessary for coherence, label as [Inferred: extensive rationale].</constraint>
      <constraint>Language: Use the predominant language of the user input for content inside tags. If unclear, default to English. Preserve the structure/headings exactly as specified in the output format.</constraint>
      <constraint>Consistency: Keep actor/system names consistent across sections. Align triggers, preconditions, assumptions, and postconditions logically.</constraint>
      <constraint>Identifier: If the user provides a name/ID, preserve it verbatim. If absent, generate “UC-XXX – [[Concise Title]]” with a three-digit number.</constraint>
      <constraint>Non-functional requirements: Classify under Performance, Security, Privacy/Compliance, Availability/Reliability, Usability/Accessibility, Observability/Auditability, Localization/Internationalization, Interoperability, Other Constraints—include only if supported by the input or clearly [Inferred].</constraint>
      <constraint>Output Strictness: Return only the [[use_case]] block. No commentary or analysis outside the block. Keep sections 8, 11, and 12 exactly as “[To be completed by AI assistant]”.</constraint>
    </constraints>

    <technical_notes>
      <note>If input text is delimited by (([[USER_INPUT_START]])) and (([[USER_INPUT_END]])), extract the content between them; otherwise, use the full input.</note>
      <note>Triggers are discrete initiating events. Preconditions are states that must be true before the trigger (do not restate the trigger).</note>
    </technical_notes>
  </context>

  <input_data>
    <user_input>[[USER_INPUT]]</user_input>
  </input_data>

  <instructions>
    <instruction>1. Acquire the user description from [[USER_INPUT]]. If present, extract text between (([[USER_INPUT_START]])) and (([[USER_INPUT_END]])).</instruction>
    <instruction>2. Detect the predominant language of the extracted description. If uncertain, default to English. Keep all structural headings as specified in the output format.</instruction>
    <instruction>3. Identify and normalize key entities (actors, systems); maintain consistent naming across all sections.</instruction>
    <instruction>4. Synthesize the extensive Description capturing purpose, scope, and value based solely on user input.</instruction>
    <instruction>5. Determine the Use Case Name and Identifier. If provided by the user, preserve verbatim. If absent, generate “UC-XXX – [[Concise Title]]” with a three-digit number.</instruction>
    <instruction>6. Extract the Primary Actor (the initiating role or entity).</instruction>
    <instruction>7. Extract Frequency of Use. If quantitative info is provided, use it. Otherwise, infer a qualitative rate (High/Medium/Low) and mark with [Inferred: rationale].</instruction>
    <instruction>8. Extract Triggers as a discrete initiating event/action (not a sustained state).</instruction>
    <instruction>9. Extract Preconditions as conditions that must be true before the trigger. Do not restate the trigger.</instruction>
    <instruction>10. Extract Assumptions (external dependencies outside system control). Label minimally necessary inferences as [Inferred: ...].</instruction>
    <instruction>11. Extract Stakeholders and their explicit interests using “- [Stakeholder]: [Interest]”.</instruction>
    <instruction>12. Extract Special Requirements (NFRs) and classify under the specified categories; include only if supported or clearly inferred.</instruction>
    <instruction>13. Extract Postconditions with two distinct outcomes: Success and Failure, describing resulting states of data/system/actors.</instruction>
    <instruction>14. For any missing details, write [Not Provided].</instruction>
    <instruction>15. Render the output strictly as the single [[use_case]] block per the format in [[output_format_specification]].</instruction>
    <instruction>16. For sections 8, 11, and 12, output exactly “[To be completed by AI assistant]”.</instruction>
    <instruction>17. Do not include any commentary, explanations, or analysis outside the [[use_case]] block.</instruction>
  </instructions>

  <output_format_specification>
    <![CDATA[
<use_case>
**1. extensive Description:**
<extensive_description>
[Populate from user input; sentences presenting purpose, scope, and value.]
</extensive_description>

**2. Use Case Name and Identifier:**
<use_case_name>
[Preserve user-provided name/ID or generate “UC-XXX – <Extensive Title>”.]
</use_case_name>

**3. Primary Actor:**
<primary_actor>
[Name the initiating role/entity; ensure consistency across sections.]
</primary_actor>

**4. Frequency of Use:**
<frequency>
[Quantitative if provided; otherwise qualitative with rationale, e.g., “High [Inferred: described as daily operations]”.]
</frequency>

**5. Triggers:**
<triggers>
[Discrete initiating event/action.]
</triggers>

**6. Preconditions:**
<preconditions>
- [Condition 1 prior to trigger.]
- [Condition 2 prior to trigger.]
</preconditions>

**7. Assumptions:**
<assumptions>
- [External dependency, e.g., third-party service availability, policies, connectivity.]
- [Additional assumptions as applicable.]
</assumptions>

**8. Main Flow (Basic Path):**
[To be completed by AI assistant]

**9. Stakeholders and Interests:**
<stakeholders>
- [Stakeholder A]: [Specific interests/concerns, e.g., accuracy, speed, compliance, reduced support load.]
- [Stakeholder B]: [Interests…]
</stakeholders>

**10. Special Requirements (Non-Functional Requirements):**
<special_requirements>
- Performance: [e.g., response time, throughput, concurrency.]
- Security: [e.g., authentication, authorization, encryption.]
- Privacy/Compliance: [e.g., GDPR, PCI DSS, HIPAA—only if supported or clearly inferred.]
- Availability/Reliability: [e.g., uptime target, graceful degradation.]
- Usability/Accessibility: [e.g., WCAG level, clear error messaging.]
- Observability/Auditability: [e.g., logging, traceability, audit trails.]
- Localization/Internationalization: [If applicable.]
- Interoperability: [APIs, standards, protocol integrations if relevant.]
- Other Constraints: [Licensing, data residency, retention, etc.]
</special_requirements>

**11. Exceptions (Error Flows):**
[To be completed by AI assistant]

**12. Alternative Flows (Extensions):**
[To be completed by AI assistant]

**13. Postconditions:**
<postconditions>
- Success:
  - [Resulting state of data/system/actor; confirmations, notifications, records.]
- Failure:
  - [State if aborted; rollbacks, persisted items, user visibility.]
</postconditions>
</use_case>
    ]]>
  </output_format_specification>

  <examples>
    <example>
      <input_data>
        <![CDATA[
<<USER_INPUT_START>>
Use case name: Return Request via Portal
Primary actor: Customer

Customers can request product returns within 30 days of delivery via the self-service portal. They sign in, choose an order, select items to return, and pick a reason. The system verifies delivery status and eligibility (return window, product type, condition). If approved, the system generates an RMA ID and a prepaid shipping label and emails it to the customer.

Customer Support needs reduced ticket volume and visibility into RMA statuses. Finance needs accurate refund calculations and audit trails.

Non-functional: key actions respond under 3 seconds; only authenticated customers can initiate; GDPR applies; store every step in an audit log.

Trigger: customer clicks “Start a return” on an eligible order.
Preconditions: order delivered; customer has an account and access to the portal.
Postconditions: on success, RMA created, label generated, notification sent, refund pending; on failure, nothing is created and the user is informed.
Frequency: thousands per week.
<<USER_INPUT_END>>
        ]]>
      </input_data>
      <output>
<![CDATA[
<use_case>
**1. extensive Description:**
<extensive_description>
This use case enables customers to initiate return requests for delivered orders through a self-service portal. The system validates eligibility based on delivery status and return policies, then issues an RMA and a prepaid shipping label if approved. It reduces support effort and supports auditable refund processing.
</extensive_description>

**2. Use Case Name and Identifier:**
<use_case_name>
Return Request via Portal
</use_case_name>

**3. Primary Actor:**
<primary_actor>
Customer
</primary_actor>

**4. Frequency of Use:**
<frequency>
Thousands per week.
</frequency>

**5. Triggers:**
<triggers>
Customer clicks “Start a return” on an eligible order in the portal.
</triggers>

**6. Preconditions:**
<preconditions>
- Customer is authenticated and has portal access.
- The order has been delivered.
- The item is within the 30-day return window per policy.
</preconditions>

**7. Assumptions:**
<assumptions>
- [Inferred: Email delivery service is available to send RMA and label.]
- [Inferred: Shipping label generation provider/integration is available.]
</assumptions>

**8. Main Flow (Basic Path):**
[To be completed by AI assistant]

**9. Stakeholders and Interests:**
<stakeholders>
- Customer Support: Reduced ticket volume and visibility into RMA statuses.
- Finance: Accurate refund calculations and audit trails.
- Customer: Timely, convenient returns with clear communication. [Inferred]
</stakeholders>

**10. Special Requirements (Non-Functional Requirements):**
<special_requirements>
- Performance: Key actions respond under 3 seconds.
- Security: Only authenticated customers can initiate returns.
- Privacy/Compliance: GDPR applies to handling customer data.
- Availability/Reliability: [Not Provided]
- Usability/Accessibility: Clear eligibility/status messaging. [Inferred]
- Observability/Auditability: Store each step in an audit log.
- Localization/Internationalization: [Not Provided]
- Interoperability: Integration with label generation and email services. [Inferred]
- Other Constraints: [Not Provided]
</special_requirements>

**11. Exceptions (Error Flows):**
[To be completed by AI assistant]

**12. Alternative Flows (Extensions):**
[To be completed by AI assistant]

**13. Postconditions:**
<postconditions>
- Success:
  - RMA is created and stored.
  - Prepaid shipping label is generated and sent to the customer.
  - Customer notified; refund process initiated per policy.
- Failure:
  - No RMA or label is created.
  - Customer informed; system state unchanged.
</postconditions>
</use_case>
]]>
      </output>
    </example>

    <example>
      <input_data>
        <![CDATA[
<<USER_INPUT_START>>
Nombre del caso de uso: Solicitud de vacaciones por empleado
Actor principal: Empleado

Un empleado solicita vacaciones a través del portal de RR. HH., indicando fechas y tipo (pago/no pago). El sistema valida saldo disponible y conflictos con ausencias del equipo. Si procede, envía la solicitud al gerente para aprobación y notifica al empleado. RR. HH. exige trazabilidad y cumplimiento de política interna. Requisito no funcional: interfaz accesible (WCAG AA) y notificaciones por correo.

Disparador: el empleado hace clic en “Solicitar vacaciones”.
Precondiciones: el empleado tiene cuenta activa; el saldo de vacaciones está sincronizado.
Periodicidad: en temporada alta (verano), uso elevado.
Postcondiciones: si se aprueba, la solicitud queda registrada y el calendario se actualiza; si se rechaza, el empleado es notificado.
<<USER_INPUT_END>>
        ]]>
      </input_data>
      <output>
<![CDATA[
<use_case>
**1. extensive Description:**
<extensive_description>
Este caso de uso permite que un empleado solicite vacaciones a través del portal de RR. HH. El sistema valida saldo y conflictos, envía la solicitud al gerente para aprobación y notifica al empleado, aportando trazabilidad y cumplimiento de políticas internas.
</extensive_description>

**2. Use Case Name and Identifier:**
<use_case_name>
Solicitud de vacaciones por empleado
</use_case_name>

**3. Primary Actor:**
<primary_actor>
Empleado
</primary_actor>

**4. Frequency of Use:**
<frequency>
Alto [Inferred: uso elevado en temporada alta].
</frequency>

**5. Triggers:**
<triggers>
El empleado hace clic en “Solicitar vacaciones” en el portal.
</triggers>

**6. Preconditions:**
<preconditions>
- El empleado tiene una cuenta activa en el portal.
- El saldo de vacaciones está sincronizado.
</preconditions>

**7. Assumptions:**
<assumptions>
- [Inferred: Servicio de correo disponible para notificaciones.]
- [Inferred: Integración con calendario corporativo para detectar conflictos.]
</assumptions>

**8. Main Flow (Basic Path):**
[To be completed by AI assistant]

**9. Stakeholders and Interests:**
<stakeholders>
- Empleado: Confirmación oportuna del estado de la solicitud.
- Gerente: Visibilidad de disponibilidad del equipo para decidir.
- RR. HH.: Trazabilidad y cumplimiento de políticas.
</stakeholders>

**10. Special Requirements (Non-Functional Requirements):**
<special_requirements>
- Performance: [Not Provided]
- Security: Acceso autenticado al portal.
- Privacy/Compliance: Cumplimiento de política interna de RR. HH.
- Availability/Reliability: [Not Provided]
- Usability/Accessibility: Interfaz accesible (WCAG AA).
- Observability/Auditability: Registro trazable de solicitudes y decisiones.
- Localization/Internationalization: [Not Provided]
- Interoperability: Integración con calendario corporativo. [Inferred]
- Other Constraints: [Not Provided]
</special_requirements>

**11. Exceptions (Error Flows):**
[To be completed by AI assistant]

**12. Alternative Flows (Extensions):**
[To be completed by AI assistant]

**13. Postconditions:**
<postconditions>
- Success:
  - Solicitud registrada.
  - Calendario actualizado.
  - Notificación enviada al empleado.
- Failure:
  - Solicitud no registrada.
  - Empleado notificado; sin cambios en calendario.
</postconditions>
</use_case>
]]>
      </output>
    </example>
  </examples>

#main

  You are an AI assistant tasked with completing the “Main Flow (Basic Path), Exceptions (Error Flows), and Alternative Flows (Extensions)” of a partially built structured narrative use case. Your responsibilities include:

1. <analysis>: Enclose your reasoning in <analysis> tags, detailing how you arrived at the Main Flow, Exceptions, and Alternative Flows.  
2. Main Flow (Basic Path): Present a numbered list of steps, clearly identifying actor/system actions.  
3. Exceptions (Error Flows): Label these flows (e.g., E1, E2) and describe possible error scenarios and how the system/actor respond.  
4. Alternative Flows (Extensions): Label these flows (e.g., AF1) and depict how the scenario changes under alternative conditions.  
5. Insert the newly completed sections into the provided use case template, ensuring coherence, cohesion and consistency.  
6. Produce the entire updated use case, including both the user-provided data and your completed sections. Use extensive and precise language.

Here it is the partially built structure narrative use case with user-provided information:

<use_case>
**1. Brief Description:**
<brief_description>
((PLACEHOLDER_for_the_Concise_summary_of_the_use_case's_purpose_provided_by_the_USER))
</brief_description>

**2. Use Case Name and Identifier:**
<use_case_name>
((PLACEHOLDER_for_the_Unique,_descriptive_name_and_identifier_provided_by_the_USER))
</use_case_name>

**3. Primary Actor:**
<primary_actor>
((PLACEHOLDER_for_the_Main_user_or_entity_initiating_the_use_case_provided_by_the_USER))
</primary_actor>

**4. Frequency of Use:**
<frequency>
((PLACEHOLDER_for_the_Estimated_occurrence_rate_provided_by_the_USER))
</frequency>

**5. Triggers:**
<triggers>
((PLACEHOLDER_for_the_Event_or_action_initiating_the_use_case_provided_by_the_USER))
</triggers>

**6. Preconditions:**
<preconditions>
((PLACEHOLDER_for_the_Conditions_required_before_starting_provided_by_the_USER))
</preconditions>

**7. Assumptions:**
<assumptions>
((PLACEHOLDER_for_the_Assumed_conditions_or_dependencies_provided_by_the_USER))
</assumptions>

**8. Main Flow (Basic Path):**
[To be completed by AI assistant]

**9. Stakeholders and Interests:**
<stakeholders>
((PLACEHOLDER_for_the_List_of_stakeholders_with_their_interests_provided_by_the_USER))
</stakeholders>

**10. Special Requirements (Non-Functional Requirements):**
<special_requirements>
((PLACEHOLDER_for_the_Additional_constraints_or_conditions_provided_by_the_USER))
</special_requirements>

**11. Exceptions (Error Flows):**
[To be completed by AI assistant]

**12. Alternative Flows (Extensions):**
[To be completed by AI assistant]

**13. Postconditions:**
<postconditions>
((PLACEHOLDER_for_the_State_of_the_system_after_completion_provided_by_the_USER))
</postconditions>
</use_case>

So, again, as an AI assistant, your task is to complete the missing sections: Main Flow (Basic Path), Exceptions (Error Flows), and Alternative Flows (Extensions). Follow these steps:

1. Analyze the provided information in the use case.
2. Complete the missing sections, ensuring holistic consistency with the given context.
3. Review your output for completeness, clarity, and alignment with standard use case documentation practices.

Wrap your analysis and planning process inside <analysis> tags. In your analysis:
a. Analyze the given information
b. List potential exceptions and alternative flows
c. Outline the main flow steps

For the Main Flow (Basic Path), provide a numbered list of steps, clearly indicating actor and system actions. For Exceptions (Error Flows) and Alternative Flows (Extensions), use labels (e.g., E1, AF1) and describe specific scenarios deviating from the main flow.

Ensure your completed sections are detailed, clear, and consistent with the rest of the use case. Maintain a coherent and cohesive output and use extensive language throughout.

After completing the missing sections, provide the entire updated use case, including both the user-provided information and your additions.

<example>
<brief_description>
This use case describes how a customer completes an online purchase, from reviewing the cart to receiving an order confirmation.
</brief_description>
<use_case_name>
UC-01 - Place Order
</use_case_name>
<primary_actor>
Registered Customer
</primary_actor>
<frequency>
High; expected multiple times per day.
</frequency>
<triggers>
Customer clicks "Checkout" in the shopping cart.
</triggers>
<preconditions>
- Customer is logged in.
- Items are in the shopping cart.
- System is operational.
</preconditions>
<assumptions>
- Payment gateway is functioning.
- Customer has sufficient funds.
</assumptions>
<stakeholders>
- **Customer:** Quick, secure transaction.
- **Sales Team:** Increase sales, reduce cart abandonment.
- **Finance Department:** Accurate records.
- **Shipping Department:** Correct order details.
- **Customer Service:** Fewer support issues.
</stakeholders>
<special_requirements>
- **Performance:** Complete checkout in under 5 seconds.
- **Security:** PCI DSS compliance.
- **Usability:** Accessible per WCAG 2.1 AA.
- **Compliance:** GDPR adherence.
</special_requirements>
<postconditions>
- **Success:**
  - Order recorded.
  - Inventory updated.
  - Confirmation sent.
- **Failure:**
  - No transaction recorded.
  - Items remain in cart.
</postconditions>
<ideal_output>
<analysis>
Problem Statement: Complete the missing sections of a use case for an online purchase system, including the Main Flow (Basic Path), Exceptions (Error Flows), and Alternative Flows (Extensions).

Background Information: The use case describes how a registered customer completes an online purchase, triggered by clicking "Checkout" in the shopping cart. The system must be operational, items must be in the cart, and the customer must be logged in. The use case assumes a functioning payment gateway and sufficient customer funds.

Gather Information:
- Review the provided sections of the use case.
- Consider common steps in online purchasing processes.
- Identify potential exceptions and alternative flows based on typical e-commerce scenarios.

Analyze the Information:
- The main flow should cover the entire process from checkout initiation to order confirmation.
- Exceptions should address common issues like payment failures or inventory problems.
- Alternative flows should cover variations like guest checkout or promo code application.
- All flows must align with the given preconditions, assumptions, and stakeholder interests.

Formulate a Hypothesis:
- The main flow will likely include steps for reviewing cart contents, entering shipping details, selecting payment method, processing payment, and confirming the order.
- Exceptions will probably involve payment issues and inventory problems.
- Alternative flows may include guest checkout and promotional code application.

Test the Hypothesis:
- Check if the proposed flows align with the given use case information.
- Ensure all stakeholder interests are addressed.
- Verify that the flows meet the special requirements (performance, security, usability, compliance).

Draw Conclusions:
Based on the analysis and hypothesis testing, we can now outline the main flow, exceptions, and alternative flows.

Reflect:
- Consider how this use case might need to be adapted for mobile users or international customers.
- Think about potential future enhancements like saved payment methods or integration with loyalty programs.
</analysis>

**8. Main Flow (Basic Path):**

1. **Customer** clicks "Checkout."
2. **System** displays the checkout page.
3. **Customer** confirms or enters shipping details.
4. **Customer** selects payment method and enters payment info.
5. **System** validates information and processes payment.
6. **System** displays confirmation with order details.
7. **System** sends confirmation email.

**11. Exceptions (Error Flows):**

- **E1: Payment Declined:**
  - **System** notifies customer.
  - **Customer** retries or uses different method.
  - **Use Case** returns to payment step.
- **E2: Item Unavailable:**
  - **System** alerts customer.
  - **Customer** modifies cart.
  - **Use Case** continues.

**12. Alternative Flows (Extensions):**

- **AF1: Guest Checkout:**
  - **Customer** proceeds without login.
  - **System** collects necessary details.
  - **Use Case** continues to payment.
- **AF2: Apply Promo Code:**
  - **Customer** enters promo code.
  - **System** applies discount.
  - **Use Case** continues with updated total.
</ideal_output>
</example>

Your final output should preserve the original sections, fill in the missing ones, and reflect a structured, step-by-step narrative. Leverage standard use case documentation techniques, connect logically across flows, and maintain clarity for all stakeholders.

URL: https://ib.bsb.br/usecase

Use Case Flows

#decision-tree

#Decision-Tree Queries for Input Creation

#2: Purpose/Goal

#3: Primary Actor

#4: Trigger

#5: Preconditions

#6: Assumptions

#7: Stakeholders

#8: Frequency

#9: Special Requirements (Optional)

#10: Postconditions

#Core Path (Minimal Input)

#Extended Path (Optional)

#auxiliary

#main