Rewrite Behavior in Requirement Assistant
The Rewrite feature improves item clarity and structure using predefined templates. It applies internal logic to split, format, and optionally merge requirement statements.
• Internal Split for All Options
The system splits the item internally to process each intent even if you choose Format, Clarify, or Isolate Rationale. This ensures better formatting and clarity.
◦ If Split is not selected, intents are merged back into a single item after formatting.
◦ If Split is selected, each intent remains as a separate item.
• Handling Multi-Condition Requirements and Enumerations
When an item contains multiple conditions or lists, Rewrite creates separate statements for each intent. This is by design to make items atomic and easier to manage.
• Ambiguity Handling
Phrases like “such as” or “could include” are treated as separate thoughts. The system does not guess missing details, it preserves clarity by isolating these parts.
Example 1: Multi-Condition Requirement
Before: The system shall automatically adjust the low beam headlights based on various factors, such as ambient lighting conditions, vehicle speed, and road conditions.
After Rewrite:
◦ The system shall automatically adjust the low beam headlights based on various factors.
◦ The system shall consider ambient lighting conditions.
◦ The system shall consider vehicle speed.
◦ The system shall consider road conditions.
Example 2: Enumerations Requirement
Before: The balcony should include privacy features, such as frosted glass or a privacy screen.
After Rewrite:
◦ The balcony should include privacy features.
◦ The balcony should include frosted glass as a privacy feature.
◦ The balcony should include privacy screen as a privacy feature.
Format Option Behavior
The Format tool standardizes requirements to match customer-defined templates using a three-step process.
It parses the original requirement text to identify the following nodes:
• SUBJECT_SYSTEM – Subject system of the requirement
• ACTION_VERB – Action verb for the requirement
• MODAL_VERB – The modal verb used to write the requirement
• PERFORMANCE – Describes the performance expected for a functional requirement
• CHARACTERISTIC – Describes the characteristic expected for a characteristic requirement
• INTERFACE_SYSTEM – Describes the system to which the action applies
• OBJECT_SYSTEM – Describes the system that constrains the design
• CONDITION – Describes the conditions under which the requirement applies
The tool determines the primary purpose of the requirement and maps the extracted nodes into the designated template for that intent type to generate the standardized requirement.
Requirement Type Determination
The system determines the primary purpose of a requirement from one of the following categories:
• Functional – Describes what the system shall do
• Characteristic – Specifies a property, attribute, or quality the system shall have
• Design Constraint – Imposes limitations on system design, often via required composition
• Interface – Specifies interactions between the system and an external entity
This determination is used to select the appropriate format definition.
Impact of Format on Analysis and Rewrite
The Format step has no impact on the independent Requirement Analysis phase.
From a rewrite perspective, aside from enforcing the structured statement rule (R1), the Format step also applies several INCOSE 4.0 rules, including:
• R2 – Active voice
• R5 – Definite articles
• R12 – Correct grammar
• R13 – Correct spelling
• R14 – Correct punctuation
• R20 – Purpose phrases
Split Option Behavior
Split option detects multiple thoughts and separates them into separate requirements.
The primary principle for identifying a distinct thought is whether it introduces a single, independent system intent, rather than relying solely on the presence of verbs.
Common triggers that indicate separate intents include:
• Specific punctuation
• Logical operators. For example: and, or, and so on.
• Enumerated lists