How Document Templating Works

This is a reference guide for Ultralight's document templating. Ultralight can

generate highly customizable documents based on user-managed templates

in the form of Word files.

For most cases, unless you are planning on changing the way Ultralight displays the data, you can create templates with only the additional content you want added to it. I.e. you can download an example template from the bottom of the page and then add headers, change fonts, font sizes, footers, add images, preambles etc and leave the rest of it as-is.

For advanced users - a template is a Word file with user defined-content. Ultralight uses

tags to insert data into templates. This is inspired by the language-agnostic Mustache specification.

Tags can be used to insert variables in a document. A tag looks like this: {variableName}

Ultralight supports two main types of tags - the regular variable tag, {variableName} and the {#list} tag, which can loop over a list of values.

Variable Tag

A variable tag can be used to insert data in the given location in the Word file. For example: {productName} will replace the tag with the product name, e.g. "TENS Device".

Loops

A loop tag, e.g. {#allDesignElements} can be used to loop over a list of values. A {#list} tag must be closed by an identical {/list} tag which signifies the end of the loop.

Example usage:

{#allDesignElements}
{ID}
{/allDesignElements}

This loop will print out all IDs for all design elements.

Advanced Usage

There are some advanced options available to build custom documents.

Tables

You can create rows in a table using a similar loop as below:

ID	Component	Category	Title	Description
{#allDesignElements \| filterByType: “USER_NEED”}{ID}	{component}	{category}	{title}	{~~description}{/}

Grouping

You can use {#allDesignElements | groupBy "category"} to group all design elements by their categories, for example. Another example would be to group by components, which can be done by using {#allDesignElements | groupBy "component"}.

Make sure to close this tag correctly using the exact same tag, e.g. {/allDesignElements | groupBy "component"}.

When grouping is used, it changes the way the data is represented. Within the grouping, a new tag called {groupKey} is created to, for example, access the category/component name in the examples. Another list tag is also created, called groupedItems. This can be looped over the same way as other lists are looped.

For example, to group all design elements by category and then show the category as well as the grouped item data, you can use this:

{#allDesignElements | groupBy: "category"}

{groupKey}
{#groupedItems}
{ID} {title}
{/groupedItems}

{/allDesignElements | groupBy: "category"}

Filtering

You can filter allDesignElements using the filterByComponent, filterByCategory , filterByType and filterByID tags.

Example usage:

{#allDesignElements | filterByComponent : "Hardware"}
{ID} {title}
{/allDesignElements | filterByComponent : "Hardware"}

The above will populate the template with only filtered design elements whose component is "Hardware". An example for the type filtering is:

{#allDesignElements | filterByType: "SUBSYSTEM_REQUIREMENT"}
{ID} {title}
{/allDesignElements | filterByType: "SUBSYSTEM_REQUIREMENT"}

An example of ID filtering is:

 {#allDesignElements | filterByID: ["VER-1", "SSR-1"]}
{ID} {title}
{/allDesignElements | filterByID: ["VER-1", "SSR-1"]}

Chaining Filters

Note that filters can be chained together too.

Example:

{#allDesignElements | filterByType: "SUBSYSTEM_REQUIREMENT" | filterByComponent: "Battery"}

{ID} {title}

{/allDesignElements | filterByType: "SUBSYSTEM_REQUIREMENT" | filterByComponent: "Battery"}

Filtering by multiple values

To filter by multiple values, you can enclose the values in square brackets, separated by commas.

Example:

{#allDesignElements | filterByType: ["SYSTEM_REQUIREMENT", "SUBSYSTEM_REQUIREMENT"]}

{ID} {title}

{/allDesignElements | filterByType: ["SYSTEM_REQUIREMENT", "SUBSYSTEM_REQUIREMENT"]}

Available Filters

Filter	Description	Example Usage
filterByComponent (for `allDesignElements`)	Can be used to filter by component. For subcomponent filtering, a full path must be provided, e.g. `Hardware -> Battery`	`filterByComponent: ["Hardware", "Hardware -> Battery"]`
filterByCategory (for `allDesignElements`)	Can be used to filter by categories	`filterByCategory: ["Clinical", "Regulatory"]`
filterByType (for `allDesignElements`)	Can be used to filter by design element type. Options are `USER_NEED, SYSTEM_REQUIREMENT, SUBSYSTEM_REQUIREMENT, DESIGN_OUTPUT, VERIFICATION, VALIDATION`. Note: this is not available for Test Execution Report templates.	`filterByType: ["SYSTEM_REQUIREMENT", "SUBSYSTEM_REQUIREMENT"]`
filterByID (for `allDesignElements`)	Can be used to filter by the "ID" (or by "testID" for test report documents).	filterByID: ["VER-2", "SSR-1"]

Creating Templates

Template Overrides can be created for either existing Ultralight-generated documents, or can be created as entirely new documents.

Custom Documents

You can create new custom documents by adding a new Custom Document via the UI in "Generated Design History File".

Ultralight-Generated Document Template Overrides

You can also override the way Ultralight-generated documents are created, by clicking on the document you want to override and then clicking on "Advanced" to set up the template.

Data Dictionaries

Top Level

Variable	Availability	Description
title	All documents	The title of the document
productName	All documents	The name of the product
generationDate	All documents	When the document was generated
allDesignElements	This data is available for the following document types: User Need Specifications System Requirements Specification Subsystem Requirement Specifications Design Output Specifications Verification Protocol Validation Protocol Custom Documents	A list of all design elements. This needs to be looped on using `{#allDesignElements}`. For non-Custom Documents, `allDesignElements` will only include the specific design element type for which the document is generated. For example - if overriding the "User Need Specifications" document, allDesignElements will only contain the User Needs data. For Custom Documents, `allDesignElements` will include all design elements from your product - for User Needs, System Requirements, Subsystem Requirements, Design Outputs, Verification and Validation. Notably, this excluded Verification and Validation Test Executions.
testExecutions	This data is available for the following document types: Verification Test Execution Report Validation Test Execution Report	A list of all, *most-recent* test executions. This needs to be looped on using `{#testExecutions}`. `testExecutions` will only include the specific design element type for which the document is generated. For example - if overriding the "Verification Test Execution Report", `testExecutions` will only contain Verification Test Execution data.
sections	This data is available for the following document types Framework Export	A list of all Framework sections. This needs to be looped on using `{#sections}`

Design Element - allDesignElements

Variable	Description
type	The type of the design element. One of "USER_NEED", "SYSTEM_REQUIREMENT", "SUBSYSTEM_REQUIREMENT", "DESIGN_OUTPUT", "VERIFICATION", "VALIDATION"
ID	The ID for the design element, e.g. UN-1, SR-1, SSR-1 etc.
version	The version of the design element, e.g. V1.0, V1.1 etc
title	The title of the design element
description	(optional) The description for the design element. Needs to be used as {~~description}
category	(optional) The category of the design element
component	(optional) The component of the design element. For subcomponents, this is displayed as the "Component -> Subcomponent"
method	(optional) Only present for Verification/Validation.
steps	(optional) Only present for Verification/Validation. This is an Array which needs to be looped on.
hasSteps	(optional) Only present for Verification/Validation. This is can be used as a condition.
documents	(optional) A list of documents that have been linked to the design element
files	(optional) A list of files that have been added to the design element. These are available as hyperlinks. Use as `{#files}{~~file}{/files}`
filePaths	(optional) A list of filepaths to the local downloaded files. use as `{#filePaths} {~~.} {/filePaths}`

Test Executions - testExecutions

Variable	Description
testID	The ID of the test this execution is against. E.g. `VER-1`, `VAL-1`
runBy	The name of the owner for the test execution.
category	(optional) The category of the test this execution is against. E.g. "Regulatory"
component	(optional) The component of the test this execution is against. For subcomponents, this is displayed as the "Component -> Subcomponent"
unitUnderTest	The Unit under Test for this execution.
testExecutionSteps	This is an array which needs to be looped on using `#testExecutionSteps`. See the Data Dictionary for how to use this.
testStatus	The overall test status for the test execution
notes	(optional) Any associated notes for the test execution
files	(optional) A list of files that have been added to the test executions. See the Data Dictionary for how to use this

Test Execution Steps - testExecutionSteps

Variable	Description
stepNumber	The step number
name	The name/description of the step
acceptanceCriteria	The acceptance criteria for the step
result	"Pass"/"Fail"
notes	(optional) Any notes for the test step

Documents: documents

Variable	Description
ID	The ID of the document. E.g. "DOC-1", "SOP-1"
title	The title of the document
version	The version of the document. E.g. "V0", "V1.0" etc.

Steps - steps

Variable	Description
stepNumber	The step number
name	The name/description of the step
acceptanceCriteria	The acceptance criteria for the step

Files - files

Variable	Description
file	The name of the file hyperlinked to the download link. Must be used as {~~file}

Framework Sections - sections

Variable	Description
sectionName
requirements	The list of requirements under the current framework section

Framework Requirements - requirements

Variable	Description
title
description
hasEvidence	Whether the requirement has evidence assigned. Useful as a condition.
evidence

Framework Requirement Evidence - evidence

Variable	Description
description	Must be used as {~~description}
evidenceFiles	A list of paths to the files within the export. Example loop: {#evidenceFiles} {.} {/evidenceFiles}
evidenceDocumentVersions ID version title
evidenceDesignElementVersions ID version title

Example Templates

Design Element Template

Download

This template can be used as-is for the following documents:

User Needs Specification
System Requirements Specification
Subsystem Requirements Specification
Design Output Specification
Verification Protocol
Validation Protocol

Test Execution Report Template