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?”
Unlike most entities you author by hand, Features are discovered, not created. When Catalio scans an Application, it infers the features that the system delivers and records each one as a candidate for review. A domain expert then confirms or dismisses each candidate on the Explore Features stage. There is no standalone “create a Feature” form.
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.
The Feature Lifecycle
Every Feature moves through a review lifecycle driven by its status:
detected → confirmed (or) detected → dismissed
detected: The scan surfaced the feature as a candidate and it is awaiting expert review. Detected features are proposals, not catalog entries.
confirmed: A domain expert accepted the candidate. Only confirmed Features are real entries in the catalog, and requirements can group under them.
dismissed: A domain expert rejected the candidate (for example, an internal mechanism that is not a user-facing feature). The reason can be fed back to the scan so it is not re-suggested.
A dismissed Feature can be un-dismissed, and a confirmed one can be un-approved. Either action sends it back to detected so it re-enters the review queue.
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 | Review state: detected, confirmed, or dismissed |
| confidence | The scan’s confidence (0 to 1) that this is a real feature of the application |
| feature_kind | product (an end-user or business feature) or platform (a technical/operational capability) |
| evidence | The reason and source files the scan used to infer the feature |
| discovery_method | How the row originated: scan (inferred by Catalio) or manual |
Product vs. Platform
feature_kind separates end-user value from supporting machinery. A product feature is something a business user recognizes, like “Accounts Payable” or “Order Tracking”. A platform feature is a technical or operational capability that enables the product, such as background sync, audit logging, or a shared integration layer. The distinction drives the product/platform grouping you see during review, so you can focus on user-facing scope without losing sight of the technical surface.
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
A Requirement can group under a Feature, but only once that Feature is confirmed. Detected and dismissed candidates never hold requirements. 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
Open a confirmed Feature to see all its Requirements, and open a Requirement to see the Feature it belongs to.
Features and Policy Coverage
One of Catalio’s most valuable capabilities is policy-to-requirement traceability. Because Requirements group under 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.
How Features Get Discovered
When Catalio scans an Application, it infers candidate features and records each with a confidence score and the evidence (reason plus source files) it was inferred from. Re-running a scan re-scores candidates that are still detected. It never disturbs an expert’s confirmed or dismissed decision. Your job on the Explore Features stage is to review these candidates, confirm the real ones, and dismiss the noise.
Best Practices
Review high-confidence candidates first.
The confidence score orders your review. Start with the features the scan is most sure about, then work down to the ambiguous ones.
Match your stakeholders’ vocabulary when you rename.
If the business team calls it the “AP module,” confirm the Feature as “Accounts Payable”, not “Financial Liability Processing.” Alignment with existing language reduces confusion.
Dismiss with a reason.
When you dismiss a candidate that is not a user-facing feature, record why. The reason feeds back into the scan so the same non-feature is not re-suggested.
Confirm before grouping.
Requirements only attach to confirmed Features, so confirm a candidate before you expect requirements to organize under it.
Relationships at a Glance
| Related Concept | Relationship |
|---|---|
| Application | Features belong to an Application |
| Requirements | A confirmed Feature groups many Requirements |
| Initiative | Initiatives scope Features as in-scope or out-of-scope |
| Policies | Policies apply to Applications via the Feature → Requirement path |
Next Steps
- Add Requirements: Populate your confirmed Features with specific capabilities
- Define Initiatives: Use Features to scope your modernization phases
- Understand Applications: Learn how Features fit the broader hierarchy
Pro Tip: Treat the Explore Features stage as triage. Confirming and dismissing candidates quickly gives you a clean feature map to hang requirements on. A well-curated set of confirmed Features is worth far more than a long list of unreviewed candidates.
Support
- Documentation: Continue reading about Requirements and Initiatives
- Email: support@catalio.ai
- Community: Share scoping strategies with other Catalio users
