From BIM Explanation Plan to requirements you can check

I started like everybody else. Excel sheets of required properties. Word documents that told planners how they had to work. We called it a BEP. In my hands it was a BIM Explanation Plan: a long text that explained BIM, hoping someone would read it and then model accordingly.

That was 2015. Telling planners how they have to work does not work. I had to learn that myself.

Two things stuck, and they still run the work.

1. A requirement is only good when there is a use behind it. If nobody uses the data, the property is theatre. I wrote plenty of those.
2. A requirement is only good if it is formulated so that it can be checked. Test-driven. If you cannot fail an IFC against it, it is not a requirement. It is a wish list with nicer formatting.

That problem has kept me busy since. From Excel lists to open data contracts. From PDFs to IDS. From "please model it like this" to "here is the check." The newest pragmaticBIM release is the latest attempt: an open standard, configured from business and project goals, not from a use-case checklist.

Use first, then require

Most BIM requirement lists start at the element. Walls need this property set. Spaces need that LongName. Doors need an extra classification. The list grows because someone, somewhere, once needed the field, and nobody wants to be the person who deleted it.

The question I learned to ask first is simpler: what will anyone do with this data? Quantity takeoff, cost, handover, operations, a quality check. If I cannot name the use, I should not order the attribute. A requirement without a use is a cost you impose on every modeler, every phase, every model, for nothing.

That sounds obvious. It is not how BEPs are written. A BEP explains a process. It rarely says which workflow actually consumes which field, or what happens when the field is missing. So the document gets signed, the model gets delivered, and the Excel list sits next to both, unused.

Formulate it so you can check it

The second lesson is the engineering one. Software people already know it: if you cannot test it, you do not have a spec. You have an intention.

BIM requirements have to survive the same test. Allowed values, units, IFC entity, property set, phase. Written so a checker can say pass or fail. Written so a planner can see the failure on a specific element, not in a paragraph about "information management." That is what buildingSMART IDS is for, and why a contract Excel that cannot be checked is still a BIM Explanation Plan, just in a different file format.

I have been circling this for years: make the use explicit, make the requirement machine-readable, then let the project team check the model against the same source they were given. No second tool, no translation back into a Word appendix.

Open standard, goal-driven configuration

The newest approach is simple to say and hard to build.

The data contract is open. The Swiss Starter Elementplan sits on GitHub: more than 40 workflows, around 80 elements, mapped to seven project goals. Anyone can read it, fork it, or copy it into a project. buildingSMART IDS is the exchange format. The published plan is the same artifact for the owner, the BIM manager, and the checker.

Configuration starts in business language. How cost-sensitive is the project? How high is the fit-out standard? How much do operations and handover matter? Each goal has intensity levels. Each level activates the workflows behind it. You order data because a project goal needs it, not because a checklist had an empty box.

Then the Information Delivery Plan answers the question every modeler actually asks: in which file, in which phase? That split is what makes model-specific IDS files possible. Without it you publish one giant requirements list and hope the right people read the right rows.

What shipped

The updated Elementplan is the product of that line of work, not a new philosophy. In this release:

• Goal-driven configuration - set an intensity per project goal and let it activate the workflows.
• IDS import and merge - bring another planner's requirements into a draft and decide per element and per attribute what stays.
• Actions in the viewer - upload an IFC, check it against the published IDS, get a report. The check stays in the browser.
• Model-specific IDS - the Information Delivery Plan decides which element belongs in which model and phase.
• Swiss Starter Elementplan - a public master on GitHub. Not a Swiss standard, and not perfect. Better than the usual Excel list, and you can flag a mistake.

Drafting and configuring on the community template is free. You pay when you publish, which is the moment the plan becomes contract-relevant and reaches the project team.

See it in order

Most BIM requirement discussions happen in the abstract, which is exactly why they go badly. The concrete version is a screenshot tour of Elementplan, in the order the tool is actually used: what the project team receives, how the plan gets made, how goals slim the catalogue, and how review and publishing turn a draft into a checked model.

A visual tour of Elementplan: from data contract to checked model

If you want to start from the public template, it is on GitHub. If you want to try it on a project, sign in to the Elementplan editor with a GitHub account, or ask us for a walkthrough.