Requirements for a public-sector system: decisions, data and acceptance

The core decision

Requirements should translate the management objective into roles, scenarios, data, rules, integrations and verification criteria. “The system must be convenient” is not testable and cannot replace a scenario. For this task, the initial evidence is “one object is duplicated across registers”, and the decision boundary concerns scenarios, directives and control.

The practical focus is connecting goals, programmes, measures, registers, projects and directives with verifiable execution. A decision is ready for approval when the object, owner, baseline, permitted action and outcome evidence are explicit; the reference object in this article is activities and projects.

Official sources for a public-sector environment

Federal Law No. 149-FZ provides the general legal context for information and information systems. Applicable requirements are mapped to scenarios, directives and control, a specific process stage and an accountable owner; other specialised rules are determined from the actual project scope.

The requirements register distinguishes a legal rule, an organisational decision and technical implementation. Each entry identifies the official source, current version, interpretation owner, affected data and evidence of fulfilment; the control signal here is “one object is duplicated across registers”.

Diagnosis before solution selection

The work starts with an observable situation, not with interface selection. The diagnostic signal for this article is: one object is duplicated across registers. It should be supported by a real example such as a document, data sample, decision record or registered variance.

The first scope is limited to one object and one decision. Changing every process, master-data set and system at once obscures causality. For the signal “a situation centre only visualises data”, a representative boundary is a period, business unit or transaction class where the situation can be tested again.

• Observation 1: One object is duplicated across registers. Required fields: frequency, source and consequence for goals and public programmes.
• Signal: A measure is disconnected from an activity. Evidence includes an example, frequency and consequence for activities and projects.
• Event to test: a situation centre only visualises data. Evidence shows timing, frequency and consequence for measures and sources.

Objects under management

The subject model starts with two reference objects: scenarios, directives and control and goals and public programmes. They may reside in different systems, so each needs an identifier and owner; their relationship is tested through the action “describe the main and exception scenarios”.

The primary boundary is scenarios, directives and control. Its system of record, semantic owner, quality owner, refresh cycle and permitted transformations are documented. An error is also defined explicitly: who corrects it and how the change reaches dependent reports, plans or documents.

• Object 1: Goals and public programmes. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: One object is duplicated across registers.
• Subject area 2: Activities and projects. Verification basis: system of record, owner authority and the signal “a measure is disconnected from an activity”.
• Record 3. Object: Measures and sources. Required details: identifier, lineage, quality rule and update event. Signal: A situation centre only visualises data.

From signal to decision

The article addresses “Requirements for a public-sector system: decisions, data and acceptance”. The adjacent management issue is decisions, data and acceptance. The two may share data or participants while differing in decision horizon, role authority and architecture boundary, so they are documented as separate entries in the decision map.

A signal–risk–action chain defines the subject-specific focus. Here the signal is “a situation centre only visualises data”, the material risk is “one platform without an authority model”, and the testable action is “describe the main and exception scenarios”. This chain turns a broad term into a concrete decision.

• Decision 1: object — goals and public programmes; signal — execution cannot be verified against a source; action — agree verification criteria.
• Decision 2: object — activities and projects; signal — one object is duplicated across registers; action — link the objective to a user decision.
• Decision 3: object — measures and sources; signal — a measure is disconnected from an activity; action — describe the main and exception scenarios.

From objective to testable scenario

For goals and public programmes, the sequence begins with “agree verification criteria”. The owner of the next step reviews its output; an incomplete result is returned with a specific issue concerning data, a rule, authority or an architecture dependency.

Maintain an assumptions log for goals and public programmes. Each entry states its basis, owner, review date and the event after which it must be confirmed, changed or closed.

• Stage 1: link the objective to a user decision. The working artefact describes goals and public programmes.
• Stage gate 2 connects the action “describe the main and exception scenarios” with the result “activities and projects”.
• 3. Action: define data and rules; verifiable result: measures and sources.
• Decision 4: identify non-functional constraints. The basis for the next step is registers and sector systems.

Integration contract

