A man walks through a forest along a path. The mood is tranquil, reflective, spiritually
uplifting with a hint of poetic longing::2, painting, oil on canvas, impasto. The brushwork has rich textures,
earthy palette with luminous highlights

Architecture Business Requirements Builder

Enterprise Architecture and Requirements Engineering

written by

Ted Tschopp

In Search of an Image - "No Image Associated with this article": an image by Ted Tschopp

This prompt is designed for professional architecture business requirements builder prompt designed for high-quality content generation and structured analysis.

How to Use This Prompt

Copy the prompt from the prompt content section above
Customize variables if any are marked with placeholders like {variable_name}
Paste into your AI tool (ChatGPT, Claude, Copilot, etc.)
Provide your specific input as requested by the prompt
Review and iterate on the generated output as needed

Prompt Preview

## Role
Be an expert in Azure API Management and an expert in AI.

## Context

    ### High Level Needs
      * AI models are accessed ad hoc without standardization or documentation, relying heavily ...

Best Practices

Read through the entire prompt before using to understand its requirements
Prepare any background information or context the prompt might need
Consider the intended audience and adjust examples accordingly
Test with different inputs to see the range of outputs possible

Supported AI Models

This prompt has been tested and optimized for use with the supported models listed above. It may work with other AI systems but performance may vary.

Customization Tips

Modify the tone and style instructions to match your needs
Add specific examples relevant to your domain or industry
Adjust the output format requirements if needed
Include additional constraints or requirements as necessary

Planning Management Business Strategy Architecture Requirements Engineering Documentation

## Role
Be an expert in Azure API Management and an expert in AI.

## Context

    ### High Level Needs
      * AI models are accessed ad hoc without standardization or documentation, relying heavily on the architect's knowledge for functionality use.
      * Basic documentation and a standard AI Access exists for core functionalities, with limited and inconsistent access control.
      * Standardized, well-documented APIs provide comprehensive access to AI services, supported by established AI Access management practices.
      * AI Access is monitored with metrics, managed proactively for performance and security, and designed with versioning and backward compatibility.
      * AI Access is continuously optimized with dynamic scaling, self-healing, and enhancements driven by active developer on the product teams.

    ### Key Concepts
      * A foundational framework for interacting with AI models and services via standardized interfaces.
      * Ensures consistency, scalability, and reliability across AI functionalities.
      * Provides abstraction to simplify model interactions, enhance developer experience, and improve integration with business systems.
      * Focuses on access control, performance monitoring, and ensuring backward compatibility.
      * Includes practices for proactive security, documentation, and versioning.
      * Introduces advanced capabilities such as dynamic scaling, self-healing APIs, and continual improvement via developer feedback

    ### Expected Benefits
      * Standardization: Ensures consistent access and interaction with AI services, minimizing redundancy and enhancing integration.
      * Performance & Scalability: Eases the scaling of AI capabilities to fit organizational needs and allows for updates without major interruptions.
      * Security & Governance: Improves data security and compliance through access control and monitoring.
      * Developer Productivity: Enhances usability with thorough documentation and standardized APIs. API versioning facilitates easy transitions during upgrades.
      * Cost Accounting: Establishes a centralized method for tracking AI-related expenses.

