Identifying Assumptions, Constraints, Risks, and Dependencies in Discovery Notes

Welcome back. In the previous lesson, you prepared discovery questions that seek evidence rather than opinions: real workflow steps, decision rules, systems, exceptions, delays, and measurable outcomes. Those conversations produce valuable notes, but notes are not yet requirements. They contain a mixture of verified facts, beliefs, fixed limits, unresolved questions, and potential failure points.

This lesson gives you a disciplined way to extract assumptions, constraints, risks, and dependencies from those notes. This is particularly important when moving into an unfamiliar domain: instead of silently accepting a statement such as “payroll will handle that” or “we must launch by quarter-end,” you record what it means, who must validate it, and what could happen if it is untrue or unmet.

By the end, you should be able to turn raw discovery statements into clear, traceable entries that a sponsor, developer, tester, or delivery lead can act on.

---

Four categories that prevent costly misunderstandings

A useful starting point is to treat these categories as different kinds of uncertainty or limitation—not as interchangeable project vocabulary.

Here is the practical distinction.

Category	Meaning	Discovery-note example	What the analyst must do
Assumption	Something treated as true for planning, but not yet proven	“The payroll system can accept a daily reimbursement file.”	Record it, identify the evidence needed, assign an owner to validate it.
Constraint	A fixed limitation or restriction on the solution or delivery approach	“No custom code may be added to the existing payroll product.”	Confirm who imposed it, its rationale, and whether it is truly fixed.
Dependency	A linkage where one item, team, decision, system, or deliverable relies on another	“UAT cannot begin until the payroll vendor supplies masked test data.”	Identify what is needed, from whom, by when, and what work is affected.
Risk	An uncertain event or condition that could have an effect if it occurs	“If masked test data is late, UAT and the release decision may be delayed.”	State the condition and consequence; record ownership and an initial response.

The critical word is uncertain. A risk might happen, but has not happened yet. If a problem already exists, it is an issue.

For example:

• “The payroll vendor has not supplied the promised test file, and UAT was due to begin yesterday” is an issue.
• “The payroll vendor may not supply the test file by the agreed date” is a risk.
• “We assume the vendor will supply the file by the agreed date” is an assumption.
• “UAT requires the vendor’s masked test file” is a dependency.

The same real-world situation can therefore create several linked records. That is not duplication when each record has a distinct purpose.

---

Read discovery notes as evidence, not as instructions

Discovery notes often contain statements like these:

“Finance believes daily payroll files should be possible.”

“We need to launch before the current vendor contract ends.”

“Managers must not see employee bank-account details.”

“The approval workflow cannot be tested until the identity team creates test accounts.”

None of these statements should immediately become a requirement. First, identify what the speaker is actually claiming, how certain it is, and what action the team needs to take.

A useful sequence is:

1. Preserve the original statement. Record the source, date, stakeholder role, and any supporting artifact such as a policy document, report, or ticket.
2. Separate evidence from interpretation. “The monthly report shows 38% of claims exceeded five days” is evidence. “Manager approvals are the main cause” is an interpretation that needs validation.
3. Classify the statement. Decide whether it is an assumption, constraint, dependency, risk, issue, business rule, open point, or confirmed fact.
4. Rewrite it precisely. Remove vague wording such as “should be fine,” “quickly,” “seamlessly,” or “as usual.”
5. Assign a next action. Validation, confirmation, mitigation, escalation, documentation review, or ownership clarification.

The objective is not to create a large register. It is to make important uncertainty visible while it can still be managed.

Do not force every statement into ARCD

ARCD is a useful shorthand for assumptions, risks, constraints, and dependencies. But discovery sessions also reveal other types of information.

What you hear	Better classification	Why it is not automatically ARCD
“Claims above INR 10,000 require finance-controller approval.”	Business rule	This describes a condition and outcome. It needs validation, but it is neither inherently a risk nor a constraint.
“Last month, 38% of claims missed the five-day reimbursement target.”	Fact, if supported by a report	The figure establishes a baseline. Record its source and calculation.
“The cost-centre field is missing on many submitted claims today.”	Issue	The problem is already occurring. It needs investigation and resolution, not merely risk monitoring.
“Can the payroll system support multiple currencies?”	Open point	The answer is unknown. Assign an owner and a due date.
“The system must validate cost-centre values before submission.”	Candidate requirement	It describes desired product behavior. Its rationale may originate in a current issue or risk.