An integration design begins not with arrows between applications but with events and accountability. It defines who creates a record, where it becomes authoritative, which checks run before transfer, how duplicates are handled and which action is blocked when records disagree. The reference object here is goals and public programmes.

Every exchange has a business owner, technical owner and observable control point. API, messaging, file transfer or another technology is selected after frequency, volume, resilience and error behaviour are known. For the signal “one object is duplicated across registers”, quality is assessed before transfer and after loading so that the origin of a discrepancy can be located.

• Boundary 5. Object: Scenarios, directives and control. Define the source, frequency, permitted transformations and response to “execution cannot be verified against a source”.
• Control record 4. Object: Registers and sector systems. Observable signal: A project is not linked to a programme goal. Accountability: semantic owner and quality owner.
• Record 3. Object: Measures and sources. Required details: identifier, lineage, quality rule and update event. Signal: A situation centre only visualises data.

End-to-end outcome test

Verification of activities and projects starts with the baseline. The sample, period, calculation rule, known exceptions and interpretation owner are preserved. After the change, the same scenario is repeated under comparable conditions; a new method or data population is documented as a separate version.

A functioning feature is not yet acceptance evidence. A user must receive the signal “one object is duplicated across registers” from the agreed source, understand its lineage, make an authorised decision, execute the action through the working environment and observe confirmed actuals for scenarios, directives and control.

• Test 1 concerns goals and public programmes. The method, interpretation owner and outcome source are documented. Signal: A situation centre only visualises data.
• Control record 2: Activities and projects; data version, calculation rule, expected change and actual outcome. Signal: A project is not linked to a programme goal.
• Criterion 3 uses measures and sources; the result is compared with the baseline using one method. Signal: Execution cannot be verified against a source.
• Criterion 4: Registers and sector systems; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: One object is duplicated across registers.

Authority and escalation

Build the authority matrix around decisions concerning activities and projects. Assign the right to change a rule, duty to prepare data, authority to approve an exception and accountability for confirming the outcome separately.

Define the escalation path for “agree verification criteria” concerning activities and projects in advance. The business owner is accountable for decision meaning, the data owner for evidence fitness, the architect for dependency integrity and the project manager for the agreed work sequence.

• Business owner decides within goals and public programmes; the basis is prepared through “describe the main and exception scenarios”.
• For activities and projects, the assigned role is Architect; its control duty is to define data and rules.
• Data owner: authority is linked to measures and sources, and participation is tied to “identify non-functional constraints”.
• In the decision matrix, project manager connects registers and sector systems with the action “agree verification criteria”.

Constraints and risk control

For the risk “one platform without an authority model”, define an observable condition and control decision. The record also includes the owner, response time, execution evidence and rollback rule if the control fails.

Verify the regulatory basis against an official source and current version. Map it to goals and public programmes in a requirement–process–data–control matrix and assign an owner for interpretation.

• Risk record 1. Condition: Claiming access to public-sector data. Control action: Link the objective to a user decision. Evidence source: Measures and sources.
• Risk: One platform without an authority model. Control: describe the main and exception scenarios. Evidence: registers and sector systems.
• Risk condition 3: Requirements without a current official regulatory source. Response: Define data and rules. Testable evidence: Scenarios, directives and control.
• The risk scenario “centralisation without sector data owners” is addressed through “identify non-functional constraints” and confirmed using goals and public programmes.

First working session

The first working session on scenarios, directives and control uses real material: a transaction example, report or plan, systems diagram, role list and the variance “one object is duplicated across registers”. Participants select one scenario, identify data gaps and perform the action “agree verification criteria”.

The output is a decision pack: problem statement, object map, baseline sample, owners, dependencies, verification criteria and open questions. The risk “one platform without an authority model” helps determine the next format: a pilot, architecture discovery, competitive selection or process correction without a new system.

• Stage 1: link the objective to a user decision. The working artefact describes goals and public programmes.
• Stage gate 2 connects the action “describe the main and exception scenarios” with the result “activities and projects”.
• Criterion 4: Registers and sector systems; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: One object is duplicated across registers.
• Criterion 5. Object: Scenarios, directives and control. Test fields: baseline, target change, source and owner. Signal: A measure is disconnected from an activity.