Overview
Glossa offers three requirement granularity levels that control how detailed your AI-generated requirements are. Choosing the right level for your project phase ensures you get requirements at the appropriate level of detail—not too vague, not overly specific.
This guide explains each level, when to use it, and how to adjust the setting.
The Three Levels
Broad Strokes
What it produces:
Fewer requirements (typically 50% fewer than Balanced)
High-level, strategic requirements
Each requirement covers broader scope
Minimal implementation details
1-2 sentence descriptions
Example requirement:
Title: "User Authentication System"
Description: "Implement secure user authentication with password reset capability and session management."
When to use:
Sales discovery - Initial scoping conversations
Early estimation - Ballpark sizing and pricing
Executive reviews - High-level overview for stakeholders
Broad project scoping - Understanding overall project shape
Benefits:
Fast to review (fewer requirements)
Good for big-picture discussions
Easy for non-technical stakeholders to understand
Helps avoid getting lost in details too early
Trade-offs:
May miss important details
Requires more interpretation later
Not ready for implementation
May need to regenerate at higher detail later
Balanced
What it produces:
Moderate number of requirements
Good level of detail for most delivery work
Clear enough to understand and discuss
Enough detail for planning without overwhelming
3-5 sentence descriptions
Example requirement:
Title: "User Password Reset Workflow"
Description: "Enable users to reset forgotten passwords via email verification link. System sends reset email to registered address, validates token expiration, allows new password entry, and confirms successful reset. Process must complete within 24 hours of request."
When to use:
Most discovery work - Standard requirements gathering
Active project planning - Fleshing out project scope
Stakeholder alignment - Getting team agreement on features
Default setting - When unsure which level to use
Benefits:
Right amount of detail for most situations
Clear enough to plan from
Not so detailed it's overwhelming
Good balance of speed and comprehensiveness
Trade-offs:
May still need additional detail for complex areas
Some requirements might feel too high-level for implementation
Might capture duplicates that need merging
Granular
What it produces:
Many detailed requirements (typically 2-3x more than Balanced)
Very specific, narrow scope per requirement
Implementation-ready level of detail
Comprehensive edge cases and scenarios
5-10+ sentence descriptions with specifics
Example requirements: Multiple granular requirements instead of one balanced requirement:
"Password Reset Email Generation and Delivery"
"Password Reset Token Validation Logic"
"Password Reset Token Expiration Handling"
"New Password Strength Requirements"
"Password Reset Success Confirmation"
When to use:
Technical deep-dives - Getting into implementation specifics
Complex feature areas - Where detail really matters
Compliance-heavy work - Need exhaustive coverage
Handoff to developers - When dev team needs complete specs
Benefits:
Comprehensive, detailed coverage
Less likely to miss edge cases
Clear enough for developers to implement
Good for complex, regulated, or critical features
Trade-offs:
Many more requirements to review
Can feel overwhelming
More duplicates to resolve
Takes longer to process and review
May include obvious details that don't need documenting
How to Choose the Right Level
By Project Phase
Sales / Initial Discovery → Broad Strokes
Quick scoping for proposals
High-level estimation
Executive buy-in conversations
Active Discovery / Planning → Balanced
Detailed requirements gathering
Team alignment discussions
Planning and prioritization
Technical Design / Handoff → Granular
Specific feature deep-dives
Developer-ready requirements
Implementation planning
By Audience
Executives / Business Stakeholders → Broad Strokes
Don't need implementation details
Want to understand scope quickly
Focus on business value
Product / Project Managers → Balanced
Need enough detail to plan
Balance clarity with manageability
Coordinate across teams
Developers / Technical Teams → Granular
Need specific implementation guidance
Want edge cases documented
Prefer comprehensive over concise
By Content Type
SOWs / Strategic docs / Business cases → Broad Strokes
High-level vision documents
Business requirement documents
Executive presentations
Discovery notes / User interviews → Balanced
Meeting transcripts
Email discussions
User feedback
Technical specs / Detailed designs → Granular
Technical documentation
API specifications
Detailed process workflows
Changing the Granularity Level
Where to Find It
Open your project
Click More then Edit Project
Find Requirement Detail & Visibility
Select: Broad Strokes, Balanced, or Granular
How It Works
Important: The granularity setting applies to files uploaded AFTER you change it.
What this means:
Existing requirements are NOT affected
Only new files uploaded use the new setting
To regenerate existing requirements, you must delete and re-upload files
Workflow for changing levels:
Adjust granularity dial in Project Settings
Upload new files (they'll use new setting)
For existing files: delete file & delete requirements → re-upload file
Using Multiple Levels in One Project
You can have requirements at different levels in the same project:
Early discovery files at Broad Strokes
Later detailed discussions at Balanced
Technical deep-dives at Granular
All coexist in same project
Best Practices
Start Broad, Then Go Deeper
Recommended progression:
First pass: Broad Strokes for overall scope
Second pass: Balanced for key features
Final pass: Granular for complex/critical areas
Why this works:
See big picture first
Avoid getting lost in details early
Focus granular effort where it matters most
Match Level to Meeting Type
Sales calls → Broad Strokes
Upload call recording at Broad Strokes
Get high-level scope quickly
Use for estimation
Discovery workshops → Balanced
Upload workshop notes at Balanced
Get actionable requirements
Use for planning
Technical design sessions → Granular
Upload design docs at Granular
Get comprehensive coverage
Use for implementation
Don't Over-Index on Granular
Granular isn't always better:
Creates many more requirements to manage
Many may be obvious and not worth documenting
More duplicates to resolve
More time to review
Use granular selectively:
Only for areas that truly need detail
Complex integrations or workflows
Compliance-critical features
Areas with lots of edge cases
Review and Refine Regardless
All levels need human review:
AI doesn't know what's important to you
May miss nuances only you understand
May generate obvious or irrelevant requirements
Always review, edit, and refine
Don't just accept AI output:
Delete irrelevant requirements
Merge duplicates
Add missing requirements manually
Edit for clarity
Common Scenarios
Scenario: Initial Sales Call
Situation: Just had first call with prospect, need to estimate project
Recommendation: Broad Strokes
Upload call recording or notes at Broad Strokes
Get 5-10 high-level requirements
Use for ballpark estimate
Later, switch to Balanced for detailed discovery
Scenario: Multi-Week Discovery
Situation: Running weekly discovery sessions over 4-6 weeks
Recommendation: Balanced
Upload all meeting notes at Balanced
Get comprehensive but manageable requirements
Review and refine each week
Switch to Granular for specific complex areas
Scenario: Developer Handoff
Situation: Discovery complete, handing off to dev team
Recommendation: Granular for complex areas, Balanced for everything else
Re-upload complex feature docs at Granular
Keep other requirements at Balanced
Developers get detail where they need it
Don't overwhelm with unnecessary detail
Scenario: Compliance Project
Situation: Healthcare/Finance project with regulatory requirements
Recommendation: Granular
Upload all compliance docs at Granular
Need comprehensive coverage
Can't afford to miss edge cases
More requirements acceptable given stakes
Troubleshooting
"Broad Strokes still feels too detailed"
Possible causes:
Source material is very detailed
AI erring on side of completeness
Solutions:
Provide less detailed source material (high-level summaries)
Edit requirements to simplify after generation
Manually create even higher-level requirements
Note: if this is your experience, I want to know about it! Email Ali at [email protected]
"Granular created way too many requirements"
This is expected behavior for Granular:
100-200+ requirements is normal for large docs
Granular is meant to be exhaustive
Solutions:
Use Balanced instead for most content
Reserve Granular for truly complex areas
Review and delete obvious/unnecessary requirements
Merge duplicates