How a business owner should define system requirements

Answer for management practice

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 “the architect is absent from portfolio decisions”, and the decision boundary concerns the investment decision.

The practical focus is decision rights across executives, business owners, architects and the delivery team. 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 data and process ownership.

Applied analysis: How a business owner should define system requirements

For “How a business owner should define system requirements”, separate the required outcome from the implementation method. Define the outcome through data and process ownership and the owner's decision; assess technical options only after that pair is explicit.

Prepare a real example of the signal “the architect is absent from portfolio decisions” and locate its point of origin. Then assign the action “describe the main and exception scenarios”, its owner and the permitted response time.

Test the action “identify non-functional constraints” in the operating environment connected to the investment decision. Separately document exception authority, escalation and evidence of execution.

• Working object: The investment decision.
• Diagnostic signal: The architect is absent from portfolio decisions.
• Response action: Describe the main and exception scenarios.
• Controlled risk: ROI without an assumptions model.

Where the problem becomes visible

The work starts with an observable situation, not with interface selection. The diagnostic signal for this article is: the architect is absent from portfolio decisions. 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 decision is escalated too late”, a representative boundary is a period, business unit or transaction class where the situation can be tested again.

• Event to test: the sponsor approves budget but does not remove blockers. Evidence shows timing, frequency and consequence for escalation and acceptance.
• Indicator: The business owner delegates requirements to IT. Analysis needs an actual example and the resulting change in the goal and acceptable outcome.
• Diagnostic signal 3: The architect is absent from portfolio decisions. Its record contains an example and impact on the investment decision.

Subject model and boundaries

The subject model starts with two reference objects: the investment decision and architectural constraints. They may reside in different systems, so each needs an identifier and owner; their relationship is tested through the action “identify non-functional constraints”.

The primary boundary is the investment decision. 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.

• Control record 1. Object: The goal and acceptable outcome. Observable signal: A decision is escalated too late. Accountability: semantic owner and quality owner.
• Boundary 2. Object: The investment decision. Define the source, frequency, permitted transformations and response to “the sponsor approves budget but does not remove blockers”.
• Object 3: Architectural constraints. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: The business owner delegates requirements to IT.

Management question

The article addresses “How a business owner should define system requirements”. The adjacent management issue is the investment decision. 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 decision is escalated too late”, the material risk is “ROI without an assumptions model”, and the testable action is “identify non-functional constraints”. This chain turns a broad term into a concrete decision.

• Decision 1: object — the goal and acceptable outcome; signal — the business owner delegates requirements to IT; action — describe the main and exception scenarios.
• Decision 2: object — the investment decision; signal — the architect is absent from portfolio decisions; action — define data and rules.
• Decision 3: object — architectural constraints; signal — a measure has no action owner; action — identify non-functional constraints.

From objective to testable scenario

For architectural constraints, the sequence begins with “describe the main and exception scenarios”. 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 architectural constraints. Each entry states its basis, owner, review date and the event after which it must be confirmed, changed or closed.

• Stage gate 1 connects the action “link the objective to a user decision” with the result “escalation and acceptance”.
• 2. Action: describe the main and exception scenarios; verifiable result: the goal and acceptable outcome.
• Decision 3: define data and rules. The basis for the next step is the investment decision.
• Step 4. Identify non-functional constraints. Output: architectural constraints.

End-to-end scenario data

Describe data exchange as a contract between owners. For architectural constraints, specify the triggering event, system of record, mandatory fields, pre-transfer control and the recipient's response to an error.

Choose the transport mechanism after frequency and resilience requirements are known. Check “the architect is absent from portfolio decisions” on both sides of the interface to distinguish a source error from transformation, delivery or loading failure.

• Record 5. Object: Escalation and acceptance. Required details: identifier, lineage, quality rule and update event. Signal: A measure has no action owner.
• Subject area 4: Data and process ownership. Verification basis: system of record, owner authority and the signal “the architect is absent from portfolio decisions”.
• Object 3: Architectural constraints. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: The business owner delegates requirements to IT.

Evidence that the solution works

The acceptance criterion for data and process ownership includes a baseline sample, calculation rule, expected change and source of the actual outcome. The interpretation owner confirms that comparison conditions have not changed.

The end-to-end test starts with “a decision is escalated too late”, passes through an authorised decision and “identify non-functional constraints”, and ends with an execution record. Interface defects and process nonconformities are logged separately.

• Evidence item 1 describes the goal and acceptable outcome, comparable test conditions and the person accountable for interpretation. Signal: The business owner delegates requirements to IT.
• Test 2 concerns the investment decision. The method, interpretation owner and outcome source are documented. Signal: The architect is absent from portfolio decisions.
• Control record 3: Architectural constraints; data version, calculation rule, expected change and actual outcome. Signal: A measure has no action owner.
• Criterion 4 uses data and process ownership; the result is compared with the baseline using one method. Signal: A decision is escalated too late.

Decision-rights matrix

Build the authority matrix around decisions concerning data and process ownership. 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 “describe the main and exception scenarios” concerning data and process ownership 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.

• For escalation and acceptance, the assigned role is Business owner; its control duty is to link the objective to a user decision.
• Architect: authority is linked to the goal and acceptable outcome, and participation is tied to “describe the main and exception scenarios”.
• In the decision matrix, data owner connects the investment decision with the action “define data and rules”.
• Project manager: decision area — architectural constraints; control action — identify non-functional constraints.

Controlling critical dependencies

The risk map starts with two conditions: “ROI without an assumptions model” and “collective accountability without an owner”. Each receives an observable event, decision owner, control and outcome that requires a stop or rollback.

Every assumption has an owner, supporting evidence and a review event. The risk “collective accountability without an owner” needs particular control here because its status affects the scope, delivery sequence and acceptance criterion.

• Risk condition 1: Collective accountability without an owner. Response: Agree verification criteria. Testable evidence: The investment decision.
• The risk scenario “mixing the sponsor and project-manager roles” is addressed through “link the objective to a user decision” and confirmed using architectural constraints.
• Controlled constraint: an architecture decision without a business rationale. The owner performs “describe the main and exception scenarios” and provides data and process ownership.
• For the risk “ROI without an assumptions model”, assign the action “define data and rules” and evidence “escalation and acceptance” in advance.

Materials for starting work

The first working session on the investment decision uses real material: a transaction example, report or plan, systems diagram, role list and the variance “the architect is absent from portfolio decisions”. Participants select one scenario, identify data gaps and perform the action “describe the main and exception scenarios”.

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

• Stage gate 1 connects the action “link the objective to a user decision” with the result “escalation and acceptance”.
• 2. Action: describe the main and exception scenarios; verifiable result: the goal and acceptable outcome.
• Criterion 4 uses data and process ownership; the result is compared with the baseline using one method. Signal: A decision is escalated too late.
• Criterion 5: Escalation and acceptance; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: The sponsor approves budget but does not remove blockers.