E6 · Publication Volume 28

Requirements and Professional Boundaries

user roles, decisions, risk, scope and non-goals

*user roles, decisions, risk, scope and non-goals*

Decision, role, evidence, risk and non-goal boundaries for a geoscience system
Decision, role, evidence, risk and non-goal boundaries for a geoscience system

Learning objectives

This lesson is general and institution-neutral. It uses no real company, individual, property, project or identifiable place. Generic roles describe responsibilities only, and SYN-ARCH identifiers denote explicitly synthetic teaching evidence.

  • Frame the decision governed by user roles, decisions, risk, scope and non-goals.
  • Model the relevant boundaries, states and contracts before selecting an implementation.
  • Define measurable invariants, failure evidence and a safe release consequence.
  • Produce a decision-centred requirements and professional-boundary register from synthetic evidence and defend its trade-offs.

Decision boundary

Start with the decision the system may support and the decision it must not make. Identify the acting role, affected parties, admissible evidence, decision horizon, consequence of error, escalation path and accountable approval. A request such as “build a geological dashboard” is not a requirement because it omits the decision and response measure. Replace it with a bounded scenario: a reviewing role must locate conflicting interval states within a declared dataset version, explain the conflict from source records and withhold publication when identity or reference is unresolved. Non-goals are first-class constraints; they stop convenience features from silently becoming professional conclusions.

Core concepts

Separate stakeholder need, system requirement, software requirement, policy constraint and acceptance evidence. Needs describe desired outcomes; requirements state verifiable obligations; design decisions choose one way to satisfy them. Mixing these levels makes alternatives appear mandatory and hides why a component exists. Functional suitability is only one quality concern. Reliability, security, performance efficiency, compatibility, maintainability, usability, safety-related consequences and portability can alter the acceptable architecture. Professional boundaries add a further question: which statements require competent domain judgement, independent review or statutory authority outside the software boundary?

System model and contracts

Maintain a trace graph with stable identifiers for role, decision, concern, requirement, risk, control, acceptance test and released artefact. Each requirement records source, rationale, priority, verification method, applicability, version and status. Quality requirements use a scenario with stimulus, environment, affected element, response and response measure. A context model marks people, external systems, trust boundaries, evidence flows and excluded responsibilities. A professional-boundary table separates calculation, presentation, recommendation, approval and publication. Architecture decisions point back to the requirements they address and forward to tests and telemetry that keep those claims observable after release.

Invariants and acceptance criteria

| Invariant | Test evidence | Release consequence | |---|---|---| | Every system behaviour traces to a decision, requirement or explicit non-goal. | contract test and recorded counterexample | block publication | | Professional approval remains assigned to an authorised human role. | replay comparison and digest check | quarantine the artefact | | Every applicable requirement has a verification method and release consequence. | role-based acceptance trace | return the decision unresolved | | Waivers are scoped, approved, time-bounded and reviewable. | failure injection and recovery record | retain the last verified version | | Synthetic evidence is never represented as observed operational evidence. | domain review against declared evidence | record an explicit review finding |

Quantitative engineering

Traceability coverage is C_t=n_{verified}/n_{applicable}, where the denominator contains applicable requirements for the release and the numerator contains requirements linked to passing evidence. Report missing, ambiguous and waived items separately; a high ratio cannot excuse one untested high-consequence requirement. For a screening model, expected exposure may be written E=p_1c_1+p_2c_2+...+p_nc_n, but probabilities and consequences must be sourced or explicitly bounded rather than invented. Use risk classes when numerical calibration is unavailable. Acceptance measures need a population, environment, threshold, observation window and release consequence.

Data quality, evidence and uncertainty

Requirements evidence includes observed tasks, decision records, representative datasets, error histories, applicable policies and direct review findings. Interview statements are inputs, not automatically authoritative requirements. Record who supplied each statement, the context, conflicting accounts and how the requirement was resolved. A synthetic example can test structure and failure handling, but cannot establish the frequency, severity or acceptability of a real operational risk. Unknown legal, safety or professional obligations remain open dependencies assigned for external review; the architecture must not conceal them behind a generic “compliance” label.

Interoperability and versioning

Give requirements and acceptance tests machine-stable identifiers independent of document headings. Exchange fields include identifier, statement, rationale, role, decision, risk link, verification method, status, valid interval and supersession relation. Version the requirement set and preserve the baseline used by each release. When wording changes without changing obligation, retain identity and record a revision; when obligation changes incompatibly, issue a new identity or declared major contract version. Exports must preserve links and controlled terms, not flatten a graph into prose that cannot be rejoined.

Security and professional responsibility

Requirements may expose sensitive locations, vulnerabilities, personal responsibilities or privileged workflows. Classify access at the object level and collect only what is necessary for the decision. Do not place secrets, credentials or exploitable implementation detail in broadly distributed requirement documents. Separation of duties matters when the same role could define, implement, verify and approve a high-consequence control. A waiver records scope, reason, compensating control, approver role, expiry and review trigger. Security language must remain testable; “secure”, “industry standard” and “best practice” alone are not acceptance criteria.

Operational workflow and observability

Treat requirement change as an observable workflow: propose, analyse impact, resolve conflict, approve, implement, verify, release and monitor. A release candidate declares its requirement baseline and emits results for each applicable acceptance test. Operational signals test assumptions such as volume, latency, rejection rate and role behaviour. When a threshold fails, link the event to the requirement and decision rather than opening an unclassified defect. Periodic review checks stale assumptions, unused controls and non-goals that users are trying to bypass. Emergency changes still need retrospective trace and explicit expiry.

Integration checkpoint

Connect the requirements and professional boundaries artefact to the preceding volume architecture. Trace one synthetic object from source identity through the new boundary to a reviewed output, then trace one rejection or failure back to the earliest violated invariant. Update the architecture decision record with the chosen option, alternatives, assumptions, evidence, consequences, owner role, review state and triggers for reconsideration. A checkpoint passes only when another reviewer can reconstruct both the successful path and the blocked path without oral explanation.

Synthetic worked example

SYN-ARCH-01 begins with the request “automatically approve valid datasets”. Decomposition reveals three decisions: structural validation, domain fitness and publication approval. The system may calculate structural findings and assemble evidence, but only a designated review role may decide domain fitness and release. The requirement set defines a blocked state for unresolved coordinate reference, a measurable response for duplicate identity and a non-goal forbidding automatic geological endorsement. A trace review finds that the “fast upload” requirement has no population or percentile, so it is returned for clarification rather than guessed.

Practice and assessment

  1. What decision and error consequence does this requirement govern?
  2. Which responsibility is deliberately outside the software boundary?
  3. What evidence would make the requirement pass, fail or remain unresolved?
  4. When must a changed requirement receive a new identity?

Assessed artefact: a decision-centred requirements and professional-boundary register. Submit the artefact with its source manifest, acceptance evidence, unresolved risks and a short explanation of why one plausible alternative was not selected.

Common failure modes

  • Writing a component wish list instead of decision-centred requirements.
  • Embedding one design choice in a requirement without analysing alternatives.
  • Allowing software to cross an undeclared professional approval boundary.
  • Using vague quality words without environment, population or threshold.
  • Treating a synthetic demonstration as evidence of real operational acceptability.

Sources and further reading