As soon as the requirements management team matures in both tooling and process, requirements engineers begin to explore and adopt advanced techniques to enhance efficiency, consistency, and traceability. One such technique is the use of parameters in requirements.

A requirement parameter is essentially a placeholder or variable that is maintained separately from the requirement itself. This decoupling introduces a powerful mechanism: it allows parameter values to be managed centrally and reused across multiple requirements. Most importantly, when implemented correctly, this setup enables value updates without altering the requirement text directly - thus preserving link integrity and avoiding unnecessary re-verification or change propagation.

Why Use Parameters? 
The use of parameters in requirements can deliver several significant benefits:
 

• Reusability: Common values (e.g., thresholds, dimensions, performance metrics) can be defined once and used across multiple requirements. 
  
• Consistency: Reduces the risk of mismatches in values that appear in several places. 
  
• Ease of Updates: A single change to a parameter value updates all dependent requirements without changing their textual content.  Improved Traceability: Changes to parameters can trigger precise impact analysis and notifications. 
• Link Stability: Because the core requirement content doesn't change, link status (e.g., “suspect” links in DOORS) remains stable unless the actual semantics are affected. 
  
  However, exactly how it works can differ according to team demands and particular implementation decisions.

In IBM DOORS Classic, implementing parameters typically requires custom DXL scripting. DXL (DOORS eXtension Language) allows you to create reusable modules that hold parameter values and reference them from requirement modules.

However, this approach demands scripting expertise and careful management of module structures and dependencies.

DOORS Next offers out-of-the-box support for parameters via artifact embedding and reusable data elements. One common approach is:

• Create a dedicated module (a dedicated component can be used) that contains parameter definitions (e.g., " 35 meters" for braking distance)
• In requirement text, instead of hardcoding the value, embed parameter artifact.
  
  

The second way would be similar with a minor difference:  

• Create a dedicated module (also a dedicated component can be used) that contains parameters, and artifact type used for parameters is marked to be used for terms (this is OOTB function of DOORS Next)   
• In requirement text type value once and link it to a parameter via lookup term function

Now, depending on the chosen approach, the state is following:

• Embedded artifact was used: no link is created between an embedded artifact and a placeholder artifact, but linking functionality is available from the context o Softacus provides an extension which adds more automation for this case
• Term functionality was used: a link is always created automatically

On the screenshot below both approaches are shown:

• The requirement for complete braking distance has parameters as embedded artifacts:

  Speed: 100 km/h

  Distance: 40 m

• The requirement for acceleration time has parameters based on Glossary Term function:

  Speed: 100 km/h

  Time: 4.0 seconds

Please pay attention to:

• Parameters based on embedded artifacts are in a frame which separated parameter from the main requirement, and parameters based on Glossary Term function are organic part of the text
• Linking of parameters to the requirement – with Glossary Term function they are created by a default, and in case of embedded artifacts – it should be handled additionally

Now, when a parameter is changed:

• Embedded artifact was used: refreshed automatically new value is available
• Term functionality was used: parameter value is not updated in the text by itself even thus changed value can be seen on hover over. Softacus provides an extension which boosts Terms functionality of DOORS Next

In the other use case, when artifacts with parameters will be exported to a spreadsheet:

• Embedded artifact: an additional handling would be required to get parameter value, because by a default only reference to the artifact with parameter is shown o Softacus has an experience solving such cases
• Term functionality: parameter is an organic part of text

After you have chosen your way to use parametrization and requirements are written with parameters – you probably would like to use parameters for testing with . Softacus can support with this case, we have such experience as well. Besides described above, Softacus offers more extensions for artifacts synchronization and reuse and a complex solution for variants management.