Skip to content

Requirements

The question this discipline answers

What must be true, and why?

Requirements connect the problem to the solution. A need says what someone expects, in their own language. A requirement is an obligation the solution must meet, and it exists because something drove it: a need, a hazard, a threat, or an existing component's limits. MEMO records that driver as a typed relationship, so every requirement can answer "why does this exist?" and every need can answer "what did we do about it?".

Requirements run across the architecture layers. A requirement can be about the whole system, the software, the hardware, or the instructions for use, and it is satisfied by elements in any layer.

Namespace: memo::assurance::requirements · Source: src/assurance/requirements/

Key elements

Needs. A Need is a problem-space expectation stated in stakeholder language. Its needKind classifies it as a design input in ISO 13485 and IEC 62366-1 terms: stakeholder, user, clinical user, patient user, business, service, regulatory, operational, or design control. A user need says whose need it is with HeldBy. The user's characteristics live on the User, not restated on the need.

Requirements. A Requirement is a solution-space obligation. It records:

  • requirementType: what it is about, which is the system, the software, the hardware, or the instructions for use (EU MDR Annex I §23.4, ISO 20417).
  • sourceKind and concernKind: where it came from and which concern it serves.
  • statement, with an authoring notation such as EARS, an obligation (shall, should, will), and the parsed condition and response clauses, so tools can check the pattern.
  • safetyClass for a software requirement (IEC 62304).
  • acceptanceCriteria, which a verification case checks.

Drivers and supporting definitions. A RiskDriver is a requirement driver that comes from risk: Risk and Threat both specialise it, which is what lets a hazard or a threat be the source a requirement derives from. A SystemConstant is a named constant from a source requirements document, such as a tolerance, that requirement statements refer to. A NotificationSpec is one row of an alarm and notification table: a named notification, its priority, and the actions the system must take.

How it connects

  • Needs motivate use cases (Motivates) and are held by participants (HeldBy). See Operational.
  • Requirements derive from their drivers (DerivesFrom): from needs, from operational activities, from risks and threats, from components. The driver end accepts any element, because drivers are of many kinds.
  • Requirements are satisfied by design elements with native satisfy: a function, a hardware component, a software module, or a UI element. See the layer pages from Functional to Implementation.
  • Requirements are checked by verification cases, and the evidence they produce. See Verification and validation.
  • A security requirement is derived from a threat or a risk (DerivesCyberRequirement, in Core). SecurityRequirement itself is defined in Cybersecurity.

In the running example

The temperature alarm carries no requirements, so this example comes from the GPCA infusion pump. Here is a need, a hardware requirement, the needs it derives from, and requirements satisfied by software.

requirement needTimelyAlarms : Need {
    attribute :>> needKind = NeedKind::'stakeholder';
    @MemoIdentity { :>> providedId = "NEED-003"; :>> label = "TimelyAlarmNotification"; }
    attribute :>> statement = "Clinicians shall be notified promptly and unambiguously of any condition that interrupts or endangers therapy.";
    attribute :>> priority = "high";
requirement reqAlarmLoudness : Requirement {
    attribute :>> requirementType = RequirementTypeKind::hardware;
    @MemoIdentity { :>> providedId = "REQ-X-12"; :>> label = "AlarmSoundPressureLevel"; }
    attribute :>> statement = "The audible annunciator shall produce notification tones at the sound level defined by Audio_level_const (50 db for 2 seconds per interface spec I 8), distinguishable by priority.";
    attribute :>> sourceKind = RequirementSourceKind::extension;
    attribute :>> concernKind = ConcernKind::usability;
    attribute :>> status = ElementStatusKind::approved;
    attribute :>> acceptanceCriteria = "Calibrated SPL measurement meets Audio_level_const for each priority tone.";
    attribute :>> subjectDescription = "AudibleAlarmAnnunciator";
connection : DerivesFrom connect sourceDriver ::> needSafeTherapy to targetRequirement ::> reqPost;
connection : DerivesFrom connect sourceDriver ::> needEffectiveAnalgesia to targetRequirement ::> reqPumpAccuracy;
connection : DerivesFrom connect sourceDriver ::> needEffectiveAnalgesia to targetRequirement ::> reqBatteryBackup;
connection : DerivesFrom connect sourceDriver ::> needTimelyAlarms to targetRequirement ::> reqAlarmLoudness;
connection : DerivesFrom connect sourceDriver ::> needAuditableRecord to targetRequirement ::> reqEventLogging;
satisfy reqCs01 by gpcaSoftware.tlm;
satisfy reqCs01 by gpcaSoftware.outputBus;
satisfy reqCs18 by gpcaSoftware.systemStatus;
satisfy reqCs23 by gpcaSoftware.systemStatus;

The full inventory

Generated from src/assurance/requirements/.

Elements

Core concepts

Element SysML kind What it is
RiskDriver part def Risk driver definition specializing RequirementDriver.
Requirement requirement def Requirement definition specializing MemoRequirement.
SystemConstant part def Named constant defined by a source requirements document (e.g. CriSys GPCA App. A.4) and referenced from requirement statements.
NotificationSpec part def One row of a notification/alarm action table (e.g. CriSys GPCA REQ 59): a named notification, its priority, and the actions the system must take.

Needs

Element SysML kind What it is
Need requirement def Need definition specializing MemoNeed.

Connections at a glance

Each arrow is one relationship, from its source end to its target end. A grey box belongs to another layer.

flowchart LR
  MemoNeed["MemoNeed"]:::other
  OperationalParticipant["OperationalParticipant"]:::other
  Need["Need"]
  UseCase["UseCase"]:::other
  MemoNeed -->|HeldBy| OperationalParticipant
  Need -->|Motivates| UseCase
  classDef other fill:#eef1f4,stroke:#9aa7b2,color:#4a5a66

Relationships declared here

Relationship From To What it says
HeldBy MemoNeed OperationalParticipant Whose need this is. The holder is a modelled participant — a User, with the profile IEC 62366-1 asks for, or another operational participant — so "which users does this need serve" is a question the model answers rather than a sentence a reader interprets.

Relationships from elsewhere that reach this layer

Relationship Declared in From To What it says
Motivates operational Need UseCase Typed relationship from Need to UseCase.

Enumerations

Enumeration Values
RequirementTypeKind system, software, hardware, ifu
NeedKind user, clinicalUser, patientUser, business, service, regulatory, operational, designControl

Go deeper