A strong analyst does not simply label everything “risk.” They preserve the difference between a current problem, an uncertain future event, a fixed restriction, and a planned capability.

---

A quick classification test

When a note is ambiguous, use the following questions in order.

1. Is it already true and supported by evidence?

If yes, it is likely a fact, business rule, or issue.

• “The expense policy requires receipts for claims above INR 500” may be a confirmed policy rule.
• “The report was unavailable this morning” is an issue.
• “The process includes an overnight payroll batch” may be a fact about the current state.

The analyst should still document source and owner. “Finance said so” is not the same as a policy document or system evidence.

2. Is it being treated as true without adequate evidence?

If yes, it is an assumption.

Typical signals in notes include:

• “We expect…”
• “It should…”
• “Probably…”
• “We believe…”
• “The vendor will…”
• “Users will…”
• “There should be no impact…”

For example:

“The finance team believes that managers will approve claims within 24 hours once reminders are introduced.”

This is an assumption. It may be reasonable, but it still requires evidence such as historical approval-time data, manager interviews, or a pilot.

3. Does it limit what the project or solution is allowed to do?

If yes, it is a constraint.

Typical signals include:

• “Must not…”
• “Cannot…”
• “Only…”
• “No budget for…”
• “Must comply with…”
• “Must be delivered by…”
• “The existing platform has to be used…”

For example:

“No custom code may be added to the payroll application.”

This restricts solution options. A configurable approach, a separate integration component, or a process change may still be possible, but custom changes within the payroll product are excluded.

Be careful with the word must. It does not always indicate a constraint:

• “The system must display the reimbursement status” is a candidate requirement.
• “The solution must use the existing identity provider” is a constraint.
• “The policy must be approved before implementation begins” may be a dependency.

The context and source determine the classification.

4. Does something need to be completed, available, approved, or maintained for another activity to succeed?

If yes, it is a dependency.

Dependencies may be:

• Delivery dependencies: stakeholder availability, procurement, approval, test-data delivery, another project, environment readiness.
• Solution dependencies: an API, source-data feed, identity provider, vendor platform, shared data model, notification service.
• Requirement dependencies: two requirements that must be delivered together to preserve a valid business outcome.

For example:

“The status portal can show payment confirmation only after payroll publishes the payment-status file.”

The portal depends on the payroll system’s output. This is a solution dependency. If the feed is uncertain or unreliable, it also creates a risk.

5. Can you state an uncertain condition and a consequence?

If yes, it is a risk.

A useful format is:

If [uncertain condition] occurs, then [consequence] may affect [project or solution outcome].

For example:

If the payroll system cannot accept daily reimbursement files, then employees may continue to wait for the next scheduled batch, preventing the intended reduction in reimbursement time.

That is a requirements risk because the consequence affects the product’s intended outcome for users.

Compare it with:

If the payroll vendor does not confirm file-format feasibility by 15 August, then the development schedule may be delayed.

That is a project risk because its primary effect is on delivery time.

---

Project-level and requirement-level analysis

The same discovery note can matter at two levels.

• At the project level, ask: could this affect time, cost, scope, staffing, approval, or delivery?
• At the requirement or solution level, ask: could this affect product behavior, data accuracy, security, usability, regulatory compliance, or business operations?

Consider the note:

“The existing payroll package must be used without custom coding.”

At the project level, this may be a constraint on budget, procurement, timeline, and implementation approach.

At the requirement level, it may create a risk: if the package cannot be configured to preserve exact reimbursement amounts, financial records may be inaccurate. The constraint remains the restriction; the risk describes the uncertain consequence of working within it.

This distinction matters in interviews. A Technical Business Analyst is expected to recognize both:

• the delivery concern a project manager may need to manage; and
• the product exposure that developers, QA, operations, compliance, or business owners need to address.

---

Worked example: turn raw notes into an ARCD register

Assume that a Business Analyst has completed discovery interviews for an expense-claim status-visibility initiative. The sponsor wants to reduce employee enquiries about claim status and reduce reimbursement delays.

The following notes are intentionally realistic: they contain facts, beliefs, restrictions, and incomplete statements.

