Write requirements

What the IDS Ruler is

The IDS Ruler is where you write your own model requirements and check a model against them, without writing XML by hand. Open it from the rail. It has two tabs that share the same rules: Rule Checker, where rules are listed and run, and IDS Creator, where the same rules are shown as IDS specifications.

IDS is buildingSMART's open format for information requirements. Rules you write here can be exported as an IDS file for other tools, and IDS files from other tools can be imported.

Results from the IDS Ruler are your own checks. They are separate from Assure's catalogue, its findings and the standard score.

Writing a rule

On the Rule Checker tab, press Add rule. Give the rule a name, then say what it applies to and what it requires: choose the IFC class, the Parameter to test, the Condition and the Value. Changing the IFC class resets the parameter to the first one that class has, because the parameters offered depend on the class. Allocate as sets what a failure of this rule counts as: Error, Warning or Info. The switch on the row turns the rule on or off.

You can record why a rule exists, such as the regulation, standard or client requirement behind it.

On the IDS Creator tab, Add specification adds the same kind of rule in IDS terms. Anything added there is a rule in the Rule Checker tab, and runs there.

Importing an IDS file

Press Add IDS and choose an IDS file. Before anything changes, ZEROBiE shows a report to review: how many specifications the file has, how many this engine can run, and which are kept but cannot be run here.

Then choose what to do with it: import it as a new group, add it to the rules on screen, or replace the rules on screen. The original file is kept as it was, including the parts this engine cannot run. A specification that cannot be run is kept, imported disabled, and reported as not run. It is never reported as a pass.

Groups

A group is a named set of rules you can come back to. The group control at the top chooses the group on screen. When you change rules, the group is marked Unsaved until you save it under a name, with an optional description.

Copy makes a copy of the group, Export .ids downloads it as an IDS file, and Delete removes it.

Running a check

Choose the model in the Model control, then press Run check. The check is queued and runs against the model as it was when you pressed the button, with the rules as they were at that moment. If you change the rules afterwards, the results on screen still belong to the earlier draft, and the page says so; press Run check again to evaluate the new rules.

Reading the results

Results are grouped by rule. For each failing element you see its IFC class, name, Object ID and what was found. Select a failure to see Why this failed, which sets what the rule required beside what the model has, and to see the element in the model.

Rules that could not be evaluated are listed under Did not run. These are not passes: each one says why it could not be evaluated.

Exporting IDS and BCF

Export .ids downloads the rules as an IDS file. The IDS XML view shows the file's content, and lists what the file does not carry.

After a check, Export BCF produces a BCF archive of the failures, with a topic and viewpoint for each, for use in a coordination tool. Save BCF to CDE stores the archive in the project instead: choose a folder in the model's project, or Project root, and press Save BCF.

Workflow: turn a requirement into a repeatable check

Before you begin, identify the model and write down the requirement in everyday language: which elements it applies to, what information they must carry, and what counts as an acceptable value. The rule is only useful if those choices match the team's actual requirement.

1. Add a rule and name it so another reviewer can recognize its purpose. Select the IFC class, then choose an available parameter, condition and value. Check the parameter again if you change the class, because the selection resets.
2. Record why the rule exists and choose its failure severity. Save the group under a name you can recognize later. A saved group lets you return to the requirements; exporting IDS lets you exchange them with another tool.
3. Select the model and Run check. Open a failing result and read Why this failed to compare the requirement with the recorded value. Read Did not run before drawing a conclusion about coverage.
4. Export BCF when the author needs coordination topics, or Save BCF to CDE to keep the archive with the project. Export .ids when the recipient needs the requirements themselves. These exports serve different purposes.

If you edit a rule after the check, run it again. The existing result describes the earlier draft and does not update merely because the visible rule changed. IDS Ruler results remain separate from Assure's findings and score.

Review an imported requirement set

Read the import report before choosing whether to create a new group, add to the current rules or replace them. Replacing changes which rules are on screen, so save the current group first if you need to return to it.

Some imported specifications may be preserved but unsupported by this engine. They arrive disabled and are reported as not run. Retaining their original content does not mean the checker evaluated them. Tell the receiving team which requirements were evaluated and which still need another review method.