The requirement analysis feature looks at the requirement text and highlights potential issues regarding the requirement quality. It provides multiple levels of analysis:

Core requirement analysis
Item classification
Field analysis
Weak word analysis
Project analysis
Issue feedback
Standards check
Similarity

How to access

The Requirement analysis can be found in the Raiqon AI plugin and inside the Raiqon copilot.

How to use

Scope

The scope of the search can be changed in the top left corner via the scope selector. By default the scope is set to the current project. You can select multiple projects and/or trackers to be included.

Classification

Based on its content, items are assigned one of these type labels:

Functional Requirement
Non Functional Requirement
Usability
Security
Look And Feel
Legal
Fault Tolerance
Maintainability
Portability
Scalability
Operational
Performance
Unknown

and one of these level labels:

Software Detailed Requirement
System Requirement
System Architectural Requirement
Software Requirement
Software Architectural Requirement
Unknown

Raiqon review

This analysis helps you find issues in the requirement itself and improve the general requirement quality. It finds completeness and inconsistency issues and provides detailed reasoning about the highlighted parts.

Field Analysis

This analysis shows proposals regarding the summary of the requirement.

Weak word analysis

The weak word analysis highlights the weak words used in the requirement text. It is based on a configurable weak words list that are commonly used in requirements and may cause misunderstanding between stakeholders or lead to an ambiguous or otherwise unclear requirement.

This analysis helps you to identify and replace weak words with stronger alternatives.

Project Analysis

This analysis helps you to identify inconsistencies between multiple requirements in the context of the selected project.

This is a more advanced analysis that looks at the requirement content in the context of the project and provides detailed feedback while highlighting the issues between two requirements in scope.

The issues can be expanded for a detailed explanation.

Issue Feedback

Only available to Expert users.

To provide feedback on issues, press the button on the right side of the issue .

Clicking the feedback button brings up the feedback modal where you can select your desired feedback and optionally provide additional comments. Clicking the send button will save the feedback and put the issue in its proper section within the group. Existing feedback can be changed by following the same flow.

After a selection the choice and comment is saved and icon indicates the severity.

The icon (and its color) depends on the previous feedback, but brings up the same feedback modal. In order: no previous feedback, accepted, rejected and risk accepted.

Users who do not have Expert User privileges will only be able to see items that either have no feedback or have Accepted feedback. Rejected and Accepted Risk items are only visible for users with Expert User role.

Rejected issues

All issues flagged rejected are moved to a separate field at the bottom of the menu. Changing the severity from rejected to accepted or accepted with risk moves them back to their origin.

Standard Check

Requirements are checked against a set of rules derived from industry standard requirement engineering guidelines and rulesets (like INCOSE or NASA).

List of high level rules checked by our AI models:

Clarity and Simplicity: Use clear, precise language. Avoid ambiguity by using well-defined terms and avoiding vague adjectives or adverbs like "large," "fast," or "about”.Requirements must be using active voice and follow a straightforward subject-verb-object structure.
Measurability and Verifiability: Each requirement must be objectively measurable and verifiable. Quantitative criteria should be included wherever possible to ensure the requirement's fulfilment can be tested.Avoid subjective language and ensure the requirement is stated in a way that allows measurable evaluation (e.g., specific units, measurable performance criteria).
Necessity and Relevance: Ensure each requirement is necessary for achieving the overall system goal. Requirements should not be included without a clear justification of their necessity to the system or stakeholder needs. Include only requirements that provide a tangible benefit or functionality from a business perspective.
Completeness: The requirement must be complete, providing all necessary information, context, and parameters to avoid assumptions and ambiguity. Avoid implicit information. Requirements must be explicit to eliminate the need for external clarification or assumptions from stakeholders.
Feasibility: The requirement must be complete, providing all necessary information, context, and parameters to avoid assumptions and ambiguity.Avoid implicit information. Requirements must be explicit to eliminate the need for external clarification or assumptions from stakeholders.
Singularity: Each requirement must express a single function or attribute. Do not combine multiple actions or features into a single requirement statement. A requirement should address only one aspect to remain straightforward and testable.Avoid combining multiple conditions, which can make verification and implementation challenging.
Consistency: Use consistent terminology throughout the requirements document to reduce misunderstandings. Abbreviations should only be used if defined clearly and consistently in a glossary.Ensure there are no internal contradictions within the requirements set. Requirements should align without overlap or conflicting statements.
Traceability: Maintain traceability of each requirement to its source (e.g., stakeholder need, higher-level system goal). This ensures that all requirements have a clear origin and purpose, and changes can be managed effectively.Traceability also supports validation to ensure each requirement contributes to fulfilling a stakeholder need
Non-Ambiguity and Testability: Use constrained natural language where possible, such as the Easy Approach to Requirements Syntax (EARS), to reduce ambiguity and improve testability.Requirements should avoid using modal verbs like "should" or "may," which can make them non-binding or unclear. Use "shall" or equivalent definitive terms to establish requirements as binding.

The rulesets can be expanded using the drop down arrows to reveal the detailed violations.

Here the user can check the exact rules violated by the requirement from the original standards/rulesets. Top level categories (like Completeness, Feasibility, etc.) are also used to group rules and guidelines from other standards/rulesets.

Hovering over a violated rule’s title will reveal the full content of the rule or guideline, so the requirement can be corrected accordingly.

These rules can be configured using the Raiqon configuration project.

Similar Items

The requirement similarity feature helps you find similar items based on the textual content of the current requirement. It provides a list of similar items with a preview of their content. Additionally it shows on the top right corner if an item has the same parent as the currently selected and also shows potential duplicates.

Clicking the buttons on the right side navigates to the similar item