Raw discovery note	Extraction	Why
“Finance believes payroll can accept a reimbursement file every day instead of twice weekly.”	Assumption A-01: Payroll can accept and process a daily reimbursement file without unacceptable operational impact.	The word “believes” signals that this is not yet proven.
“The payroll vendor contract ends on 30 September, and leadership has set that date as the deadline for the first release.”	Constraint C-01: The first release must be ready for production use by 30 September.	The deadline restricts delivery options. Confirm that leadership has formally approved it.
“The portal needs payment confirmation from payroll before it can show a claim as paid.”	Dependency D-01: Claim-status display depends on payroll publishing payment confirmation.	The portal’s status depends on another system’s information.
“UAT cannot start until the identity team provisions test accounts for employees, managers, and finance approvers.”	Dependency D-02: UAT depends on identity-team provisioning of role-specific test accounts.	Another team must provide a prerequisite.
“Line managers must not view employees’ bank-account details.”	Constraint C-02: Access to employee bank-account details is restricted to authorized finance roles.	This is a security and privacy boundary. It may later lead to authorization requirements.
“The last report showed 38% of claims exceeded the five-day target.”	Fact F-01: In the named report period, 38% of claims exceeded the five-day target.	This is baseline evidence, assuming the report and calculation are available.
“Several claims are already failing because cost centres are blank.”	Issue I-01: Claims with blank cost centres are currently failing routing or processing.	The condition is happening now. Investigate its root cause and business impact.
“Claims above INR 10,000 need finance-controller approval.”	Business rule BR-01: If a claim value exceeds INR 10,000, finance-controller approval is required before payment processing.	This is a decision rule. Validate the threshold, exceptions, and policy owner.

Now convert only the uncertain, potentially harmful conditions into risks.

Risk ID	Source item	Risk statement	Level	Initial response
R-01	A-01: daily payroll-file assumption	If payroll cannot process daily reimbursement files, then the intended reduction in claim-to-payment time may not be achieved.	Requirement / solution	Ask the payroll owner to confirm supported frequency, throughput, cutoff times, and failure handling.
R-02	D-02: test-account dependency	If the identity team does not provide test accounts by the agreed date, then UAT and the release decision may be delayed.	Project	Assign an identity-team owner, due date, and escalation route.
R-03	C-02: restricted bank-account access	If bank-account data is exposed to unauthorized roles, then the organization may face privacy, security, and employee-trust impacts.	Requirement / solution	Confirm data classification, permitted roles, audit expectations, and access-control approach.
R-04	I-01: blank cost-centre issue	If new claims can still be submitted without valid cost centres, then routing failures and reimbursement delays may continue after release.	Requirement / solution	Confirm the authoritative cost-centre source and define validation behavior.

Notice the discipline in this analysis:

• The assumption is not deleted after writing the risk. It remains open until verified.
• The dependency is not itself a problem. It becomes a risk because timely delivery is uncertain.
• The existing blank-cost-centre problem is an issue, but it reveals a continuing solution risk if the new workflow fails to prevent or handle invalid input.
• The security constraint is not merely a statement of intent. It must influence solution design, access requirements, testing, and audit evidence.

---

Record assumptions so they do not become invisible “facts”

Assumptions are necessary. Analysis cannot stop every time information is incomplete. The problem arises when the team forgets that a planning premise was unproven.

For discovery work, a simple assumptions log can use the following structure.

Field	Purpose
ID	Gives the item a stable reference, such as A-01.
Statement	States exactly what is being assumed.
Source and date	Records who stated it and when.
Confidence	Indicates how credible the assumption currently is: low, medium, or high.
Impact if false	Identifies the likely delivery or solution consequence.
Validation action	States what evidence will confirm or disprove it.
Owner	Names the person accountable for obtaining or confirming evidence.
Review date	Prevents the item from being forgotten.
Status	Open, validated, disproven, superseded, or converted to risk/issue.

A well-written assumption is testable:

• Weak: “The vendor integration should work.”
• Better: “The payroll vendor’s existing API supports retrieval of payment status for an individual claim within the agreed operational window.”
• Validation action: “Integration lead to review API documentation and demonstrate a test response by 12 August.”

The better version identifies the assumed capability, makes validation possible, and avoids prematurely claiming success.

---

A practical extraction routine for every discovery session

After a stakeholder interview or workshop, reserve 15 to 20 minutes for structured note review. Do not wait until the end of the project. Risks and dependencies are easier to manage when they are found during discovery, before solution decisions harden.

