Explainer

S1000D Business Rules, With Examples

S1000D leaves a long list of decisions to every project, and business rules are where those decisions live. Here is how they are organized, and what they look like once a machine can enforce them, using real rules from the specification's own BREX.

Decision Points

Every Rule Starts as a Decision

The specification identifies the decisions it leaves open as business rules decision points, each with a permanent identifier. Decision points that originate in S1000D take the form BRDP-S1-NNNNN, and the number does not change between issues. Two real ones: BRDP-S1-00001 covers the use of the letters I and O, and BRDP-S1-00003 is the decision on which issue of S1000D the project uses. Organizations add their own decision points with their own prefix.

Rules are also layered. The specification is the top layer, and each layer below it (a service, a program, a supplier) inherits the one above, extends it, and narrows it, with the aim that almost nothing is left for an individual author to decide. The Army's MIL-STD-3031 and Air Force's MIL-STD-3048 are exactly such layers.

Issue 4.2 groups business rules into ten categories:

1.General
2.Product definition
3.Maintenance philosophy and concepts of operation
4.Security
5.Business process
6.Data creation (text; illustrations and multimedia)
7.Data exchange
8.Data integrity and management
9.Legacy data conversion, management and handling
10.Data output

The BREX

Anatomy of a Machine-Checkable Rule

Many decisions can be enforced by software, and the BREX data module is where they are written. Each structure object rule has the same parts:

objectPath: an XPath to the thing being governed, with allowedObjectFlag set to 0 (must not be used), 1 (must be used), or 2 (optional, as the specification allows).
objectUse: the rule in words.
objectValue: allowed values, as a single value, a range, or a pattern, each with a valueTailoring setting (restrictable, lexical, or closed) that says how far a lower layer may change it.

Around the structure rules sit SNS rules (the project's system breakdown), notation rules for permitted graphic and file notations, and narrative rules that software cannot check. The Issue 6 default BREX, the specification's own top layer, carries 272 rules.

Real Rules

Three From the Default BREX

A prohibition. Flag 0 forbids anything the path matches: here, any BREX data module not coded with information code 022 and item location D.

<structureObjectRule>
  <brDecisionRef brDecisionIdentNumber="BREX-S1-00268"/>
  <objectPath allowedObjectFlag="0">/dmodule[content/brex]/identAndStatusSection/dmAddress/dmIdent/dmCode[@infoCode!="022" or @itemLocationCode!="D"]</objectPath>
  <objectUse>The information code for a BREX data module is 022, and the item location code is set to D. (Chap 4.10.2.4, Para 2).</objectUse>
</structureObjectRule>

An allowed-values list. Security classifications 01 to 09 are fixed; the range 51 to 99 is left for projects to define, and marked restrictable.

<structureObjectRule>
  <brDecisionRef brDecisionIdentNumber="BREX-S1-00231"/>
  <objectPath allowedObjectFlag="2">//@securityClassification</objectPath>
  <objectUse>Attribute securityClassification - Security classification (Chap 3.9.6.1, Table 64)</objectUse>
  <objectValue valueForm="single" valueAllowed="01"/>
  <!-- ... 02 through 09 ... -->
  <!-- Values within range 51~99 can be allocated and defined by projects or organizations -->
  <objectValue valueForm="range" valueAllowed="51~99" valueTailoring="restrictable"/>
</structureObjectRule>

A code list. Every valid information code, each restrictable, so a project can narrow the list to the codes it actually uses.

<structureObjectRule>
  <brDecisionRef brDecisionIdentNumber="BREX-S1-00180"/>
  <objectPath allowedObjectFlag="2">//dmIdent/dmCode/@infoCode</objectPath>
  <objectUse>Attribute infoCode - The data module information code (Chap 8.4.1, Para 1).</objectUse>
  <objectValue valueForm="single" valueAllowed="000" valueTailoring="restrictable">Function, data for plans and description</objectValue>
  <objectValue valueForm="single" valueAllowed="001" valueTailoring="restrictable">Title page</objectValue>
  <!-- ... the full information code list ... -->
</structureObjectRule>

From Decision to Rule

What a Project Layer Adds

Because those values are restrictable, a program can narrow them. Suppose a program decides it will only ever use two security classifications. Recorded as a business rule and written into the project BREX, it might look like this (an illustration, not a rule from the specification):

<!-- Illustrative project rule, not from the specification -->
<structureObjectRule>
  <objectPath allowedObjectFlag="2">//@securityClassification</objectPath>
  <objectUse>This program uses classifications 01 and 02 only.</objectUse>
  <objectValue valueForm="single" valueAllowed="01"/>
  <objectValue valueForm="single" valueAllowed="02"/>
</structureObjectRule>

From then on, every data module that uses any other classification fails validation while it is being written, not in a delivery review. That is the whole case for business rules: decisions made once, early, and enforced everywhere. The program start checklist lists the ones to settle first, and open tools like s1kd-tools can run a BREX against your modules for free (see our free tools guide).

FAQ

Questions We Hear

What is a BRDP in S1000D?

A business rules decision point: one decision the specification leaves to each project. Each has a permanent identifier in the form BRDP-S1-NNNNN for decision points that originate in S1000D; for example BRDP-S1-00003 is the decision on which issue of S1000D to use. Organizations can define their own decision points with their own prefix.

What is the difference between business rules and the BREX?

Business rules are the project's decisions, written down, usually in a business rules document. The BREX is the machine-checkable subset: rules expressed as paths and allowed values that validation software can enforce against every data module. Many rules can be enforced this way; some remain narrative.

What are the S1000D business rules categories?

Issue 4.2 defines ten: general; product definition; maintenance philosophy and concepts of operation; security; business process; data creation (text, and illustrations and multimedia); data exchange; data integrity and management; legacy data conversion, management and handling; and data output.

Where do I find the list of decisions a project has to make?

In the specification package. It includes a business rules project decision point index and a business rules template, which together map the decisions and give a structure for recording them. Read them early: they show where the specification ends and the project begins.

Get In Touch

Writing Your Business Rules?

We help programs make their business rules decisions early, record them clearly, and enforce them in the BREX, and we teach their teams to own them afterward.

Contact Shakewell LLC Prefer to build it in-house? We'll teach your team

or email hello@shakewell.agency