Built-in Requirements

Overview

Built-in requirements are for teams that want to define and manage requirements directly inside TestKase without relying on an external issue tracker. When you enable the Requirements module in your project settings, you get a dedicated Requirements tab where you can create requirements, organize them into folders, link them to test cases and defects, and attach supporting files -- all within a single platform.

If your team tracks requirements in Jira, GitHub, or GitLab instead, see the Jira Integration, GitHub Integration, or GitLab Integration guides to auto-sync requirements from your issue tracker.

Create a Requirement

Creating a requirement in TestKase captures a testable business expectation that your team needs to verify. Follow these steps to define a new requirement from scratch:

1. Navigate to the Requirements tab in your project from the left sidebar. You will see the requirements list view with any existing requirements and the folder tree on the left.
2. Click the Create Requirement button in the top-right corner of the requirements view. A creation form will open where you can fill in all the details.
3. Enter a Title (required). This should be a clear, concise statement of what the system must do. Good titles read like verifiable statements, for example: "User can reset password via email link" or "Shopping cart calculates tax based on shipping address".
4. Optionally fill in the Description field with a rich-text explanation that provides additional context, acceptance criteria, edge cases to consider, or links to design documents. The description supports formatting including bold, italic, bullet lists, and code blocks. The richer the description, the easier it is for testers to write thorough test cases against this requirement.
5. Set the Priority level (P0, P1, P2, or P3) to indicate how critical this requirement is to the release. See the Requirement Fields section below for detailed explanations of each priority level.
6. Set the Status to reflect the current lifecycle state of the requirement. New requirements typically start as Draft while they are being reviewed, then move to Active once approved. See the Requirement Fields section for details on each status.
7. Optionally select a Folder to organize the requirement within. If you do not select a folder, the requirement will be placed at the root level. Choosing a folder at creation time avoids the need to move it later.
8. Click Save. The requirement is created immediately and appears in the requirements list. You will be redirected to the requirement detail view where you can link test cases, link defects, add attachments, and more.

Requirement Fields

Each requirement has the following built-in fields. Understanding these fields and using them consistently across your team ensures that requirements are clear, prioritized, and actionable.

Priority Levels Explained

Use the P0 through P3 priority levels consistently across your project to communicate how critical each requirement is. Priority directly affects which requirements your team should focus on covering with test cases first.

• P0 (Critical) -- The requirement is essential for the product to function. A failure to meet this requirement would block a release or cause severe business impact. Examples: user authentication and authorization, payment processing, data integrity constraints, core API endpoints, compliance-mandated features. P0 requirements should always have at least one linked test case and should be covered by automated tests when possible.
• P1 (High) -- The requirement covers important functionality that most users rely on. Failing this requirement would significantly degrade the user experience or affect key workflows. Examples: user registration flow, search and filtering, notification delivery, report generation, role-based access control. P1 requirements should be covered in every regression cycle.
• P2 (Medium) -- The requirement covers standard functionality that is expected to work but is not business-critical. Failing this requirement would be noticeable but would not block core workflows. Examples: profile customization settings, sorting and pagination options, export formatting, help tooltips. P2 is the default priority for new requirements.
• P3 (Low) -- The requirement covers nice-to-have features, edge cases, or cosmetic behaviors. Failing this requirement would have minimal user impact. Examples: keyboard shortcuts, animation smoothness, tooltip text, rarely-used configuration options, legacy browser polyfills. P3 requirements can be deferred if testing time is limited.

Status Values Explained

The status field tracks where each requirement is in its lifecycle. Use statuses to control which requirements are actively being tested and which are still being defined or have been retired.

• Draft -- The requirement is being written, discussed, or reviewed by the team. Draft requirements should not be linked to test cases yet because the requirement may change during review. Use this status for requirements that are newly created, pending stakeholder approval, or being refined based on feedback. Move to Active once the requirement is finalized and approved.
• Active -- The requirement is finalized, approved, and ready to be tested. Active requirements should be linked to at least one test case. This is the status that coverage metrics track against -- only Active requirements count in coverage percentage calculations. Use this status for all requirements that represent current, valid product behaviors.
• Deprecated -- The requirement is no longer relevant because the feature was removed, the requirement was replaced by a newer version, or the business need has changed. Deprecated requirements are excluded from coverage calculations and should not be included in new test cycles. However, their historical data (linked test cases, defects, execution history) is preserved for audit purposes.

Folder Organization

Requirements can be organized into a hierarchical folder structure, just like test cases. Folders let you group related requirements together by feature area, business domain, user persona, or any other logical grouping that makes sense for your team.

The folder tree is displayed in the left sidebar of the Requirements tab. You can create folders, nest them to any depth, rename them, and move requirements between folders at any time.

Creating Folders

1. In the Requirements tab, look at the left sidebar where the folder tree is displayed.
2. Click the New Folder button (or the folder icon with a plus sign) at the top of the sidebar.
3. Enter a name for the folder. Use descriptive names that reflect the feature area, module, or business domain. For example: "Authentication", "Checkout Flow", "Admin Dashboard", or "API - v2 Endpoints".
4. Click Save or press Enter to create the folder.

Nesting Folders

Folders support unlimited nesting depth, allowing you to create a hierarchy that mirrors your product architecture. To create a sub-folder:

1. Right-click on an existing folder in the sidebar (or use the folder's context menu).
2. Select Create Sub-folder.
3. Enter the sub-folder name and confirm.

Example folder structure:

Requirements/
├── Authentication/
│   ├── Login
│   ├── Registration
│   ├── Password Reset
│   └── Two-Factor Auth
├── Checkout Flow/
│   ├── Cart Management
│   ├── Payment Processing
│   └── Order Confirmation
├── Admin Dashboard/
│   ├── User Management
│   └── Reporting
└── API/
    ├── REST Endpoints
    └── Webhooks

Managing Folders

• Rename -- Right-click on a folder and select Rename to change the folder name. All requirements inside the folder remain unaffected.
• Delete -- Right-click and select Delete. You will be prompted to confirm. Requirements inside the deleted folder are moved to the root level; they are never deleted when a folder is removed.
• Move requirements -- To move a requirement into a different folder, open the requirement detail view and change the folder assignment, or drag and drop the requirement in the sidebar.

Attachments

Attach supporting files to requirements to provide additional context for testers, developers, and stakeholders. Attachments live on the requirement detail view and are accessible to anyone with project access.

Supported File Types

File Size Limits

Individual files can be up to 25 MB each. There is no limit on the number of attachments per requirement, but we recommend keeping attachments relevant and up-to-date. Remove outdated files to avoid confusion.

Uploading Attachments

1. Open the requirement detail view.
2. Scroll to the Attachments section.
3. Click Upload or drag and drop files into the attachment area.
4. The file uploads immediately and appears in the attachment list.