Use this routine.

1. Mark trigger language in the notes

Look for terms that often indicate hidden assumptions, constraints, dependencies, or risks:

Language in notes	Possible interpretation
“We expect,” “should,” “probably,” “will”	Assumption
“Must,” “cannot,” “only,” “not permitted,” “by this date”	Constraint, rule, or requirement
“Until,” “before,” “after,” “depends on,” “requires”	Dependency
“What if,” “failure,” “delay,” “unavailable,” “incorrect,” “unauthorized”	Risk, issue, exception, or control gap

These are prompts, not automatic classifications. For example, “The system must send an email” might be a requirement rather than a constraint.

2. Rewrite each important item as one clear statement

Avoid bundled statements such as:

“The finance team must approve high-value claims quickly, and payroll should process them daily.”

This includes at least three separate ideas:

1. a finance-controller approval rule;
2. a performance expectation about approval time;
3. an assumption about daily payroll processing.

Splitting statements makes each one testable and assignable.

3. Identify source, authority, and evidence

Ask:

• Who made this statement?
• Do they have authority to define the rule or constraint?
• Is there a policy, contract, system document, report, or historical data that supports it?
• Does another stakeholder need to confirm it?

A sponsor may set a business outcome but not know the technical capability of an API. A technical lead may know system limits but not have authority to relax a regulatory constraint. Record both the statement and the appropriate validating owner.

4. Convert high-impact uncertainty into a risk statement

Use the format:

If [condition] occurs, then [consequence] may affect [delivery objective or solution outcome].

Avoid vague risk statements:

• Weak: “Integration risk.”
• Weak: “Payroll may fail.”
• Better: “If the payroll payment-status file is delayed beyond the portal refresh window, then employees may see outdated claim statuses and continue to raise status enquiries.”

The better version gives the team something concrete to analyze and test.

5. Link, do not duplicate

A risk should reference the assumption, dependency, constraint, issue, or requirement from which it arose.

For example:

Item	ID	Linked item
Assumption: Payroll supports daily files	A-01	R-01
Dependency: Payroll provides payment status	D-01	R-05
Constraint: Existing identity provider must be used	C-03	R-06
Issue: Cost-centre values missing	I-01	R-04, candidate validation requirement

This traceability is valuable in a requirements walkthrough. It allows you to explain not only what was documented, but why it matters and where it originated.

---

Common mistakes to avoid

Treating stakeholder confidence as proof

“Finance is confident” may be useful input, but confidence is not evidence. Treat it as an assumption until reports, technical confirmation, policy documentation, or another reliable source validates it.

Calling a current problem a risk

If an environment is already unavailable, data is already incorrect, or a stakeholder is already blocking approval, log an issue. A risk response is not enough; the team needs an immediate resolution path.

Calling every desired behavior a constraint

A constraint restricts possible choices. A requirement describes a needed capability or condition. “Employees must receive a status update” is likely a requirement. “Status updates must use the existing corporate notification service” is a constraint.

Recording dependencies without an owner or date

“Depends on identity team” is not actionable. Record exactly what is needed, who provides it, the required date, acceptance criteria, and escalation route.

Writing risks without consequences

A risk statement must help prioritization. “Vendor delay” says little. “If the vendor does not approve the interface specification by 20 August, then development cannot begin and the planned September release may be delayed” enables action.

Solving the problem while still extracting it

During discovery, avoid jumping immediately to “build a dashboard,” “add a reminder,” or “create a new API.” First establish the evidence, limitation, dependency, and exposure. Solution options can then be assessed against a better understanding of the problem.

---

Key takeaways

Discovery notes contain different kinds of information. Your role is to make their status explicit:

• An assumption is treated as true without sufficient proof.
• A constraint is a fixed limitation on the project or solution.
• A dependency is a linkage that another activity, decision, team, or system must satisfy.
• A risk is an uncertain condition with a potential consequence.
• An issue is a problem already happening and needing resolution now.

Preserve the source statement, classify it carefully, validate its authority and evidence, and convert meaningful uncertainty into a clear conditional risk statement. Keep related items linked so that requirements, risks, decisions, and delivery actions remain traceable.

Next, you will use the evidence collected during discovery to define clear in-scope and out-of-scope boundaries for a proposed change.