### Instructions
Build for me the list of things I want out of an implementation of Azure API Management with the AI and MCP addons to make me sucessful in meeting the concepts, and expected benefits for this effort.  For each of those things I need do the following:

    If the goals are user centric, use a User Story as the output.

    If the goals are technology, system, engineering, or tool centric, use a Requirement. 

    Format all the User Stories, and Sub-User Stories in the following format: 

    "As a [User Role Who would pay to use the app to do something], I want to [Action the User wants to do in a narrative format that tells a story], so that [Outcome, Benefit, or Value Created and complete the narrative story]."

    Following each User Story and Sub-User Story include Acceptance Criteria that is SMART using the following format:

    "[Scenario: A labor for the behavior being described]: Given [The Starting Condition for the scenario to test, include any preconditions, environmental details, or relevant information], When [A specific action that the user takes or an automated process takes within the system takes]. Then [The expected outcome of the "When", which could be used as confirmation that something happened correctly or a failure of it] And [Chain together up to three Given, When, Then statements]."

    Format all the Requirements, and sub requirements in the following format:

    "The [System that this requirement is assigned to] [Shall {for requirements} | Will {for facts or declaration of purpose} | Should = {for goals}] [Do some capability or create some business outcome] while [some set of conditions need to be met that can be measured] [under some measurable constraint]

    Each requirement / user story must include:

    1. Verification Methodology
    “Did we build the system right?” Verification confirms that the system meets specified requirements.  Please select from the following which approach should be taken.
    1. **Inspection**
        * Manual review of documents, code, models, drawings, or hardware.
        * Checks conformance to standards or requirements.
        * Example: Peer review of system design documents.
    2. **Demonstration**
        * Functional operation under specified conditions.
        * Typically qualitative and observable.
        * Example: Pressing a button to verify the system powers up.
    3. **Test**
        * Quantitative, measurable performance validation under controlled conditions.
        * May be conducted at component, subsystem, or system level.
        * Example: Thermal vacuum test on satellite components.
    4. **Analysis**
        * Use of mathematical models or simulations to verify performance.
        * Often used when physical testing is impractical.
        * Example: Structural finite element analysis for stress/strain.
    5. **Model-Based Verification**
        * Verification via formal modeling and simulation (SysML, MBSE tools).
        * Enables early lifecycle verification.
        * Includes model checking and simulation-based validation of behavior and interfaces.
    6. **Automated Verification**
        * Use of software tools to execute scripted tests and verify compliance.
        * Often used in software-intensive systems.
        * Example: Unit testing frameworks, static code analysis tools.

    1. Validation Methodoolgy
    “Did we build the right system?” - Validation ensures the system meets stakeholder needs and intended use. Please select from the following which approach should be taken.
    1. **Operational Testing**
        * Involves users operating the system in its intended environment.
        * Focused on end-to-end performance and user satisfaction.
        * Example: Flight testing of a new aircraft by experienced pilots.
    2. **Simulations and Emulation**
        * High-fidelity models or emulators replicate real-world conditions.
        * Useful when full system deployment is not yet possible.
        * Example: Power grid simulation for control software.
    3. **Prototyping**
        * Building an early or partial version to validate concepts or user needs.
        * Can be physical or digital (mock-ups, wireframes, MVPs).
        * Example: Prototype of a medical device evaluated by clinicians.
    4. **Stakeholder Review / Walkthroughs**
        * Direct engagement with stakeholders to confirm the solution aligns with their intent.
        * Structured interviews or walkthroughs of system concepts or interfaces.
    5. **Field Trials / Pilots**
        * Limited deployment in operational context with real users.
        * Helps assess readiness, usability, and integration with business processes.
        * Example: Pilot rollout of new grid management software in a single region.
    6. **Human-in-the-Loop Testing**
        * Integrates human decision-making into simulations or operations.
        * Assesses ergonomics, workflow compatibility, and cognitive load.

    1.  **INVEST Criteria**  
    For each story, confirm the following attributes. Stories may be annotated with ☑️ (Yes), ❓ (Unclear), or ❌ (No) to guide iteration:

    - [ ] **Independent** – Can be scheduled and delivered in any order without creating blockers. Stories should follow the Single Responsibility Principle.
    - [ ] **Negotiable** – Written to invite conversation, not act as fixed contracts. Only include known, high-confidence details.
    - [ ] **Valuable** – Delivers observable value to a specific user or stakeholder (e.g., end-user vs. purchaser). Prefer thin vertical slices of functionality over isolated technical layers.
    - [ ] **Estimable** – Sized and described well enough that the team can provide a meaningful effort estimate. If not, consider splitting or inserting a Spike.
    - [ ] **Small** – Fits within a single iteration or <1–2 person-weeks. Too big? Slice it until the scope feels clear and actionable.
    - [ ] **Testable** – Clearly defined success criteria. If it can’t be tested, it’s either not ready or not specific enough.

    4. Time Estimate: e.g., “~2 days for 2-person UX team”

    5. Confidence Score (1–5):

    1 = Low (many unknowns or vague input)
    3 = Moderate (acceptable but incomplete)
    5 = High (fully scoped and realistic)

    6. Strategy Summary
    Conclude with a short explanation of your planning logic (3 – 5 sentences).
    Add an optional TL;DR for non-technical stakeholders.
    Label each user story with complexity:basic or complexity:advanced where useful. Suggest escalating from basic to advanced only when warranted.

## Role
Be an expert in Azure API Management and an expert in AI.

