A Feature is a named functional area within an Application that groups related Requirements. Features provide the middle tier of Catalio’s Application hierarchy:
Application → Feature → Requirement → Use Case / Test Case
Features answer the question: “Which part of the system does this requirement belong to?”
Why Features Exist
Requirements without grouping become overwhelming at scale. A legacy system may have hundreds or thousands of requirements spread across modules, workflows, and user roles. Features create natural groupings that match how the system’s users and builders already think about it.
Features also support scope management: an Initiative can include or exclude entire Features, making it easy to define the scope of a modernization phase or a release.
Key Fields
| Field | Purpose |
|---|---|
| name | The feature name, e.g. “Invoice Approval”, “Customer Onboarding” |
| description | What this feature area covers and who uses it |
| application_id | The parent Application this feature belongs to |
| status | Whether the feature is active, planned, or deprecated |
| priority | Relative priority for modernization planning |
Common Feature Patterns
Features typically map to one of:
Modules or functional areas
Application: "Oracle EBS Finance"
Feature: "Accounts Payable"
Feature: "Accounts Receivable"
Feature: "General Ledger"
Feature: "Fixed Assets"
User-facing workflows
Application: "Customer Portal"
Feature: "Account Registration"
Feature: "Order Tracking"
Feature: "Invoice Download"
Feature: "Support Ticket Management"
Integration touchpoints
Application: "ERP Integration Layer"
Feature: "Salesforce Sync"
Feature: "Warehouse Management Interface"
Feature: "EDI Message Processing"
Features and Requirements
Every Requirement in Catalio can be linked to a Feature. This link:
- Makes requirements easier to find and filter
- Enables feature-level coverage analysis (which features have requirements? which have test cases?)
- Drives scoping decisions in Initiatives
The relationship is visible wherever you view a Feature: open a Feature to see all its Requirements, and open a Requirement to see the Feature it belongs to. You can also filter the Requirements list by Feature from the Requirements index page.
Features and Policy Coverage
One of Catalio’s most valuable features is policy-to-requirement traceability. Because Requirements belong to Features, and Features belong to Applications, Catalio can traverse this hierarchy to answer: “Which Policies apply to this Application?”
Application → Features → Requirements → RequirementPolicy → Policy
This lets you see all governance constraints that apply to an Application in a single view, without manually tagging each requirement.
AI-Powered Feature Discovery
When Catalio’s AI analyzes uploaded documents, meeting transcripts, or connected source code, it can generate Change Proposals scoped to specific Features. This makes AI-discovered requirements immediately organized within the right functional area, rather than arriving as unstructured noise.
Best Practices
Match your stakeholders’ vocabulary.
If the business team calls it the “AP module,” name the Feature “Accounts Payable” — not “Financial Liability Processing.” Alignment with existing language reduces confusion.
Aim for Features that map to team ownership.
If one team owns “Accounts Payable” and another owns “General Ledger,” create separate Features. This makes it easy to assign requirements to the right owners.
Don’t over-granularize.
A Feature should represent a meaningful functional area, not a single screen or button. If a Feature would have only one or two requirements, consider merging it with a sibling Feature.
Review Features during Initiative scoping.
When defining an Initiative, review all Features in scope. Explicitly including or excluding Features at the Initiative level is cleaner than tagging individual requirements.
Relationships at a Glance
| Related Concept | Relationship |
|---|---|
| Application | Features belong to an Application |
| Requirements | A Feature contains many Requirements |
| Initiative | Initiatives scope Features as in-scope or out-of-scope |
| Change Proposal | Proposals can be linked to a Feature |
| Policies | Policies apply to Applications via the Feature → Requirement path |
Next Steps
- Add Requirements — Populate your Features with specific capabilities
- Define Initiatives — Use Features to scope your modernization phases
- Understand Applications — Learn how Features fit the broader hierarchy
Pro Tip: Start with 5-10 high-level Features per Application. You can always split a Feature later as requirements grow. Starting too granular leads to sprawl; starting too broad is easy to fix.
Support
- Documentation: Continue reading about Requirements and Initiatives
- Email: support@catalio.ai
- Community: Share scoping strategies with other Catalio users