Pete Brink from UL Solutions led an ELISA seminar on the basics of requirements engineering. He explained why teams write requirements, how to know when you are “done,” and how safety-critical work raises the bar. Requirements describe what a system must do and how well it must do it, not how to implement it. They can be functional (including safety and security behavior) or non-functional (performance, resource, thermal, mechanical, usability, and similar constraints). Pete stressed an iterative process: elicit from stakeholders, analyze and validate, write the spec, verify requirement quality, and then do architecture, design, coding, and testing. Testing spans unit, component, integration, and acceptance to prove the requirements were fulfilled. He noted that language is imprecise, so clarity, atomicity, unique IDs, status, allocation, and traceability are essential. Text can be supported with diagrams and models (semi-formal); full formal notation is used rarely. Tooling in practice often includes markdown in GitHub; community tools like StrictDoc and others are emerging, but traceability remains hard.
Pete showed weak vs. improved requirements, fixing ambiguity like “regular intervals” and splitting “and/should” into separate, testable statements with precise timing and tolerances. He introduced EARS (Easy Approach to Requirements Syntax) to give simple, consistent sentence patterns, including ubiquitous, event-driven, state-driven, and optional-feature forms (useful for things like debug vs. release or hardware variants). Detail should match criticality: too little raises risk; too much raises cost. Open source adds challenges because code often exists first; teams may derive requirements from observed behavior or refactor to align with clearer, testable specs. In Q&A, attendees discussed automotive vs. aerospace use of formal methods, handling hardware variants and build types, and authoring options like LaTeX and Sphinx.
The core message: write clear, atomic, testable requirements, keep them implementation-free, manage them with discipline, and iterate whenever design and testing reveal issues.
ELISA Project Seminar Series focuses on hot topics related to ELISA’s mission to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification. Speakers are members, contributors and thought leaders from the ELISA Project and surrounding communities. Each seminar comprises a 45-minute presentation and a 15-minute Q&A, and it’s free to attend.
Watch the previous Seminar series here.
