Labsco
bitwarden logo

requirements-elicitation

โ˜… 121

by bitwarden ยท part of bitwarden/ai-plugins

Extract complete, unambiguous requirements from specifications. Use when analyzing feature requests, processing enhancement specifications, or identifying missing information. Trigger phrases: "extract requirements", "analyze specification", "identify requirements", "clarify ambiguities". After extracting requirements, use the `work-breakdown` skill.

๐Ÿงฉ One of 7 skills in the bitwarden/ai-plugins package โ€” works on its own, and pairs well with its siblings.

This is the playbook your agent receives when the skill activates โ€” you don't need to read it to use the skill, but it's here to audit before installing.

Requirements Elicitation

Key Capabilities

  1. Extract Requirements โ€” Identify functional and non-functional requirements from multiple sources
  2. Clarify Ambiguities โ€” Flag unclear specifications and formulate targeted questions
  3. Identify Constraints โ€” Find technical, business, security, and resource limitations
  4. Categorize Requirements โ€” Organize by type (functional, non-functional, security, performance)

Approach

1. Read and Understand

  • Read entire specification thoroughly, including all referenced documents
  • Identify the primary source (main requirement) vs. supporting documentation
  • Note the scope and context of the request

2. Extract Explicit Requirements

  • Capture clearly stated requirements
  • Document exact specifications (API signatures, data formats, performance metrics)
  • Preserve technical details verbatim

3. Identify Implicit Requirements

  • Infer unstated but necessary requirements (e.g., error handling, validation, logging)
  • Consider security implications based on Bitwarden security principles (P01-P06)
  • Identify data classification needs (Vault Data, Protected Data, secure channels)

4. Flag Ambiguities and Gaps

  • Document unclear or missing information
  • Formulate specific questions to resolve ambiguities
  • Identify conflicting requirements between sources
  • Note assumptions being made

5. Document Constraints

  • Technical constraints (APIs, platforms, compatibility)
  • Security constraints (data protection, authentication, authorization)
  • Resource constraints (performance, storage, bandwidth)
  • Business constraints (timeline, scope, dependencies)

6. Create Acceptance Criteria

  • For each requirement, define testable acceptance criteria
  • Specify verification methods (commands, tests, manual checks)
  • Include edge cases and error scenarios

Bitwarden-Specific Considerations

Security Requirements

Always consider and document:

  • Data classification โ€” Is this Vault Data, Protected Data, or other?
  • Data states โ€” Requirements for data at rest, in use, in transit
  • Security channels โ€” Need for secure/trusted channels?
  • Security principles โ€” Which principles (P01-P06) apply?
  • Threat scenarios โ€” What could go wrong?

Common Bitwarden Requirement Types

  • Authentication/Authorization โ€” Who can access what?
  • Encryption โ€” What data needs protection and how?
  • Zero-knowledge โ€” Server must not have access to plaintext (P01)
  • Cross-platform โ€” Works on all Bitwarden clients?
  • Backwards compatibility โ€” Maintains existing behavior?

Example

See examples/export-functionality.md for a complete worked example.

Best Practices

Do's

  • โœ… Ask "what" questions, not "how" โ€” Focus on requirements, not implementation
  • โœ… Document assumptions explicitly โ€” Make implicit knowledge visible
  • โœ… Create testable acceptance criteria โ€” Avoid vague success measures
  • โœ… Consider all user types โ€” Free users, premium, enterprise, admins
  • โœ… Think about edge cases โ€” Empty vaults, huge vaults, network failures
  • โœ… Reference Bitwarden security principles โ€” Ground security requirements in P01-P06
  • โœ… Use Bitwarden vocabulary โ€” Standard terminology for data, channels, security

Don'ts

  • โŒ Avoid: Making technical implementation decisions โ€” That's the architect's job
  • โŒ Avoid: Assuming unstated requirements are obvious โ€” Explicit is better
  • โŒ Avoid: Generic acceptance criteria โ€” "It works" is not testable
  • โŒ Avoid: Ignoring security implications โ€” Security is never optional at Bitwarden
  • โŒ Avoid: Skipping constraints โ€” They're as important as requirements

Output Format

Organize extracted requirements in structured sections:


## Constraints

- **Technical**: [APIs, platforms, dependencies]
- **Business**: [Timeline, scope, resources]
- **Security**: [Compliance, encryption, authentication]

## Open Questions

1. [Specific question needing stakeholder input]
2. [Ambiguity requiring clarification]
3. [Missing information that blocks complete specification]

## Assumptions

- [Assumption 1: explicit statement of what's assumed]
- [Assumption 2: should be validated with stakeholders]