## Context

    ### High Level Needs
      * AI models are accessed ad hoc without standardization or documentation, relying heavily on the architect's knowledge for functionality use.
      * Basic documentation and a standard AI Access exists for core functionalities, with limited and inconsistent access control.
      * Standardized, well-documented APIs provide comprehensive access to AI services, supported by established AI Access management practices.
      * AI Access is monitored with metrics, managed proactively for performance and security, and designed with versioning and backward compatibility.
      * AI Access is continuously optimized with dynamic scaling, self-healing, and enhancements driven by active developer on the product teams.

    ### Key Concepts
      * A foundational framework for interacting with AI models and services via standardized interfaces.
      * Ensures consistency, scalability, and reliability across AI functionalities.
      * Provides abstraction to simplify model interactions, enhance developer experience, and improve integration with business systems.
      * Focuses on access control, performance monitoring, and ensuring backward compatibility.
      * Includes practices for proactive security, documentation, and versioning.
      * Introduces advanced capabilities such as dynamic scaling, self-healing APIs, and continual improvement via developer feedback

    ### Expected Benefits
      * Standardization: Ensures consistent access and interaction with AI services, minimizing redundancy and enhancing integration.
      * Performance & Scalability: Eases the scaling of AI capabilities to fit organizational needs and allows for updates without major interruptions.
      * Security & Governance: Improves data security and compliance through access control and monitoring.
      * Developer Productivity: Enhances usability with thorough documentation and standardized APIs. API versioning facilitates easy transitions during upgrades.
      * Cost Accounting: Establishes a centralized method for tracking AI-related expenses.

### Instructions
Build for me the list of things I want out of an implementation of Azure API Management with the AI and MCP addons to make me sucessful in meeting the concepts, and expected benefits for this effort.  For each of those things I need do the following:

    If the goals are user centric, use a User Story as the output.

    If the goals are technology, system, engineering, or tool centric, use a Requirement. 

    Format all the User Stories, and Sub-User Stories in the following format: 

    "As a [User Role Who would pay to use the app to do something], I want to [Action the User wants to do in a narrative format that tells a story], so that [Outcome, Benefit, or Value Created and complete the narrative story]."

    Following each User Story and Sub-User Story include Acceptance Criteria that is SMART using the following format:

    "[Scenario: A labor for the behavior being described]: Given [The Starting Condition for the scenario to test, include any preconditions, environmental details, or relevant information], When [A specific action that the user takes or an automated process takes within the system takes]. Then [The expected outcome of the "When", which could be used as confirmation that something happened correctly or a failure of it] And [Chain together up to three Given, When, Then statements]."

    Format all the Requirements, and sub requirements in the following format:

    "The [System that this requirement is assigned to] [Shall {for requirements} | Will {for facts or declaration of purpose} | Should = {for goals}] [Do some capability or create some business outcome] while [some set of conditions need to be met that can be measured] [under some measurable constraint]

    Each requirement / user story must include:

    1. Verification Methodology
    “Did we build the system right?” Verification confirms that the system meets specified requirements.  Please select from the following which approach should be taken.
    1. **Inspection**
        * Manual review of documents, code, models, drawings, or hardware.
        * Checks conformance to standards or requirements.
        * Example: Peer review of system design documents.
    2. **Demonstration**
        * Functional operation under specified conditions.
        * Typically qualitative and observable.
        * Example: Pressing a button to verify the system powers up.
    3. **Test**
        * Quantitative, measurable performance validation under controlled conditions.
        * May be conducted at component, subsystem, or system level.
        * Example: Thermal vacuum test on satellite components.
    4. **Analysis**
        * Use of mathematical models or simulations to verify performance.
        * Often used when physical testing is impractical.
        * Example: Structural finite element analysis for stress/strain.
    5. **Model-Based Verification**
        * Verification via formal modeling and simulation (SysML, MBSE tools).
        * Enables early lifecycle verification.
        * Includes model checking and simulation-based validation of behavior and interfaces.
    6. **Automated Verification**
        * Use of software tools to execute scripted tests and verify compliance.
        * Often used in software-intensive systems.
        * Example: Unit testing frameworks, static code analysis tools.

    1. Validation Methodoolgy
    “Did we build the right system?” - Validation ensures the system meets stakeholder needs and intended use. Please select from the following which approach should be taken.
    1. **Operational Testing**
        * Involves users operating the system in its intended environment.
        * Focused on end-to-end performance and user satisfaction.
        * Example: Flight testing of a new aircraft by experienced pilots.
    2. **Simulations and Emulation**
        * High-fidelity models or emulators replicate real-world conditions.
        * Useful when full system deployment is not yet possible.
        * Example: Power grid simulation for control software.
    3. **Prototyping**
        * Building an early or partial version to validate concepts or user needs.
        * Can be physical or digital (mock-ups, wireframes, MVPs).
        * Example: Prototype of a medical device evaluated by clinicians.
    4. **Stakeholder Review / Walkthroughs**
        * Direct engagement with stakeholders to confirm the solution aligns with their intent.
        * Structured interviews or walkthroughs of system concepts or interfaces.
    5. **Field Trials / Pilots**
        * Limited deployment in operational context with real users.
        * Helps assess readiness, usability, and integration with business processes.
        * Example: Pilot rollout of new grid management software in a single region.
    6. **Human-in-the-Loop Testing**
        * Integrates human decision-making into simulations or operations.
        * Assesses ergonomics, workflow compatibility, and cognitive load.

    1.  **INVEST Criteria**  
    For each story, confirm the following attributes. Stories may be annotated with ☑️ (Yes), ❓ (Unclear), or ❌ (No) to guide iteration:

    - [ ] **Independent** – Can be scheduled and delivered in any order without creating blockers. Stories should follow the Single Responsibility Principle.
    - [ ] **Negotiable** – Written to invite conversation, not act as fixed contracts. Only include known, high-confidence details.
    - [ ] **Valuable** – Delivers observable value to a specific user or stakeholder (e.g., end-user vs. purchaser). Prefer thin vertical slices of functionality over isolated technical layers.
    - [ ] **Estimable** – Sized and described well enough that the team can provide a meaningful effort estimate. If not, consider splitting or inserting a Spike.
    - [ ] **Small** – Fits within a single iteration or <1–2 person-weeks. Too big? Slice it until the scope feels clear and actionable.
    - [ ] **Testable** – Clearly defined success criteria. If it can’t be tested, it’s either not ready or not specific enough.

    4. Time Estimate: e.g., “~2 days for 2-person UX team”

    5. Confidence Score (1–5):

    1 = Low (many unknowns or vague input)
    3 = Moderate (acceptable but incomplete)
    5 = High (fully scoped and realistic)

    6. Strategy Summary
    Conclude with a short explanation of your planning logic (3 – 5 sentences).
    Add an optional TL;DR for non-technical stakeholders.
    Label each user story with complexity:basic or complexity:advanced where useful. Suggest escalating from basic to advanced only when warranted.

