13 KiB

Raw Blame History

name	description	workflow_path	thisStepFile	nextStepFile	workflowFile	outputFile	advancedElicitationTask	partyModeWorkflow
step-07-constraints-lifecycle	Define design constraints, information management, policy and regulation, and lifecycle sustainability for SyRS Sections 3.10-3.13	{project-root}/_bmad/bmm/workflows/3-solutioning/create-syrs	./step-07-constraints-lifecycle.md	./step-08-verification-plan.md	{workflow_path}/workflow.md	{planning_artifacts}/syrs-{{project_name}}.md	{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml	{project-root}/_bmad/core/workflows/party-mode/workflow.md

Step 7: Constraints & Lifecycle

STEP GOAL:

Define design constraints at the system level, information management requirements, policy and regulation requirements, and lifecycle sustainability (maintenance, evolution, decommission). This step populates ISO 29148 Clause 8 Sections 3.10 (Information Management), 3.11 (Policies and Regulations), 3.12 (System Lifecycle Sustainability), and 3.13 (Design Constraints).

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 System Architecture and Requirements Engineering specialist
✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
✅ We engage in collaborative dialogue, not command-response
✅ You bring systems lifecycle engineering and governance expertise
✅ User brings organizational context, regulatory knowledge, and long-term vision

Step-Specific Rules:

🎯 Focus ONLY on constraints and lifecycle requirements (Sections 3.10-3.13)
🚫 FORBIDDEN to write verification or traceability content in this step
💬 Lifecycle sustainability must address the entire system lifespan - not just initial development
🚪 Design constraints must not duplicate architectural decisions but complement them
📐 Policy requirements must reference specific regulations or standards

EXECUTION PROTOCOLS:

🎯 Show your analysis before taking any action
⚠️ Present A/P/C menu after generating constraints and lifecycle content
💾 ONLY save when user chooses C (Continue)
📖 Update frontmatter stepsCompleted: [1, 2, 3, 4, 5, 6, 7] before loading next step
🚫 FORBIDDEN to load next step until C is selected

COLLABORATION MENUS (A/P/C):

This step will generate content and present choices:

A (Advanced Elicitation): Use discovery protocols to explore regulatory landscape or lifecycle implications
P (Party Mode): Bring multiple perspectives to evaluate constraints from governance, legal, and engineering angles
C (Continue): Save the content to the document and proceed to next step

PROTOCOL INTEGRATION:

When 'A' selected: Read fully and follow: {advancedElicitationTask}
When 'P' selected: Read fully and follow: {partyModeWorkflow}
PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
User accepts/rejects protocol changes before proceeding

CONTEXT BOUNDARIES:

Current document with Sections 1, 2, 3.1-3.9 completed
All previous requirements inform constraint and lifecycle decisions
Architecture document may define technology constraints
StRS may specify organizational and regulatory constraints
Focus on long-term system viability and governance

CONSTRAINTS AND LIFECYCLE ENGINEERING SEQUENCE:

1. Information Management (Section 3.10)

Define how the system manages information throughout its lifecycle:

Information Management Categories:

Data Retention - How long different data types must be retained
Data Archival - Requirements for moving data to long-term storage
Data Disposal - Requirements for secure data deletion/destruction
Data Classification - Categories of data sensitivity and handling rules
Data Integrity - Requirements for ensuring data accuracy and consistency
Data Migration - Requirements for moving data between system versions
Backup and Restoration - Data backup frequency and restoration requirements

For each information management requirement:

**SYS-INFO-###:** [Requirement statement about information management]

| Attribute | Value |
|-----------|-------|
| Priority | [Critical / High / Medium / Low] |
| Source | [StRS ref, Regulatory ref, or Business need] |
| V&V Method | [Inspection / Analysis / Demonstration / Test] |

2. Policies and Regulations (Section 3.11)

Define policy and regulatory requirements the system must comply with:

Policy Categories to Address:

Data Privacy Regulations - GDPR, CCPA, LGPD, PIPEDA, etc.
Industry Regulations - HIPAA, PCI-DSS, SOX, etc. as applicable
Accessibility Standards - ADA, Section 508, EN 301 549, etc.
Organizational Policies - Internal security, data handling, development policies
Export Control - If applicable, ITAR, EAR, etc.
Licensing - Open source licensing compliance requirements

For each policy/regulation requirement:

**SYS-POL-###:** [Requirement statement about policy or regulation compliance]

| Attribute | Value |
|-----------|-------|
| Priority | [Critical / High / Medium / Low] |
| Source | [Specific regulation, e.g., "GDPR Article 17"] |
| V&V Method | [Inspection / Analysis / Audit] |
| Regulation | [Full regulation name and version] |

NOTE: If no specific regulations apply, explicitly state: "No specific regulatory requirements have been identified for this system. The following organizational policies apply: [list or 'None identified']."

3. System Lifecycle Sustainability (Section 3.12)

Define requirements for the system's long-term viability:

Lifecycle Categories:

Maintenance - How the system must support ongoing maintenance
- Corrective maintenance (bug fixing)
- Adaptive maintenance (environment changes)
- Perfective maintenance (enhancements)
- Preventive maintenance (technical debt reduction)
Evolution - How the system must support planned growth
- Extensibility requirements
- Modularity requirements
- API versioning requirements
- Feature toggling capabilities
Decommission - How the system must support end-of-life
- Data export requirements
- Migration path requirements
- Graceful degradation during sunset period
- Data preservation obligations

For each lifecycle requirement:

**SYS-LIFE-###:** [Requirement statement about lifecycle sustainability]

| Attribute | Value |
|-----------|-------|
| Priority | [Critical / High / Medium / Low] |
| Source | [StRS ref, Organizational policy, or Engineering best practice] |
| V&V Method | [Inspection / Analysis / Demonstration] |
| Lifecycle Phase | [Maintenance / Evolution / Decommission] |

4. Design Constraints (Section 3.13)

Define constraints that limit the design solution space:

Constraint Categories:

Technology Constraints - Required or prohibited technologies
Standards Compliance - Required technical standards (coding standards, API standards)
Organizational Constraints - Imposed by the organization (approved vendors, platforms)
Interoperability Constraints - Must work with specific existing systems
Resource Constraints - Budget, timeline, team size limitations on design
Legacy Constraints - Requirements to maintain backward compatibility

For each design constraint:

**SYS-CON-###:** [Constraint statement]

| Attribute | Value |
|-----------|-------|
| Priority | [Critical / High / Medium / Low] |
| Source | [Architecture ref, StRS ref, or Organizational policy] |
| V&V Method | [Inspection / Analysis] |
| Constraint Type | [Technology / Standard / Organizational / Interoperability / Resource / Legacy] |

NOTE: Design constraints should complement, not duplicate, architectural decisions. If the Architecture document specifies technology choices, reference them here as constraints on the system design rather than restating them.

5. Cross-Reference Check

Verify constraints and lifecycle requirements are consistent with:

Security requirements from Section 3.5 (data handling, compliance)
Operational requirements from Sections 3.6-3.9 (maintenance, environment)
Interface requirements from Section 3.2 (interoperability constraints)
Architecture document decisions (if available)

6. Generate Constraints and Lifecycle Content

Prepare the content to replace the Sections 3.10-3.13 placeholders:

Content Structure:

### 3.10 Information Management

[Information management requirements with SYS-INFO-### format]

### 3.11 Policies and Regulations

[Policy and regulation requirements with SYS-POL-### format]

### 3.12 System Lifecycle Sustainability

#### 3.12.1 Maintenance Requirements
[Maintenance requirements with SYS-LIFE-### format]

#### 3.12.2 Evolution Requirements
[Evolution requirements with SYS-LIFE-### format]

#### 3.12.3 Decommission Requirements
[Decommission requirements with SYS-LIFE-### format]

### 3.13 Design Constraints

[Design constraint requirements with SYS-CON-### format]

Show the generated content and present choices:

"I've defined constraints and lifecycle requirements covering information management, policies, sustainability, and design constraints.

Constraints & Lifecycle Summary:

Information Management: {{info_count}} requirements
Policies and Regulations: {{pol_count}} requirements
Lifecycle Sustainability: {{life_count}} requirements (maintenance: {{m}}, evolution: {{e}}, decommission: {{d}})
Design Constraints: {{con_count}} constraints

Here's what I'll add to the SyRS document (Sections 3.10-3.13):

[Show the complete markdown content from step 6]

What would you like to do? [A] Advanced Elicitation - Explore regulatory landscape or lifecycle implications in depth [P] Party Mode - Evaluate constraints from governance, legal, and engineering perspectives [C] Continue - Save these requirements and proceed to verification planning"

If 'A' (Advanced Elicitation):

Read fully and follow: {advancedElicitationTask} with the current constraints and lifecycle requirements
Process enhanced insights about regulatory or lifecycle concerns
Ask user: "Accept these enhancements to the constraints and lifecycle requirements? (y/n)"
If yes: Update content with improvements, then return to A/P/C menu
If no: Keep original content, then return to A/P/C menu

If 'P' (Party Mode):

Read fully and follow: {partyModeWorkflow} with the current constraints and lifecycle requirements
Process collaborative improvements to constraint coverage
Ask user: "Accept these changes to the constraints and lifecycle requirements? (y/n)"
If yes: Update content with improvements, then return to A/P/C menu
If no: Keep original content, then return to A/P/C menu

If 'C' (Continue):

Write the final content to Sections 3.10-3.13 in {outputFile}
Update frontmatter: stepsCompleted: [1, 2, 3, 4, 5, 6, 7]
Load {nextStepFile}

APPEND TO DOCUMENT:

When user selects 'C', replace the placeholder content in Sections 3.10, 3.11, 3.12, and 3.13 of the output document with the finalized content.

SUCCESS METRICS:

✅ Information management covers retention, archival, disposal, and integrity ✅ Policy requirements reference specific regulations and standards ✅ Lifecycle sustainability addresses maintenance, evolution, AND decommission ✅ Design constraints complement (not duplicate) architectural decisions ✅ Each requirement uses appropriate identifier format (SYS-INFO, SYS-POL, SYS-LIFE, SYS-CON) ✅ Each requirement has Enterprise attributes ✅ Constraints cross-referenced with architecture document ✅ A/P/C menu presented and handled correctly ✅ Content properly written to document when C selected

FAILURE MODES:

❌ Ignoring lifecycle sustainability (common oversight) ❌ Not addressing decommission requirements ❌ Vague policy requirements without specific regulation references ❌ Duplicating architectural decisions as constraints ❌ Missing information management for data-intensive systems ❌ Missing Enterprise attributes on any requirement ❌ Not presenting A/P/C menu after content generation

❌ CRITICAL: Reading only partial step file - leads to incomplete understanding and poor decisions ❌ CRITICAL: Proceeding with 'C' without fully reading and understanding the next step file ❌ CRITICAL: Making decisions without complete understanding of step requirements and protocols

NEXT STEP:

After user selects 'C' and content is saved to document, load ./step-08-verification-plan.md to create the verification plan for all system requirements.

Remember: Do NOT proceed to step-08 until user explicitly selects 'C' from the A/P/C menu and content is saved!

13 KiB

Raw Blame History

Step 7: Constraints & Lifecycle

STEP GOAL:

MANDATORY EXECUTION RULES (READ FIRST):

Universal Rules:

Role Reinforcement:

Step-Specific Rules:

EXECUTION PROTOCOLS:

COLLABORATION MENUS (A/P/C):

PROTOCOL INTEGRATION:

CONTEXT BOUNDARIES:

CONSTRAINTS AND LIFECYCLE ENGINEERING SEQUENCE:

1. Information Management (Section 3.10)

2. Policies and Regulations (Section 3.11)

3. System Lifecycle Sustainability (Section 3.12)

4. Design Constraints (Section 3.13)

5. Cross-Reference Check

6. Generate Constraints and Lifecycle Content

Content Structure:

7. Present Content and Menu

8. Handle Menu Selection

If 'A' (Advanced Elicitation):

If 'P' (Party Mode):

If 'C' (Continue):

APPEND TO DOCUMENT:

SUCCESS METRICS:

FAILURE MODES:

NEXT STEP:

13 KiB Raw Blame History

Step 7: Constraints & Lifecycle

STEP GOAL:

MANDATORY EXECUTION RULES (READ FIRST):

Universal Rules:

Role Reinforcement:

Step-Specific Rules:

EXECUTION PROTOCOLS:

COLLABORATION MENUS (A/P/C):

PROTOCOL INTEGRATION:

CONTEXT BOUNDARIES:

CONSTRAINTS AND LIFECYCLE ENGINEERING SEQUENCE:

1. Information Management (Section 3.10)

2. Policies and Regulations (Section 3.11)

3. System Lifecycle Sustainability (Section 3.12)

4. Design Constraints (Section 3.13)

5. Cross-Reference Check

6. Generate Constraints and Lifecycle Content

Content Structure:

7. Present Content and Menu

8. Handle Menu Selection

If 'A' (Advanced Elicitation):

If 'P' (Party Mode):

If 'C' (Continue):

APPEND TO DOCUMENT:

SUCCESS METRICS:

FAILURE MODES:

NEXT STEP:

13 KiB

Raw Blame History