feat(strs): add ISO 29148 Clause 7 Stakeholder Requirements Specification workflow
Create complete StRS workflow for Enterprise track with: - ISO 29148 Clause 7 compliant template (strs-template.md) - Main workflow file with step-file architecture - 8 guided steps: init, stakeholder identification, business context, operational requirements, user requirements, operational concept, project constraints, final review - Quality checklist covering all ISO 29148 Clause 7 sections - A/P/C menu support on all content steps - Product Brief as primary input document - Cross-section consistency validation in review step Part of ISO 29148 compliance initiative (Wave 1). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Tolga Karatas
parent
2d134314c9
commit
378f96cd43
|
|
@ -0,0 +1,102 @@
|
|||
# StRS Quality Checklist (ISO 29148 Clause 7)
|
||||
|
||||
Use this checklist to validate StRS completeness and quality.
|
||||
|
||||
## Document Structure
|
||||
|
||||
- [ ] All ISO 29148 Clause 7 sections are present
|
||||
- [ ] Frontmatter includes version, status, and workflow tracking
|
||||
- [ ] Document follows the approved template structure
|
||||
- [ ] All sections contain substantive content (no empty placeholders)
|
||||
|
||||
## Section 1: Introduction & Stakeholders
|
||||
|
||||
- [ ] Business purpose is clearly stated
|
||||
- [ ] Business scope is defined
|
||||
- [ ] Business overview provides sufficient context
|
||||
- [ ] Definitions and acronyms section is present
|
||||
- [ ] All stakeholders are identified with category, interest, and influence levels
|
||||
- [ ] Each stakeholder has a profile with needs vs. wants distinction
|
||||
- [ ] Stakeholder relationships and conflicts are analyzed
|
||||
- [ ] Priority ordering for conflicting needs is established
|
||||
|
||||
## Section 2: References
|
||||
|
||||
- [ ] All referenced documents are listed
|
||||
- [ ] Standards and regulations are referenced
|
||||
- [ ] References are traceable (version, date, source)
|
||||
|
||||
## Section 3: Business Management Requirements
|
||||
|
||||
- [ ] Business environment is documented (market, competition, technology)
|
||||
- [ ] Business objectives are SMART (Specific, Measurable, Achievable, Relevant, Time-bound)
|
||||
- [ ] Business model is articulated (value creation, revenue, costs)
|
||||
- [ ] Information environment is mapped (existing systems, data flows)
|
||||
- [ ] Business policies and rules are identified
|
||||
|
||||
## Section 4: Business Operational Requirements
|
||||
|
||||
- [ ] Key business processes are mapped (trigger, actors, steps, outcome)
|
||||
- [ ] Operational policies and constraints are documented
|
||||
- [ ] All operational modes are defined (normal, degraded, maintenance, emergency)
|
||||
- [ ] Operational quality expectations are specified
|
||||
- [ ] Business structure context is captured
|
||||
|
||||
## Section 5: User Requirements
|
||||
|
||||
- [ ] All user types are identified and categorized
|
||||
- [ ] Each user type has a detailed profile (proficiency, goals, frustrations)
|
||||
- [ ] Personnel requirements are defined (training, support, staffing)
|
||||
- [ ] User interaction requirements are captured (devices, connectivity, languages)
|
||||
- [ ] Accessibility needs are documented per user type
|
||||
|
||||
## Section 6: Proposed System Concept
|
||||
|
||||
- [ ] Operational concept provides clear picture of system in action
|
||||
- [ ] At least 3 operational scenarios are documented
|
||||
- [ ] Scenarios cover happy path, exceptions, and cross-user interactions
|
||||
- [ ] Each scenario has actors, preconditions, steps, postconditions, and variations
|
||||
- [ ] Scenario coverage matrix validates completeness against user types and processes
|
||||
|
||||
## Section 7: Project Constraints
|
||||
|
||||
- [ ] Budget and cost constraints are documented
|
||||
- [ ] Schedule and timeline constraints are identified
|
||||
- [ ] Technology and platform constraints are listed
|
||||
- [ ] Environmental constraints are captured
|
||||
- [ ] Regulatory and compliance constraints are explicitly identified
|
||||
- [ ] Organizational constraints are documented
|
||||
|
||||
## Section 8: Appendices
|
||||
|
||||
- [ ] Assumptions are documented separately from verified facts
|
||||
- [ ] Dependencies are listed
|
||||
- [ ] Abbreviations and acronyms glossary is complete
|
||||
|
||||
## Cross-Section Consistency
|
||||
|
||||
- [ ] Stakeholder names are used consistently throughout
|
||||
- [ ] Business objectives align with operational requirements
|
||||
- [ ] User profiles match actors in operational scenarios
|
||||
- [ ] Constraints don't contradict requirements
|
||||
- [ ] All abbreviations appear in the glossary
|
||||
|
||||
## Quality Criteria (Per Requirement)
|
||||
|
||||
- [ ] Each requirement is necessary (traces to a stakeholder need)
|
||||
- [ ] Each requirement is implementation-free (states WHAT, not HOW)
|
||||
- [ ] Each requirement is unambiguous (single interpretation)
|
||||
- [ ] Each requirement is consistent with other requirements
|
||||
- [ ] Each requirement is complete (sufficient detail)
|
||||
- [ ] Each requirement is singular (one requirement per statement)
|
||||
- [ ] Each requirement is feasible within stated constraints
|
||||
- [ ] Each requirement is traceable (has source reference)
|
||||
- [ ] Each requirement is verifiable (can be tested or inspected)
|
||||
|
||||
## Downstream Readiness
|
||||
|
||||
- [ ] StRS provides sufficient input for PRD/SRS creation
|
||||
- [ ] Stakeholder requirements are traceable (have IDs for RTM)
|
||||
- [ ] Business objectives can be decomposed into functional requirements
|
||||
- [ ] Operational scenarios inform user journey creation in PRD
|
||||
- [ ] Constraints inform architecture decisions
|
||||
|
|
@ -0,0 +1,197 @@
|
|||
---
|
||||
name: 'step-01-init'
|
||||
description: 'Initialize the StRS workflow by detecting continuation state and loading input documents'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-02-stakeholder-identification.md'
|
||||
outputFile: '{planning_artifacts}/strs-{{project_name}}.md'
|
||||
|
||||
# Template References
|
||||
strsTemplate: '../templates/strs-template.md'
|
||||
---
|
||||
|
||||
# Step 1: StRS Initialization
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Initialize the StRS workflow by detecting continuation state, loading the Product Brief and other input documents, and setting up the document structure.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a Requirements Engineering specialist facilitating ISO 29148 compliance
|
||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring structured requirements thinking, while the user brings domain expertise and stakeholder knowledge
|
||||
- ✅ Maintain collaborative discovery tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on initialization and setup - no content generation yet
|
||||
- 🚫 FORBIDDEN to look ahead to future steps or assume knowledge from them
|
||||
- 💬 Approach: Systematic setup with clear reporting to user
|
||||
- 📋 Detect existing workflow state and handle continuation properly
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis of current state before taking any action
|
||||
- 💾 Initialize document structure and update frontmatter appropriately
|
||||
- 📖 Set up frontmatter `stepsCompleted: [1]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C' (Continue)
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Variables from workflow.md are available in memory
|
||||
- Focus: Workflow initialization and document setup only
|
||||
- Limits: Don't assume knowledge from other steps or create content yet
|
||||
- Dependencies: Configuration loaded from workflow.md initialization
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Check for Existing Workflow State
|
||||
|
||||
First, check if the output document already exists:
|
||||
|
||||
**Workflow State Detection:**
|
||||
|
||||
- Look for file `{outputFile}`
|
||||
- If exists, read the complete file including frontmatter
|
||||
- If not exists, this is a fresh workflow
|
||||
|
||||
### 2. Handle Continuation (If Document Exists)
|
||||
|
||||
If the document exists and has frontmatter with `stepsCompleted`:
|
||||
|
||||
**Continuation Protocol:**
|
||||
|
||||
- Determine which step to resume from based on `stepsCompleted` array
|
||||
- Report to user what has been completed and what remains
|
||||
- Offer to continue from the next incomplete step
|
||||
- Load the appropriate step file based on last completed step
|
||||
|
||||
### 3. Fresh Workflow Setup (If No Document)
|
||||
|
||||
If no document exists or no `stepsCompleted` in frontmatter:
|
||||
|
||||
#### A. Input Document Discovery
|
||||
|
||||
Load context documents using smart discovery. Documents can be in the following locations:
|
||||
- {planning_artifacts}/**
|
||||
- {output_folder}/**
|
||||
- {product_knowledge}/**
|
||||
- docs/**
|
||||
|
||||
Also - when searching - documents can be a single markdown file, or a folder with an index and multiple files.
|
||||
|
||||
**REQUIRED Input (Product Brief):**
|
||||
Try to discover the Product Brief:
|
||||
- `*product-brief*.md` or `*brief*.md`
|
||||
- The Product Brief is the PRIMARY input for StRS creation - it provides business vision, target audience, and market context
|
||||
|
||||
**Optional Inputs:**
|
||||
- Brainstorming Reports (`*brainstorming*.md`)
|
||||
- Research Documents (`*research*.md`)
|
||||
- Project Documentation (in `{product_knowledge}` or `docs` folder)
|
||||
- Project Context (`**/project-context.md`)
|
||||
|
||||
<critical>Confirm what you have found with the user, along with asking if the user wants to provide anything else. The Product Brief is strongly recommended - if not found, warn the user that StRS quality will be impacted. Only after this confirmation will you proceed to follow the loading rules.</critical>
|
||||
|
||||
**Loading Rules:**
|
||||
|
||||
- Load ALL discovered files completely that the user confirmed or provided (no offset/limit)
|
||||
- The Product Brief content should be biased throughout the entire workflow process
|
||||
- For sharded folders, load ALL files to get complete picture, using the index first
|
||||
- Track all successfully loaded files in frontmatter `inputDocuments` array
|
||||
|
||||
#### B. Create Initial Document
|
||||
|
||||
**Document Setup:**
|
||||
|
||||
- Copy the template from `{strsTemplate}` to `{outputFile}`, and update the frontmatter fields
|
||||
|
||||
#### C. Present Initialization Results
|
||||
|
||||
**Setup Report to User:**
|
||||
"Welcome {{user_name}}! I've set up your Stakeholder Requirements Specification workspace for {{project_name}}.
|
||||
|
||||
**What is an StRS?**
|
||||
The Stakeholder Requirements Specification (ISO 29148 Clause 7) captures WHAT stakeholders need from the system - their business requirements, operational needs, user profiles, and project constraints. It bridges your Product Brief (business vision) and the PRD/SRS (detailed software requirements).
|
||||
|
||||
**Document Setup:**
|
||||
|
||||
- Created: `{outputFile}` from ISO 29148 template
|
||||
- Initialized frontmatter with workflow state
|
||||
|
||||
**Input Documents Discovered:**
|
||||
|
||||
- Product Brief: {found or "NOT FOUND - strongly recommended"}
|
||||
- Research: {number of research files loaded or "None found"}
|
||||
- Brainstorming: {number of brainstorming files loaded or "None found"}
|
||||
- Project docs: {number of project files loaded or "None found"}
|
||||
|
||||
**Files loaded:** {list of specific file names or "No additional documents found"}
|
||||
|
||||
**We'll work through 7 sections together:**
|
||||
1. Stakeholder Identification & Analysis
|
||||
2. Business Context (objectives, model, environment)
|
||||
3. Operational Requirements (processes, constraints, modes)
|
||||
4. User Requirements (profiles, personas, needs)
|
||||
5. Operational Concept & Scenarios
|
||||
6. Project Constraints (budget, timeline, environment)
|
||||
7. Final Review & Quality Check
|
||||
|
||||
Do you have any other documents you'd like me to include, or shall we continue?"
|
||||
|
||||
### 4. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select:** [C] Continue to Stakeholder Identification (Step 2 of 8)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Update frontmatter with `stepsCompleted: [1]`, then read fully and follow: {nextStepFile}
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [setup completion is achieved and frontmatter properly updated], will you then read fully and follow: `{nextStepFile}` to begin stakeholder identification.
|
||||
|
||||
---
|
||||
|
||||
## SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Existing workflow detected and properly handled for continuation
|
||||
- Fresh workflow initialized with ISO 29148 template and proper frontmatter
|
||||
- Product Brief discovered and loaded (primary input)
|
||||
- Input documents discovered and loaded using smart discovery
|
||||
- All discovered files tracked in frontmatter `inputDocuments`
|
||||
- User informed about StRS purpose and workflow structure
|
||||
- Menu presented and user input handled correctly
|
||||
- Frontmatter updated with `stepsCompleted: [1]` before proceeding
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Proceeding with fresh initialization when existing workflow exists
|
||||
- Not loading Product Brief when available
|
||||
- Not warning user if Product Brief is missing
|
||||
- Not updating frontmatter with discovered input documents
|
||||
- Creating document without proper template structure
|
||||
- Not reporting discovered documents to user clearly
|
||||
- Proceeding without user selecting 'C' (Continue)
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -0,0 +1,208 @@
|
|||
---
|
||||
name: 'step-02-stakeholder-identification'
|
||||
description: 'Identify and analyze all stakeholders and their relationships to the system'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-03-business-context.md'
|
||||
outputFile: '{planning_artifacts}/strs-{{project_name}}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 2: Stakeholder Identification & Analysis
|
||||
|
||||
**Progress: Step 2 of 8** - Next: Business Context
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
|
||||
- ✅ ALWAYS treat this as collaborative discovery between expert peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on identifying ALL stakeholders who have interest in or are affected by the system
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating stakeholder content
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Product Brief content is the primary source for stakeholder discovery
|
||||
- All loaded input documents should inform stakeholder identification
|
||||
- Focus on WHO has stakes in this system, not WHAT the system does
|
||||
- ISO 29148 requires clear stakeholder categorization
|
||||
|
||||
## STAKEHOLDER IDENTIFICATION SEQUENCE:
|
||||
|
||||
### 1. Explain Stakeholder Identification Purpose
|
||||
|
||||
Start by explaining why stakeholder identification matters:
|
||||
|
||||
**Purpose:**
|
||||
ISO 29148 requires formal identification of all parties who have interest in, are affected by, or can influence the system. This ensures no stakeholder group is overlooked and their needs are captured.
|
||||
|
||||
**Stakeholder Categories to Explore:**
|
||||
- **Users** - People who will directly interact with the system
|
||||
- **Acquirers/Customers** - People who purchase or commission the system
|
||||
- **Operators** - People who maintain or administer the system
|
||||
- **Regulators** - Bodies that govern or regulate the domain
|
||||
- **Sponsors** - People funding or authorizing the project
|
||||
- **Developers/Maintainers** - People who build and maintain the system
|
||||
- **Support Staff** - People providing user support
|
||||
- **Affected Parties** - People indirectly affected (competitors, displaced workers, etc.)
|
||||
|
||||
### 2. Extract Stakeholders from Product Brief
|
||||
|
||||
Systematically review the Product Brief to identify stakeholders:
|
||||
|
||||
**Extract From:**
|
||||
- Target audience / user definitions → Primary users
|
||||
- Business model → Customers, partners, revenue stakeholders
|
||||
- Market context → Competitors, regulators
|
||||
- Technical context → Development team, operations team
|
||||
- Success criteria → Who benefits from success?
|
||||
|
||||
### 3. Collaborative Stakeholder Discovery
|
||||
|
||||
Engage the user to validate and expand the stakeholder list:
|
||||
|
||||
**Key Questions:**
|
||||
- "Who will use this system daily? Are there different user types?"
|
||||
- "Who is paying for this? Who decides if the project continues?"
|
||||
- "Are there regulatory bodies or compliance requirements?"
|
||||
- "Who will maintain the system after launch?"
|
||||
- "Who might be negatively impacted by this system?"
|
||||
- "Are there external partners or integrations involving other organizations?"
|
||||
|
||||
### 4. Create Stakeholder Profiles
|
||||
|
||||
For each identified stakeholder, capture:
|
||||
|
||||
**Stakeholder Profile Format:**
|
||||
- **Name/Role**: Clear identifier
|
||||
- **Category**: User / Acquirer / Operator / Regulator / Sponsor / Other
|
||||
- **Interest Level**: High / Medium / Low
|
||||
- **Influence Level**: High / Medium / Low
|
||||
- **Key Concerns**: What matters most to this stakeholder
|
||||
- **Success Criteria**: How this stakeholder measures success
|
||||
- **Needs vs. Wants**: Distinguish essential needs from desirable features
|
||||
|
||||
### 5. Analyze Stakeholder Relationships
|
||||
|
||||
Map relationships and potential conflicts:
|
||||
|
||||
**Analysis Points:**
|
||||
- Which stakeholders have conflicting needs?
|
||||
- Which stakeholders have the most influence on requirements?
|
||||
- Which stakeholders are most affected by system success/failure?
|
||||
- What is the priority order when stakeholder needs conflict?
|
||||
|
||||
### 6. Generate Stakeholder Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
```markdown
|
||||
## 1. Introduction
|
||||
|
||||
### 1.1 Business Purpose
|
||||
|
||||
[Business purpose derived from Product Brief - why this system is being built]
|
||||
|
||||
### 1.2 Business Scope
|
||||
|
||||
[Scope of the business domain this system addresses]
|
||||
|
||||
### 1.3 Business Overview
|
||||
|
||||
[High-level overview of the business context]
|
||||
|
||||
### 1.4 Definitions and Acronyms
|
||||
|
||||
[Key terms and acronyms used in this document - start list, will grow through workflow]
|
||||
|
||||
### 1.5 Stakeholder Identification
|
||||
|
||||
| Stakeholder | Category | Interest | Influence | Key Concerns |
|
||||
|-------------|----------|----------|-----------|-------------- |
|
||||
| [Name/Role] | [Category] | [H/M/L] | [H/M/L] | [Primary concerns] |
|
||||
|
||||
### 1.6 Stakeholder Profiles
|
||||
|
||||
#### [Stakeholder Name/Role]
|
||||
|
||||
- **Category:** [User / Acquirer / Operator / Regulator / Sponsor / Other]
|
||||
- **Interest Level:** [High / Medium / Low]
|
||||
- **Influence Level:** [High / Medium / Low]
|
||||
- **Key Concerns:** [What matters most]
|
||||
- **Success Criteria:** [How they measure success]
|
||||
- **Needs:** [Essential requirements]
|
||||
- **Wants:** [Desirable but not essential]
|
||||
|
||||
[Repeat for each stakeholder]
|
||||
|
||||
### 1.7 Stakeholder Relationship Analysis
|
||||
|
||||
[Relationship mapping, conflict areas, priority ordering]
|
||||
```
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Present the stakeholder identification and analysis for review, then display menu:
|
||||
- Show identified stakeholders with profiles
|
||||
- Highlight any potential conflicts between stakeholder needs
|
||||
- Ask if any stakeholders are missing or profiles need adjustment
|
||||
- Present menu options naturally as part of conversation
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Business Context (Step 3 of 8)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Read fully and follow: {advancedElicitationTask} with the current stakeholder analysis, process enhanced insights, ask user acceptance, if yes update then redisplay, if no keep original then redisplay
|
||||
- IF P: Read fully and follow: {partyModeWorkflow} with stakeholder analysis, process collaborative validation, ask user acceptance, if yes update then redisplay, if no keep original then redisplay
|
||||
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: {nextStepFile}
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 6.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ All stakeholder categories explored systematically
|
||||
✅ Product Brief content used as primary source
|
||||
✅ Each stakeholder has clear profile with needs vs. wants
|
||||
✅ Stakeholder relationships and conflicts identified
|
||||
✅ Priority ordering established for conflicting needs
|
||||
✅ ISO 29148 Clause 7 Section 1 requirements addressed
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Missing key stakeholder categories (especially regulators, operators)
|
||||
❌ Not distinguishing needs from wants
|
||||
❌ Not identifying stakeholder conflicts
|
||||
❌ Generating stakeholder list without user input
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
❌ Appending content without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading next step file
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved, load {nextStepFile} to define business context.
|
||||
|
|
@ -0,0 +1,192 @@
|
|||
---
|
||||
name: 'step-03-business-context'
|
||||
description: 'Define business management requirements including objectives, business model, and information environment'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-04-operational-requirements.md'
|
||||
outputFile: '{planning_artifacts}/strs-{{project_name}}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 3: Business Context & Management Requirements
|
||||
|
||||
**Progress: Step 3 of 8** - Next: Operational Requirements
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
|
||||
- ✅ ALWAYS treat this as collaborative discovery between expert peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on business context that shapes what the system must do
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating business context content
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Stakeholder identification from Step 2 is now available in document
|
||||
- Product Brief content continues to inform this step
|
||||
- Focus on business-level requirements, NOT system design
|
||||
- ISO 29148 Clause 7 Section 3: Business Management Requirements
|
||||
|
||||
## BUSINESS CONTEXT SEQUENCE:
|
||||
|
||||
### 1. Explain Business Context Purpose
|
||||
|
||||
**Purpose:**
|
||||
ISO 29148 requires understanding the business environment, objectives, and model before defining what the system must do. This ensures system requirements are grounded in real business needs, not assumptions.
|
||||
|
||||
**Sections to Cover:**
|
||||
- Business Environment (market, competitive landscape, technology context)
|
||||
- Business Objectives and Success Measures
|
||||
- Business Model (how value is created and captured)
|
||||
- Information Environment (data flows, existing systems, integration landscape)
|
||||
|
||||
### 2. Business Environment Discovery
|
||||
|
||||
Extract and validate business environment from Product Brief and research:
|
||||
|
||||
**Key Questions:**
|
||||
- "What market forces or trends are driving this system?"
|
||||
- "Who are the main competitors and how does this system differentiate?"
|
||||
- "What technology changes or opportunities enable this system?"
|
||||
- "What regulatory or compliance environment affects this system?"
|
||||
- "What are the current pain points this system addresses?"
|
||||
|
||||
### 3. Business Objectives and Success
|
||||
|
||||
Define measurable business objectives:
|
||||
|
||||
**Key Questions:**
|
||||
- "What are the top 3 business objectives this system must achieve?"
|
||||
- "How will you measure whether these objectives are met?"
|
||||
- "What is the timeline for achieving these objectives?"
|
||||
- "What happens if these objectives are NOT met?"
|
||||
- "Are there intermediate milestones?"
|
||||
|
||||
**Objective Format:**
|
||||
Each objective should be SMART: Specific, Measurable, Achievable, Relevant, Time-bound.
|
||||
|
||||
### 4. Business Model
|
||||
|
||||
Capture how the system fits the business model:
|
||||
|
||||
**Key Questions:**
|
||||
- "How does this system generate or protect revenue?"
|
||||
- "What is the cost model (development, operations, maintenance)?"
|
||||
- "Who pays for the system and how?"
|
||||
- "What are the key business processes the system supports?"
|
||||
- "How does the system fit within the larger organizational strategy?"
|
||||
|
||||
### 5. Information Environment
|
||||
|
||||
Map the data and system landscape:
|
||||
|
||||
**Key Questions:**
|
||||
- "What existing systems must this system interact with?"
|
||||
- "What data does the system consume and produce?"
|
||||
- "Are there data governance or privacy requirements?"
|
||||
- "What is the current state of data (paper, legacy systems, manual processes)?"
|
||||
- "What are the key information flows this system must support?"
|
||||
|
||||
### 6. Business Policies and Rules
|
||||
|
||||
Identify policies that constrain the system:
|
||||
|
||||
**Key Questions:**
|
||||
- "What business policies must the system enforce?"
|
||||
- "Are there industry standards or best practices to follow?"
|
||||
- "What authorization or approval workflows exist?"
|
||||
- "Are there data retention or archiving requirements?"
|
||||
|
||||
### 7. Generate Business Context Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
```markdown
|
||||
## 2. References
|
||||
|
||||
[List of reference documents, standards, and regulations relevant to this project]
|
||||
|
||||
## 3. Business Management Requirements
|
||||
|
||||
### 3.1 Business Environment
|
||||
|
||||
[Market context, competitive landscape, technology drivers, regulatory context]
|
||||
|
||||
### 3.2 Business Objectives
|
||||
|
||||
| Objective ID | Objective | Success Measure | Timeline |
|
||||
|-------------|-----------|----------------|----------|
|
||||
| BO-001 | [Objective description] | [Measurable criteria] | [Target date] |
|
||||
|
||||
### 3.3 Business Model
|
||||
|
||||
[How the system creates, delivers, and captures value. Revenue model, cost structure, key processes supported.]
|
||||
|
||||
### 3.4 Information Environment
|
||||
|
||||
[Existing systems, data flows, integration landscape, data governance requirements]
|
||||
|
||||
### 3.5 Business Policies and Rules
|
||||
|
||||
[Business policies the system must enforce, industry standards, authorization workflows]
|
||||
```
|
||||
|
||||
### 8. Present MENU OPTIONS
|
||||
|
||||
Present the business context for review, then display menu:
|
||||
- Show synthesized business context and objectives
|
||||
- Highlight any gaps or assumptions that need validation
|
||||
- Ask if any business aspects are missing
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Operational Requirements (Step 4 of 8)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Read fully and follow: {advancedElicitationTask} with current business context, process enhanced insights, ask user acceptance, if yes update then redisplay, if no keep original then redisplay
|
||||
- IF P: Read fully and follow: {partyModeWorkflow} with business context, process collaborative validation, ask user acceptance, if yes update then redisplay, if no keep original then redisplay
|
||||
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: {nextStepFile}
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 7.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Business environment thoroughly documented
|
||||
✅ Business objectives are SMART (Specific, Measurable, Achievable, Relevant, Time-bound)
|
||||
✅ Business model clearly articulated
|
||||
✅ Information environment mapped (existing systems, data flows)
|
||||
✅ Business policies and rules identified
|
||||
✅ All content grounded in Product Brief and user input
|
||||
✅ ISO 29148 Clause 7 Section 3 requirements addressed
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Vague or unmeasurable business objectives
|
||||
❌ Missing information environment analysis
|
||||
❌ Not connecting business context to Product Brief
|
||||
❌ Generating content without user validation
|
||||
❌ Skipping business policy identification
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved, load {nextStepFile} to define operational requirements.
|
||||
|
|
@ -0,0 +1,206 @@
|
|||
---
|
||||
name: 'step-04-operational-requirements'
|
||||
description: 'Define business operational requirements including processes, constraints, operational modes, and quality expectations'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-05-user-requirements.md'
|
||||
outputFile: '{planning_artifacts}/strs-{{project_name}}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 4: Business Operational Requirements
|
||||
|
||||
**Progress: Step 4 of 8** - Next: User Requirements
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
|
||||
- ✅ ALWAYS treat this as collaborative discovery between expert peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on HOW the business operates and what the system must support operationally
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating operational requirements
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Previous steps (stakeholders, business context) are available in document
|
||||
- Focus on operational aspects - how the business runs and what the system must support
|
||||
- ISO 29148 Clause 7 Section 4: Business Operational Requirements
|
||||
|
||||
## OPERATIONAL REQUIREMENTS SEQUENCE:
|
||||
|
||||
### 1. Explain Operational Requirements Purpose
|
||||
|
||||
**Purpose:**
|
||||
Operational requirements define HOW the business currently operates (or intends to operate) and what the system must support at a business process level. These are NOT system design requirements - they describe business operations.
|
||||
|
||||
**Sections to Cover:**
|
||||
- Business Processes (what workflows the system supports)
|
||||
- Operational Policies and Constraints
|
||||
- Operational Modes (normal, degraded, maintenance, emergency)
|
||||
- Operational Quality Requirements (at business level)
|
||||
- Business Structure (organizational context)
|
||||
|
||||
### 2. Business Process Discovery
|
||||
|
||||
Map the key business processes this system supports:
|
||||
|
||||
**Key Questions:**
|
||||
- "Walk me through the main business processes this system will support"
|
||||
- "What happens before and after someone uses this system?"
|
||||
- "Are there manual processes that this system will automate?"
|
||||
- "What handoffs exist between people/departments?"
|
||||
- "What are the critical path processes that cannot fail?"
|
||||
|
||||
**For each process, capture:**
|
||||
- Process name and description
|
||||
- Trigger (what starts the process)
|
||||
- Actors involved
|
||||
- Key steps
|
||||
- Expected outcome
|
||||
- Current pain points
|
||||
|
||||
### 3. Operational Policies and Constraints
|
||||
|
||||
Identify operational boundaries:
|
||||
|
||||
**Key Questions:**
|
||||
- "What are the operating hours? Is 24/7 availability required?"
|
||||
- "Are there geographic or regional constraints?"
|
||||
- "What are the data handling policies (retention, deletion, privacy)?"
|
||||
- "Are there capacity limits or constraints?"
|
||||
- "What compliance policies affect operations?"
|
||||
|
||||
### 4. Operational Modes
|
||||
|
||||
Define how the system behaves in different states:
|
||||
|
||||
**Modes to Explore:**
|
||||
- **Normal Operation**: Standard operating conditions
|
||||
- **Degraded Mode**: What happens when parts of the system are unavailable?
|
||||
- **Maintenance Mode**: How are updates and maintenance handled?
|
||||
- **Emergency Mode**: What happens during incidents or emergencies?
|
||||
- **Peak Load**: How does the system behave under maximum load?
|
||||
|
||||
**For each mode:**
|
||||
- "What triggers this mode?"
|
||||
- "What capabilities are available/unavailable?"
|
||||
- "What stakeholders are affected?"
|
||||
- "How is normal operation restored?"
|
||||
|
||||
### 5. Operational Quality Expectations
|
||||
|
||||
Define quality expectations from a business perspective:
|
||||
|
||||
**Key Questions:**
|
||||
- "What level of availability does the business require?"
|
||||
- "What is the acceptable data loss window?"
|
||||
- "What response time expectations exist from a business perspective?"
|
||||
- "What are the business continuity requirements?"
|
||||
- "What reporting or audit capabilities are needed?"
|
||||
|
||||
### 6. Business Structure Context
|
||||
|
||||
Understand organizational context:
|
||||
|
||||
**Key Questions:**
|
||||
- "How is the organization structured around this system?"
|
||||
- "What teams or departments interact with the system?"
|
||||
- "Are there geographical distributions to consider?"
|
||||
- "What is the decision-making hierarchy for this system?"
|
||||
|
||||
### 7. Generate Operational Requirements Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
```markdown
|
||||
## 4. Business Operational Requirements
|
||||
|
||||
### 4.1 Business Processes
|
||||
|
||||
#### BP-001: [Process Name]
|
||||
|
||||
- **Trigger:** [What starts this process]
|
||||
- **Actors:** [Who is involved]
|
||||
- **Steps:** [Key process steps]
|
||||
- **Outcome:** [Expected result]
|
||||
- **Current Pain Points:** [What needs improvement]
|
||||
|
||||
[Repeat for each key process]
|
||||
|
||||
### 4.2 Operational Policies and Constraints
|
||||
|
||||
| Policy ID | Policy | Rationale | Impact |
|
||||
|-----------|--------|-----------|--------|
|
||||
| OP-001 | [Policy description] | [Why this exists] | [How it affects the system] |
|
||||
|
||||
### 4.3 Operational Modes
|
||||
|
||||
| Mode | Trigger | Available Capabilities | Unavailable | Recovery |
|
||||
|------|---------|----------------------|-------------|----------|
|
||||
| Normal | Default state | All | None | N/A |
|
||||
| Degraded | [Trigger] | [Limited set] | [Unavailable] | [Recovery process] |
|
||||
| Maintenance | [Trigger] | [Available during maintenance] | [Suspended] | [Restoration] |
|
||||
| Emergency | [Trigger] | [Critical only] | [Non-critical] | [Emergency procedures] |
|
||||
|
||||
### 4.4 Operational Quality
|
||||
|
||||
[Business-level quality expectations: availability, data loss tolerance, response expectations, business continuity]
|
||||
|
||||
### 4.5 Business Structure
|
||||
|
||||
[Organizational context, team interactions, geographical distribution]
|
||||
```
|
||||
|
||||
### 8. Present MENU OPTIONS
|
||||
|
||||
Present the operational requirements for review, then display menu:
|
||||
- Show documented business processes and operational requirements
|
||||
- Highlight any gaps in operational mode coverage
|
||||
- Ask if any processes or constraints are missing
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to User Requirements (Step 5 of 8)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Read fully and follow: {advancedElicitationTask}, process enhanced insights, ask user acceptance, update or keep, redisplay
|
||||
- IF P: Read fully and follow: {partyModeWorkflow}, process collaborative validation, ask user acceptance, update or keep, redisplay
|
||||
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: {nextStepFile}
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 7.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Key business processes mapped with triggers, actors, steps, outcomes
|
||||
✅ Operational policies and constraints identified
|
||||
✅ All operational modes defined (normal, degraded, maintenance, emergency)
|
||||
✅ Business-level quality expectations documented
|
||||
✅ Organizational structure context captured
|
||||
✅ ISO 29148 Clause 7 Section 4 requirements addressed
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Confusing operational requirements with system design requirements
|
||||
❌ Missing operational modes (especially degraded and emergency)
|
||||
❌ Not identifying operational constraints
|
||||
❌ Generating process maps without user validation
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved, load {nextStepFile} to define user requirements.
|
||||
|
|
@ -0,0 +1,203 @@
|
|||
---
|
||||
name: 'step-05-user-requirements'
|
||||
description: 'Define user requirements including user identification, profiles, and personnel requirements'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-06-operational-concept.md'
|
||||
outputFile: '{planning_artifacts}/strs-{{project_name}}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 5: User Requirements
|
||||
|
||||
**Progress: Step 5 of 8** - Next: Operational Concept & Scenarios
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
|
||||
- ✅ ALWAYS treat this as collaborative discovery between expert peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on who the users are and what they specifically need from the system
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating user requirements
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Stakeholder profiles from Step 2 are the foundation (especially User-category stakeholders)
|
||||
- Product Brief user definitions should inform user profiles
|
||||
- Focus on USER needs at a stakeholder level, not system features
|
||||
- ISO 29148 Clause 7 Section 5: User Requirements
|
||||
|
||||
## USER REQUIREMENTS SEQUENCE:
|
||||
|
||||
### 1. Explain User Requirements Purpose
|
||||
|
||||
**Purpose:**
|
||||
User requirements capture WHO will use the system and WHAT they need at a human level. These are distinct from functional requirements (which define system capabilities) - user requirements focus on the human side: skills, training, environment, and interaction expectations.
|
||||
|
||||
**Sections to Cover:**
|
||||
- User Identification (types and categories of users)
|
||||
- User Profiles (characteristics, skills, environment)
|
||||
- Personnel Requirements (staffing, training, support)
|
||||
|
||||
### 2. User Identification
|
||||
|
||||
Identify all user types from stakeholder analysis and Product Brief:
|
||||
|
||||
**Key Questions:**
|
||||
- "What distinct types of users will interact with the system?"
|
||||
- "How do these user types differ in their goals and capabilities?"
|
||||
- "Are there user types who interact only occasionally vs. daily?"
|
||||
- "Are there administrative or support user types?"
|
||||
- "Are there automated system users (APIs, integrations)?"
|
||||
|
||||
### 3. User Profile Development
|
||||
|
||||
For each user type, build a detailed profile:
|
||||
|
||||
**Profile Elements:**
|
||||
- **User Type Name**: Clear, descriptive identifier
|
||||
- **Description**: Who this user is and their role
|
||||
- **Technical Proficiency**: Low / Medium / High
|
||||
- **Domain Expertise**: Novice / Intermediate / Expert
|
||||
- **Usage Frequency**: Daily / Weekly / Monthly / Occasional
|
||||
- **Usage Environment**: Office / Mobile / Remote / Field / Varied
|
||||
- **Accessibility Needs**: Any specific accessibility requirements
|
||||
- **Key Goals**: Top 3-5 things this user wants to accomplish
|
||||
- **Frustrations**: Current pain points with existing solutions
|
||||
- **Constraints**: Limitations on how this user can interact
|
||||
|
||||
**Key Questions per User Type:**
|
||||
- "What is a day in the life of this user?"
|
||||
- "What tools do they currently use?"
|
||||
- "What are their biggest frustrations with current approaches?"
|
||||
- "How tech-savvy is this user type?"
|
||||
- "What would make them consider the system a success?"
|
||||
|
||||
### 4. Personnel Requirements
|
||||
|
||||
Define staffing and training needs:
|
||||
|
||||
**Key Questions:**
|
||||
- "Will users need training to use the system?"
|
||||
- "What level of training is acceptable (self-service, tutorial, formal)?"
|
||||
- "Are there specialized roles needed to operate the system?"
|
||||
- "What support model is expected (self-service, help desk, on-call)?"
|
||||
- "Are there regulatory requirements for user certification?"
|
||||
|
||||
### 5. User Interaction Requirements
|
||||
|
||||
Capture high-level interaction expectations:
|
||||
|
||||
**Key Questions:**
|
||||
- "What devices will users primarily use?"
|
||||
- "What are the connectivity expectations (always online, offline capable)?"
|
||||
- "What languages must the system support?"
|
||||
- "Are there cultural or regional considerations?"
|
||||
- "What is the expected learning curve?"
|
||||
|
||||
### 6. Generate User Requirements Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
```markdown
|
||||
## 5. User Requirements
|
||||
|
||||
### 5.1 User Identification
|
||||
|
||||
| User Type | Description | Usage Frequency | Technical Proficiency |
|
||||
|-----------|-------------|----------------|----------------------|
|
||||
| [Type name] | [Brief description] | [Daily/Weekly/etc.] | [Low/Medium/High] |
|
||||
|
||||
### 5.2 User Profiles
|
||||
|
||||
#### UP-001: [User Type Name]
|
||||
|
||||
- **Description:** [Who this user is]
|
||||
- **Technical Proficiency:** [Low / Medium / High]
|
||||
- **Domain Expertise:** [Novice / Intermediate / Expert]
|
||||
- **Usage Frequency:** [Daily / Weekly / Monthly / Occasional]
|
||||
- **Usage Environment:** [Office / Mobile / Remote / Field]
|
||||
- **Accessibility Needs:** [Specific requirements or "Standard"]
|
||||
- **Key Goals:**
|
||||
1. [Primary goal]
|
||||
2. [Secondary goal]
|
||||
3. [Tertiary goal]
|
||||
- **Current Frustrations:** [Pain points with existing solutions]
|
||||
- **Constraints:** [Limitations on interaction]
|
||||
|
||||
[Repeat for each user type]
|
||||
|
||||
### 5.3 Personnel Requirements
|
||||
|
||||
#### Training Requirements
|
||||
|
||||
[Training model, certification needs, learning curve expectations]
|
||||
|
||||
#### Support Model
|
||||
|
||||
[Support structure, escalation paths, response time expectations]
|
||||
|
||||
#### Staffing
|
||||
|
||||
[Specialized roles needed, team structure implications]
|
||||
|
||||
### 5.4 User Interaction Requirements
|
||||
|
||||
[Device expectations, connectivity, languages, cultural considerations]
|
||||
```
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Present the user requirements for review, then display menu:
|
||||
- Show user profiles and requirements
|
||||
- Highlight connections to stakeholder analysis from Step 2
|
||||
- Ask if any user types are missing or profiles need adjustment
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Operational Concept (Step 6 of 8)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Read fully and follow: {advancedElicitationTask}, process enhanced insights, ask user acceptance, update or keep, redisplay
|
||||
- IF P: Read fully and follow: {partyModeWorkflow}, process collaborative validation, ask user acceptance, update or keep, redisplay
|
||||
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: {nextStepFile}
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 6.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ All user types identified and categorized
|
||||
✅ Each user type has a detailed profile
|
||||
✅ Profiles include goals, frustrations, constraints, and proficiency levels
|
||||
✅ Personnel requirements (training, support, staffing) documented
|
||||
✅ User interaction requirements captured
|
||||
✅ Profiles connected to stakeholder analysis from Step 2
|
||||
✅ ISO 29148 Clause 7 Section 5 requirements addressed
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Missing user types (especially admin, support, API users)
|
||||
❌ Generic profiles without specific goals and frustrations
|
||||
❌ Not connecting to stakeholder profiles from Step 2
|
||||
❌ Skipping personnel requirements
|
||||
❌ Not capturing accessibility needs
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved, load {nextStepFile} to define operational concept and scenarios.
|
||||
|
|
@ -0,0 +1,187 @@
|
|||
---
|
||||
name: 'step-06-operational-concept'
|
||||
description: 'Define the proposed system operational concept and operational scenarios'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-07-project-constraints.md'
|
||||
outputFile: '{planning_artifacts}/strs-{{project_name}}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 6: Operational Concept & Scenarios
|
||||
|
||||
**Progress: Step 6 of 8** - Next: Project Constraints
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
|
||||
- ✅ ALWAYS treat this as collaborative discovery between expert peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on HOW the system will be used in real operational scenarios
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating operational concept content
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- All previous steps (stakeholders, business context, operational requirements, user profiles) inform scenarios
|
||||
- Focus on HOW the system operates in context, not system internals
|
||||
- ISO 29148 Clause 7 Section 6: Proposed System Concept
|
||||
|
||||
## OPERATIONAL CONCEPT SEQUENCE:
|
||||
|
||||
### 1. Explain Operational Concept Purpose
|
||||
|
||||
**Purpose:**
|
||||
The operational concept describes HOW the proposed system will work from the users' and operators' perspective. It paints a picture of the system in action - who does what, when, and how. Operational scenarios are concrete stories that illustrate the concept.
|
||||
|
||||
**Sections to Cover:**
|
||||
- Operational Concept (high-level vision of system operation)
|
||||
- Operational Scenarios (concrete day-in-the-life stories)
|
||||
|
||||
### 2. Build Operational Concept
|
||||
|
||||
Synthesize previous steps into a cohesive operational picture:
|
||||
|
||||
**Key Questions:**
|
||||
- "Describe a typical day with this system fully operational - what happens?"
|
||||
- "How does the system fit into users' existing workflows?"
|
||||
- "What changes from the current way of doing things?"
|
||||
- "How do different user types interact with each other through the system?"
|
||||
- "What is the system's role in the bigger picture (supporting tool vs. central platform)?"
|
||||
|
||||
**Operational Concept Elements:**
|
||||
- System's place in the overall business workflow
|
||||
- Key interactions between user types and the system
|
||||
- Information flows between system and external entities
|
||||
- Major system capabilities from an operational perspective
|
||||
- How the system handles transitions between operational modes
|
||||
|
||||
### 3. Create Operational Scenarios
|
||||
|
||||
Develop concrete scenarios that illustrate the operational concept:
|
||||
|
||||
**Scenario Development Guidelines:**
|
||||
|
||||
Create 3-5 key scenarios covering:
|
||||
1. **Happy Path**: Normal, successful use of core functionality
|
||||
2. **First-Time Use**: New user onboarding experience
|
||||
3. **Exception Handling**: What happens when things go wrong
|
||||
4. **Peak Load**: System under maximum expected usage
|
||||
5. **Cross-User Interaction**: Different user types working together
|
||||
|
||||
**For each scenario, capture:**
|
||||
- **Scenario Name**: Descriptive title
|
||||
- **Actors**: Who is involved
|
||||
- **Preconditions**: What must be true before the scenario starts
|
||||
- **Trigger**: What initiates the scenario
|
||||
- **Steps**: Sequential actions and system responses
|
||||
- **Postconditions**: What is true after the scenario completes
|
||||
- **Variations**: Alternative paths or edge cases
|
||||
|
||||
**Key Questions per Scenario:**
|
||||
- "Walk me through exactly what happens step by step"
|
||||
- "What could go wrong at each step?"
|
||||
- "How does the user know the step was successful?"
|
||||
- "What data is created, modified, or consumed?"
|
||||
|
||||
### 4. Validate Scenario Coverage
|
||||
|
||||
Ensure scenarios cover all key stakeholder needs:
|
||||
|
||||
**Coverage Check:**
|
||||
- Do scenarios cover all user types from Step 5?
|
||||
- Do scenarios exercise all business processes from Step 4?
|
||||
- Do scenarios address all operational modes (normal, degraded, maintenance)?
|
||||
- Are edge cases and error conditions represented?
|
||||
- Do scenarios illustrate the business objectives from Step 3?
|
||||
|
||||
### 5. Generate Operational Concept Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
```markdown
|
||||
## 6. Proposed System Concept
|
||||
|
||||
### 6.1 Operational Concept
|
||||
|
||||
[High-level narrative describing how the system operates in context. Paint a picture of the system in action - who does what, when, how. Include system's place in workflows, key interactions, information flows.]
|
||||
|
||||
### 6.2 Operational Scenarios
|
||||
|
||||
#### OS-001: [Scenario Name]
|
||||
|
||||
- **Actors:** [Who is involved]
|
||||
- **Preconditions:** [What must be true]
|
||||
- **Trigger:** [What starts this scenario]
|
||||
- **Scenario Steps:**
|
||||
1. [Actor] [action] → [System response/result]
|
||||
2. [Actor] [action] → [System response/result]
|
||||
3. [Continue for all steps]
|
||||
- **Postconditions:** [What is true after completion]
|
||||
- **Variations:**
|
||||
- [Alternative path or edge case]
|
||||
- [Error condition and handling]
|
||||
|
||||
[Repeat for each scenario]
|
||||
|
||||
### 6.3 Scenario Coverage Matrix
|
||||
|
||||
| Scenario | User Types | Business Processes | Operational Modes | Business Objectives |
|
||||
|----------|-----------|-------------------|-------------------|-------------------|
|
||||
| OS-001 | [Types covered] | [Processes covered] | [Modes covered] | [Objectives addressed] |
|
||||
```
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Present the operational concept and scenarios for review, then display menu:
|
||||
- Show operational concept narrative and scenarios
|
||||
- Highlight scenario coverage matrix
|
||||
- Ask if any scenarios are missing or need more detail
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Project Constraints (Step 7 of 8)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Read fully and follow: {advancedElicitationTask}, process enhanced insights, ask user acceptance, update or keep, redisplay
|
||||
- IF P: Read fully and follow: {partyModeWorkflow}, process collaborative validation, ask user acceptance, update or keep, redisplay
|
||||
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: {nextStepFile}
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 5.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Operational concept provides clear picture of system in action
|
||||
✅ 3-5 operational scenarios covering happy path, exceptions, and cross-user interactions
|
||||
✅ Each scenario has actors, preconditions, steps, postconditions, and variations
|
||||
✅ Scenario coverage matrix validates completeness
|
||||
✅ All user types from Step 5 appear in at least one scenario
|
||||
✅ Business processes from Step 4 are exercised by scenarios
|
||||
✅ ISO 29148 Clause 7 Section 6 requirements addressed
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Operational concept is too abstract (no concrete operational picture)
|
||||
❌ Scenarios are too vague (missing steps, actors, or postconditions)
|
||||
❌ Not covering all user types in scenarios
|
||||
❌ Only happy-path scenarios (missing error and edge cases)
|
||||
❌ Not validating scenario coverage against previous steps
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved, load {nextStepFile} to define project constraints.
|
||||
|
|
@ -0,0 +1,206 @@
|
|||
---
|
||||
name: 'step-07-project-constraints'
|
||||
description: 'Define project constraints including budget, timeline, and environmental constraints'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08-review-complete.md'
|
||||
outputFile: '{planning_artifacts}/strs-{{project_name}}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 7: Project Constraints
|
||||
|
||||
**Progress: Step 7 of 8** - Next: Final Review & Completion
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
|
||||
- ✅ ALWAYS treat this as collaborative discovery between expert peers
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on constraints that limit what and how the system can be built
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present A/P/C menu after generating constraints content
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- All previous steps inform constraint identification
|
||||
- Focus on project-level constraints that affect feasibility and scope
|
||||
- ISO 29148 Clause 7 Section 7: Project Constraints
|
||||
|
||||
## PROJECT CONSTRAINTS SEQUENCE:
|
||||
|
||||
### 1. Explain Constraints Purpose
|
||||
|
||||
**Purpose:**
|
||||
Project constraints define the boundaries within which the system must be built and operated. They are non-negotiable limitations from budget, time, technology, environment, regulations, or organizational factors. Understanding constraints early prevents unrealistic requirements.
|
||||
|
||||
**Constraint Categories:**
|
||||
- Budget and Cost Constraints
|
||||
- Schedule and Timeline Constraints
|
||||
- Technology and Platform Constraints
|
||||
- Environmental and Infrastructure Constraints
|
||||
- Regulatory and Compliance Constraints
|
||||
- Organizational and Resource Constraints
|
||||
|
||||
### 2. Budget and Cost Constraints
|
||||
|
||||
**Key Questions:**
|
||||
- "What is the budget range for this project?"
|
||||
- "Are there ongoing operational cost limits?"
|
||||
- "What are the licensing or subscription constraints?"
|
||||
- "Is there a target cost per user or transaction?"
|
||||
- "What happens if the budget is exceeded?"
|
||||
|
||||
### 3. Schedule and Timeline Constraints
|
||||
|
||||
**Key Questions:**
|
||||
- "What is the target launch date? Is it fixed or flexible?"
|
||||
- "Are there regulatory deadlines or market windows?"
|
||||
- "What are the key milestones?"
|
||||
- "Are there dependencies on external timelines (partner launches, API availability)?"
|
||||
- "What is the minimum viable timeline?"
|
||||
|
||||
### 4. Technology and Platform Constraints
|
||||
|
||||
**Key Questions:**
|
||||
- "Are there mandated technology choices (programming languages, frameworks, cloud providers)?"
|
||||
- "Are there existing systems that must be maintained or integrated with?"
|
||||
- "Are there platform requirements (iOS, Android, web, desktop)?"
|
||||
- "Are there third-party service dependencies?"
|
||||
- "Are there open source vs. commercial software policies?"
|
||||
|
||||
### 5. Environmental and Infrastructure Constraints
|
||||
|
||||
**Key Questions:**
|
||||
- "What hosting or deployment environments are available?"
|
||||
- "Are there geographic restrictions (data residency, CDN locations)?"
|
||||
- "What are the network constraints (bandwidth, latency, offline requirements)?"
|
||||
- "Are there hardware constraints for end users?"
|
||||
- "What are the development and testing environment constraints?"
|
||||
|
||||
### 6. Regulatory and Compliance Constraints
|
||||
|
||||
**Key Questions:**
|
||||
- "What regulations apply (GDPR, HIPAA, PCI-DSS, SOC2, etc.)?"
|
||||
- "Are there industry-specific standards to comply with?"
|
||||
- "What certifications are required?"
|
||||
- "Are there accessibility requirements (WCAG, Section 508)?"
|
||||
- "What audit or reporting requirements exist?"
|
||||
|
||||
### 7. Organizational and Resource Constraints
|
||||
|
||||
**Key Questions:**
|
||||
- "What team size and skill sets are available?"
|
||||
- "Are there organizational process requirements (Agile, waterfall, approvals)?"
|
||||
- "What are the decision-making constraints?"
|
||||
- "Are there vendor or contractor limitations?"
|
||||
- "What knowledge transfer or documentation requirements exist?"
|
||||
|
||||
### 8. Generate Constraints Content
|
||||
|
||||
Prepare the content to append to the document:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
```markdown
|
||||
## 7. Project Constraints
|
||||
|
||||
### 7.1 Budget and Cost Constraints
|
||||
|
||||
| Constraint ID | Constraint | Impact | Flexibility |
|
||||
|--------------|-----------|--------|-------------|
|
||||
| BC-001 | [Budget constraint] | [How it affects the project] | [Fixed / Negotiable] |
|
||||
|
||||
### 7.2 Schedule and Timeline Constraints
|
||||
|
||||
| Constraint ID | Constraint | Deadline | Flexibility |
|
||||
|--------------|-----------|----------|-------------|
|
||||
| TC-001 | [Timeline constraint] | [Date or timeframe] | [Fixed / Negotiable] |
|
||||
|
||||
### 7.3 Technology and Platform Constraints
|
||||
|
||||
| Constraint ID | Constraint | Rationale | Impact |
|
||||
|--------------|-----------|-----------|--------|
|
||||
| PC-001 | [Platform/technology constraint] | [Why this constraint exists] | [How it affects design] |
|
||||
|
||||
### 7.4 Environmental Constraints
|
||||
|
||||
[Hosting, geographic, network, hardware, and development environment constraints]
|
||||
|
||||
### 7.5 Regulatory and Compliance Constraints
|
||||
|
||||
| Constraint ID | Regulation/Standard | Requirement | Impact |
|
||||
|--------------|-------------------|-------------|--------|
|
||||
| RC-001 | [Regulation name] | [What it requires] | [How it affects the system] |
|
||||
|
||||
### 7.6 Organizational Constraints
|
||||
|
||||
[Team, process, vendor, and knowledge constraints]
|
||||
|
||||
## 8. Appendices
|
||||
|
||||
### 8.1 Assumptions
|
||||
|
||||
[List all assumptions made during StRS creation - these are statements believed to be true but not yet verified]
|
||||
|
||||
### 8.2 Dependencies
|
||||
|
||||
[List all external dependencies that could affect the project]
|
||||
|
||||
### 8.3 Abbreviations and Acronyms
|
||||
|
||||
[Complete list of all abbreviations and acronyms used in this document]
|
||||
```
|
||||
|
||||
### 9. Present MENU OPTIONS
|
||||
|
||||
Present the project constraints for review, then display menu:
|
||||
- Show all constraint categories
|
||||
- Highlight any constraints that may conflict with requirements from previous steps
|
||||
- Ask if any constraints are missing
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Final Review (Step 8 of 8)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Read fully and follow: {advancedElicitationTask}, process enhanced insights, ask user acceptance, update or keep, redisplay
|
||||
- IF P: Read fully and follow: {partyModeWorkflow}, process collaborative validation, ask user acceptance, update or keep, redisplay
|
||||
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: {nextStepFile}
|
||||
- IF Any other: help user respond, then redisplay menu
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 8.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ All constraint categories explored
|
||||
✅ Each constraint has ID, description, impact, and flexibility level
|
||||
✅ Regulatory and compliance constraints explicitly identified
|
||||
✅ Assumptions clearly separated from verified facts
|
||||
✅ Dependencies documented
|
||||
✅ Abbreviations and acronyms collected
|
||||
✅ ISO 29148 Clause 7 Section 7 requirements addressed
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Missing regulatory or compliance constraints
|
||||
❌ Not documenting assumptions separately from facts
|
||||
❌ Leaving constraint impact analysis blank
|
||||
❌ Not identifying constraint conflicts with requirements
|
||||
❌ Missing technology platform constraints
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved, load {nextStepFile} for final review and completion.
|
||||
|
|
@ -0,0 +1,149 @@
|
|||
---
|
||||
name: 'step-08-review-complete'
|
||||
description: 'Final quality review of the complete StRS document against ISO 29148 Clause 7 requirements'
|
||||
|
||||
# File References
|
||||
outputFile: '{planning_artifacts}/strs-{{project_name}}.md'
|
||||
checklistFile: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-strs/checklist.md'
|
||||
---
|
||||
|
||||
# Step 8: Final Review & Completion
|
||||
|
||||
**Progress: Step 8 of 8** - Final Step
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- 🎯 This is a REVIEW step - focus on validation, not content generation
|
||||
- 📋 Use the quality checklist to systematically verify document completeness
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Perform systematic review against ISO 29148 Clause 7
|
||||
- 📖 Load and use the quality checklist
|
||||
- 💾 Update document frontmatter to mark completion
|
||||
- ✅ Present review findings to user for final approval
|
||||
|
||||
## REVIEW SEQUENCE:
|
||||
|
||||
### 1. Load Quality Checklist
|
||||
|
||||
Read the quality checklist from: `{checklistFile}`
|
||||
|
||||
### 2. Systematic Document Review
|
||||
|
||||
Review the complete StRS document against the checklist. For each item:
|
||||
|
||||
**Check:**
|
||||
- Is the section present?
|
||||
- Is the content substantive (not placeholder text)?
|
||||
- Does it address the ISO 29148 requirement?
|
||||
- Is the content consistent with other sections?
|
||||
|
||||
### 3. Cross-Section Consistency Check
|
||||
|
||||
Verify consistency across the entire document:
|
||||
|
||||
**Consistency Checks:**
|
||||
- Stakeholder names used consistently throughout
|
||||
- Business objectives align with operational requirements
|
||||
- User profiles match the actors in operational scenarios
|
||||
- Constraints don't contradict other requirements
|
||||
- All abbreviations in glossary
|
||||
- All referenced documents in references section
|
||||
|
||||
### 4. Completeness Assessment
|
||||
|
||||
Evaluate overall document completeness:
|
||||
|
||||
**Scoring:**
|
||||
- **Complete**: All ISO 29148 Clause 7 sections present with substantive content
|
||||
- **Mostly Complete**: 1-2 minor sections missing or thin
|
||||
- **Incomplete**: Major sections missing or substantial gaps
|
||||
|
||||
### 5. Present Review Results
|
||||
|
||||
Present findings to the user:
|
||||
|
||||
**Review Report:**
|
||||
"I've completed the ISO 29148 Clause 7 quality review of your StRS.
|
||||
|
||||
**Overall Assessment:** [Complete / Mostly Complete / Incomplete]
|
||||
|
||||
**Section Coverage:**
|
||||
| Section | Status | Notes |
|
||||
|---------|--------|-------|
|
||||
| 1. Introduction & Stakeholders | [✅/⚠️/❌] | [Notes] |
|
||||
| 2. References | [✅/⚠️/❌] | [Notes] |
|
||||
| 3. Business Management Requirements | [✅/⚠️/❌] | [Notes] |
|
||||
| 4. Business Operational Requirements | [✅/⚠️/❌] | [Notes] |
|
||||
| 5. User Requirements | [✅/⚠️/❌] | [Notes] |
|
||||
| 6. Proposed System Concept | [✅/⚠️/❌] | [Notes] |
|
||||
| 7. Project Constraints | [✅/⚠️/❌] | [Notes] |
|
||||
| 8. Appendices | [✅/⚠️/❌] | [Notes] |
|
||||
|
||||
**Consistency Issues Found:** [List any issues or "None"]
|
||||
|
||||
**Recommendations:** [Any suggestions for improvement]
|
||||
|
||||
**Next Steps:**
|
||||
This StRS is now ready to serve as input for:
|
||||
1. **PRD/SRS Creation** (John - PM) - Translates stakeholder needs into software requirements
|
||||
2. **RTM Creation** - Links StRS requirements to downstream documents"
|
||||
|
||||
### 6. Finalize Document
|
||||
|
||||
**Frontmatter Updates:**
|
||||
- Add this step name to `stepsCompleted` array
|
||||
- Set `status: 'review'` (user should approve to set 'approved')
|
||||
- Set `version: '1.0'`
|
||||
|
||||
**Present Completion Menu:**
|
||||
|
||||
Display: "**StRS creation is complete!** Would you like to:
|
||||
- [R] Review and address any issues found
|
||||
- [F] Finalize the StRS as-is (status → review)
|
||||
- [A] Approve the StRS (status → approved)"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF R: Go back to the relevant section and iterate, then return to this review
|
||||
- IF F: Update frontmatter with `status: 'review'`, report completion
|
||||
- IF A: Update frontmatter with `status: 'approved'`, report completion
|
||||
|
||||
### 7. Completion Report
|
||||
|
||||
After finalization:
|
||||
|
||||
"**StRS Complete!** 🎯
|
||||
|
||||
**Document:** `{outputFile}`
|
||||
**Status:** [review / approved]
|
||||
**ISO 29148 Clause 7 Coverage:** [Complete / Mostly Complete]
|
||||
|
||||
**This StRS feeds into:**
|
||||
- PRD/SRS creation (use [CP] Create PRD with John)
|
||||
- Requirements Traceability Matrix (use [RT] with John)
|
||||
- Architecture decisions (use [CA] with Winston)
|
||||
|
||||
**Enterprise Track Next Step:**
|
||||
Consider running the Quality Gate check before proceeding to PRD creation."
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ All ISO 29148 Clause 7 sections reviewed against checklist
|
||||
✅ Cross-section consistency verified
|
||||
✅ Completeness assessment provided with clear scoring
|
||||
✅ Review findings presented clearly to user
|
||||
✅ Document frontmatter updated with final status
|
||||
✅ Next steps and downstream workflow guidance provided
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not using the quality checklist for systematic review
|
||||
❌ Marking document complete without addressing critical gaps
|
||||
❌ Not checking cross-section consistency
|
||||
❌ Not providing clear next-step guidance
|
||||
❌ Not updating document status in frontmatter
|
||||
|
||||
**Master Rule:** This review must be thorough and honest. Do NOT gloss over issues to appear complete.
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
---
|
||||
stepsCompleted: []
|
||||
inputDocuments: []
|
||||
workflowType: 'strs'
|
||||
track: 'enterprise'
|
||||
version: '1.0'
|
||||
status: 'draft'
|
||||
baseline_version: null
|
||||
---
|
||||
|
||||
# Stakeholder Requirements Specification - {{project_name}}
|
||||
|
||||
**Author:** {{user_name}}
|
||||
**Date:** {{date}}
|
||||
**ISO 29148 Reference:** Clause 7 - Stakeholder Requirements Specification
|
||||
|
|
@ -0,0 +1,64 @@
|
|||
---
|
||||
name: create-strs
|
||||
description: Create an ISO 29148 compliant Stakeholder Requirements Specification (StRS) through collaborative step-by-step discovery. Enterprise track workflow that transforms Product Brief into formal stakeholder requirements.
|
||||
track: enterprise
|
||||
---
|
||||
|
||||
# Create StRS Workflow (ISO 29148 Clause 7)
|
||||
|
||||
**Goal:** Create a comprehensive Stakeholder Requirements Specification (StRS) compliant with ISO/IEC/IEEE 29148:2018 Clause 7 through collaborative step-by-step discovery.
|
||||
|
||||
**Your Role:** In addition to your name, communication_style, and persona, you are a Requirements Engineering specialist facilitating formal stakeholder requirements capture. This is a partnership - you bring ISO 29148 expertise and structured elicitation skills, while the user brings domain knowledge and stakeholder insights. Work together as equals.
|
||||
|
||||
**Track:** This workflow is part of the **Enterprise** track. It produces the StRS document that bridges the Product Brief (business vision) and the PRD/SRS (software requirements).
|
||||
|
||||
---
|
||||
|
||||
## WORKFLOW ARCHITECTURE
|
||||
|
||||
This uses **step-file architecture** for disciplined execution:
|
||||
|
||||
### Core Principles
|
||||
|
||||
- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
|
||||
- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
|
||||
- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
|
||||
- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
|
||||
- **Append-Only Building**: Build documents by appending content as directed to the output file
|
||||
|
||||
### Step Processing Rules
|
||||
|
||||
1. **READ COMPLETELY**: Always read the entire step file before taking any action
|
||||
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
|
||||
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
|
||||
4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
|
||||
5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
|
||||
6. **LOAD NEXT**: When directed, read fully and follow the next step file
|
||||
|
||||
### Critical Rules (NO EXCEPTIONS)
|
||||
|
||||
- 🛑 **NEVER** load multiple step files simultaneously
|
||||
- 📖 **ALWAYS** read entire step file before execution
|
||||
- 🚫 **NEVER** skip steps or optimize the sequence
|
||||
- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
|
||||
- 🎯 **ALWAYS** follow the exact instructions in the step file
|
||||
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
||||
- 📋 **NEVER** create mental todo lists from future steps
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION SEQUENCE
|
||||
|
||||
### 1. Configuration Loading
|
||||
|
||||
Load and read full config from {project-root}/_bmad/bmm/config.yaml and resolve:
|
||||
|
||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
|
||||
- `communication_language`, `document_output_language`, `user_skill_level`
|
||||
- `date` as system-generated current datetime
|
||||
|
||||
✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
|
||||
|
||||
### 2. First Step EXECUTION
|
||||
|
||||
Read fully and follow: `{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-strs/steps/step-01-init.md` to begin the workflow.
|
||||
Loading…
Reference in New Issue