Related Prompts

Architecture ABB SBB UBB Builder

Professional architecture abb sbb ubb builder prompt designed for high-quality content generation and structured anal...

Requirements Engineering Architecture Documentation

Architecture ABB TBB UBB Builder

Professional architecture abb tbb ubb builder prompt designed for high-quality content generation and structured anal...

Requirements Engineering Architecture Documentation

Architecture AI Backlog Ideas

Professional architecture ai backlog ideas prompt designed for high-quality content generation and structured analysis.

Artificial Intelligence AI Prompts Architecture Requirements Engineering Machine Learning Documentation

Architecture AI Document Generator

Professional architecture ai document generator prompt designed for high-quality content generation and structured an...

Artificial Intelligence AI Prompts Architecture Requirements Engineering Machine Learning Documentation

Architecture Application Architecture as Markdown

Professional architecture application architecture as markdown prompt designed for high-quality content generation an...

Requirements Engineering Architecture Documentation

Automation Architecture Designer

Professional automation architecture designer prompt designed for high-quality content generation and structured anal...

Requirements Engineering Architecture Documentation

Architecture AVD as Markdown

Professional architecture avd as markdown prompt designed for high-quality content generation and structured analysis.

Requirements Engineering Architecture Documentation

Architecture Building Block

Professional architecture building block prompt designed for high-quality content generation and structured analysis.

Requirements Engineering Architecture Documentation

Architecture Business Architecture as Markdown

Professional architecture business architecture as markdown prompt designed for high-quality content generation and s...

Planning Management Business Strategy Architecture Requirements Engineering Documentation

Business Business Skills Prompts

Professional business business skills prompts prompt designed for high-quality content generation and structured anal...

Planning Business Strategy Management

Architecture Data Architecture as Markdown

