Archives

A re-analysis of two systematic mappings, 237 studies in total, asking whether the adoption of use cases and user stories rests on evidence that they work. One study tests a technique against a baseline in which it is absent; it was published in 2002.

A requirements system carries four statement kinds with incompatible lifecycles: norm, change, state and verification. Whenever one artefact carries two of them, a specific traceability failure follows, predictable from the pair alone.

A controlled English for rules, based on SBVR and RuleSpeak: a necessity test that decides what is a rule at all, a closed keyword set, ten sentence patterns, fifteen statement types and five values for the Type field.

A six-level model describing software development as an information transformation from unspoken business intent to a working system: an artifact registry, a role model and a detailed analysis of the business analyst's work.

A field must accept only part of an existing enumeration. Define a narrower enumeration, or keep the full list and state the restriction as a rule? A decision rule drawn from subtyping, type systems and derivation by restriction.

A theoretical basis for modeling the EUDAMED domain: a real entity, an MDR-defined role and a EUDAMED record are three separate sorts, not one thing under different names, grounded in foundational ontology, institutional-fact theory and compliance theory.

Slides from a 2020 talk on business rules: a survey of colleagues that showed uneven practice, and what the OMG SBVR standard says about writing them.

Slides from a 2018 talk on what business requirements are and how they differ from a specification — with the answer looked for in Michael Jackson's problem frames.