Professional architecture data architecture as markdown prompt designed for high-quality content generation and struc...

Requirements Engineering Architecture Documentation

Business Lean Six Sigma Analysis

Professional business lean six sigma analysis prompt designed for high-quality content generation and structured anal...

Planning Business Strategy Management

Architecture Microsoft Power Automate Systems Architect

Professional architecture microsoft power automate systems architect prompt designed for high-quality content generat...

Requirements Engineering Architecture Documentation

Business Objectives Key Results

Professional business objectives key results prompt designed for high-quality content generation and structured analy...

Planning Business Strategy Management

Architecture Power Platform Design

Professional architecture power platform design prompt designed for high-quality content generation and structured an...

Requirements Engineering Architecture Documentation

Architecture PRD Agent

Professional architecture prd agent prompt designed for high-quality content generation and structured analysis.

Requirements Engineering Architecture Documentation

Architecture PRD Generator

Professional architecture prd generator prompt designed for high-quality content generation and structured analysis.

Requirements Engineering Architecture Documentation

Architecture Product Requirements Document (PRD) for Power Platform

Professional architecture product requirements document (prd) for power platform prompt designed for high-quality con...

Requirements Engineering Architecture Documentation

Architecture Product Requirements Document (PRD) Template 2

Professional architecture product requirements document (prd) template 2 prompt designed for high-quality content gen...

Requirements Engineering Architecture Documentation

Architecture Product Requirements Document (PRD) Template

Professional architecture product requirements document (prd) template prompt designed for high-quality content gener...

Requirements Engineering Architecture Documentation

Architecture Prompt

Professional architecture prompt prompt designed for high-quality content generation and structured analysis.

Requirements Engineering Architecture Documentation

Architecture Requirements Analyst Graphs

Professional architecture requirements analyst graphs prompt designed for high-quality content generation and structu...

Requirements Engineering Architecture Documentation

Architecture Requirements Analyst Quality Review

Professional architecture requirements analyst quality review prompt designed for high-quality content generation and...

Requirements Engineering Architecture Documentation

Architecture Requirements Analyst - ISO/IEC/IEEE 29148:2018 SRS Generator

A specialized prompt for converting meeting transcripts into structured ISO/IEC/IEEE 29148:2018 System Requirements S...

Requirements Engineering Systems Analysis ISO Standards Documentation Meeting Analysis SRS Generation

Architecture Risk Assessment for IT

Professional architecture risk assessment for it prompt designed for high-quality content generation and structured a...

Requirements Engineering Architecture Documentation

Architecture Technology Architecture as Markdown

Professional architecture technology architecture as markdown prompt designed for high-quality content generation and...

Requirements Engineering Architecture Documentation

Architecture Testing Analyst

Professional architecture testing analyst prompt designed for high-quality content generation and structured analysis.

Requirements Engineering Architecture Documentation

Business Case and Requirements Assistant

A rigorous, step-by-step Agile coaching prompt that transforms vague goals into clear user stories, requirements, and...

Agile Product Management Requirements Engineering Backlog Refinement User Stories Acceptance Criteria Verification & Validation MBSE

Architecture Business Requirements Builder

How to Use This Prompt

Prompt Preview

Best Practices

Supported AI Models

Customization Tips

Related Prompts

Architecture ABB SBB UBB Builder

Architecture ABB TBB UBB Builder

Architecture AI Backlog Ideas

Architecture AI Document Generator

Architecture Application Architecture as Markdown

Automation Architecture Designer

Architecture AVD as Markdown

Architecture Building Block

Architecture Business Architecture as Markdown

Business Business Skills Prompts

Architecture Data Architecture as Markdown

Business Lean Six Sigma Analysis

Architecture Microsoft Power Automate Systems Architect

Business Objectives Key Results

Architecture Power Platform Design

Architecture PRD Agent

Architecture PRD Generator

Architecture Product Requirements Document (PRD) for Power Platform

Architecture Product Requirements Document (PRD) Template 2

Architecture Product Requirements Document (PRD) Template

Architecture Prompt

Architecture Requirements Analyst Graphs

Architecture Requirements Analyst Quality Review

Architecture Requirements Analyst - ISO/IEC/IEEE 29148:2018 SRS Generator

Architecture Risk Assessment for IT

Architecture Technology Architecture as Markdown

Architecture Testing Analyst

Business Case and Requirements Assistant

Webmentions