Prioritizing Functional Requirements from a Product Brief

Welcome. This course builds toward principal-level backend architecture for a cybersecurity platform: turning a business problem into an architecture that is secure, scalable, explainable, and defensible in a design review.

The first move is deliberately non-technical. Before choosing Rust service boundaries, event streams, storage engines, or models, you need a shared statement of what the product must do and what matters most for the first release. In this lesson, you will turn an ambiguous cybersecurity product brief into a small, traceable, prioritized set of functional requirements.

---

Start with intent, not a backlog of implementation tasks

A product brief is usually optimized for alignment, not precision. It may say things such as “detect suspicious activity,” “support enterprise customers,” or “give analysts useful investigations.” Those are meaningful product directions, but they are not buildable requirements yet.

A useful translation preserves the chain of reasoning:

Layer	Question answered	Example
Product objective	Why invest?	Reduce the time for SOC teams to identify suspicious sign-ins.
Stakeholder need	Who needs what outcome?	An analyst needs to investigate an alert with enough evidence to decide whether it is benign.
Functional requirement	What must the system do?	The system shall display an alert and its contributing sign-in events to an authorized analyst.
Acceptance evidence	How will we know it works?	An analyst in Tenant A can view Tenant A’s alert evidence but cannot retrieve Tenant B’s.
Design decision	How will we implement it?	Use PostgreSQL row-level security and an OpenID Connect gateway.

The first four layers belong in requirements work. The last is an architecture choice, which should remain separate until the problem is understood.

This distinction matters especially in senior design discussions. A phrase such as “build a Kafka pipeline” may disguise several unanswered questions:

• Which users need which data?
• What records count as valid?
• What must happen when data is late, malformed, or duplicated?
• Which tenant is allowed to access the result?
• Is the first release meant to detect, investigate, triage, or all three?

A requirement is not “technical” merely because it concerns a backend. It is functional when it specifies observable system behavior. For example, tenant-scoped authorization is a functional behavior even though its eventual implementation will involve security mechanisms.

User stories are useful intermediate tools, particularly when discussing workflow with product and design partners. But do not mistake the standard user-story sentence for a complete requirement. The sentence “As an analyst, I want to investigate suspicious activity” identifies a conversation. The functional requirements explain the system behavior necessary to make that outcome possible.

---

Separate facts, assumptions, constraints, and requirements

Before deriving requirements, read a brief twice.

On the first pass, identify the product objective, intended users, and claimed business value. On the second pass, annotate every statement as one of the following:

Category	Meaning	Example
Fact or stated need	Explicitly present in the brief	“Analysts must investigate suspicious sign-ins.”
Functional behavior	Something the system must do	“The system shall create an alert for a qualifying sign-in sequence.”
Quality attribute	How well the behavior must work	“Detection results must be available within five minutes.”
Constraint or dependency	Restricts the solution space	“Workforce users authenticate through the existing identity service.”
Assumption	Believed but not confirmed	“Customers can grant a read-only audit-log permission.”
Open question	Must be decided or researched	“What exact rule defines impossible travel?”
Out of scope	Explicitly deferred	“Historical backfill is not part of the pilot.”

The important discipline is this: do not silently convert an assumption into a requirement. If a brief says “detect impossible travel,” it does not necessarily mean that a reliable IP geolocation provider, a particular time threshold, or device fingerprinting has been agreed. Record the desired outcome as a requirement; record uncertain details as questions.

A brief is also not the sole source of requirements. Stakeholders often include more than the nominal buyer:

• SOC analysts need usable investigative outcomes.
• Tenant administrators need to configure and manage their organization’s connection.
• Security and compliance reviewers may need evidence of access control and accountability.
• Support and operations teams need a way to identify failed integrations.
• Approving authorities may impose regulatory, contractual, or internal-policy constraints.

The appropriate response to “we need feature X” is often: What decision or outcome does this enable? What happens if it is absent from the first release? The rationale reveals whether the request is truly essential, and it can expose an implementation proposal masquerading as a need.

---

A repeatable extraction method

A functional requirement should describe an externally meaningful system obligation in clear, platform-independent language. A practical structure is:

FR-ID — The system shall perform an action on an object or data when a stated trigger or condition applies, with the necessary business rule or outcome.

For example:

FR-05 — The system shall create an alert containing the contributing sign-in records when a tenant’s authentication events satisfy the approved impossible-travel rule.

This requirement identifies a trigger, behavior, result, and an intentionally named business rule. It does not decide whether the rule runs in a stream processor, a scheduled job, Rust, Python, SQL, or a vendor detection engine.

Use the following process.

1. State the product outcome in one sentence.
   If the sentence describes a technology rather than a user or business outcome, rewrite it.

2. Identify actors and external systems.
   Include human roles, tenant organizations, data sources, and systems that impose dependencies.

3. Write the user journey as a small number of activities.
   For a detection product, that may include connecting a source, receiving events, detecting behavior, investigating an alert, and recording a disposition.

4. Derive one behavior at a time.
   Each requirement should have a coherent trigger and outcome. Split “ingest, analyze, alert, and investigate” into separately discussable requirements.

5. Capture the source and rationale.
   A source can be a sentence in the brief, a stakeholder interview, a policy, or an explicitly recorded decision. Traceability is what lets you defend why an item is present.

6. Mark uncertainty explicitly.
   Use an assumption or open-question register instead of guessing. Requirements can be prioritized even while some details require discovery.

7. Add lightweight acceptance evidence for high-priority items.
   This is not a full test plan. It is a concrete example of successful behavior that exposes ambiguity early.

A few transformations show the difference:

Weak wording	Problem	Improved functional requirement
“Build an Entra connector.”	Names a solution-shaped task, not an outcome.	“The system shall allow a tenant administrator to authorize collection of audit events from the supported identity provider.”
“Support multi-tenancy.”	Too broad to test or prioritize.	“The system shall authorize each alert query and update against the requester’s tenant membership.”
“Make detection intelligent.”	Subjective and unspecified.	“The system shall create an alert when authentication events meet the approved impossible-travel rule.”
“Use Kafka for ingestion.”	Architecture choice, not a requirement.	Record it later as a decision if the workload and trade-offs justify it.

A useful test is the implementation-swap test: could the requirement remain true if you replaced the message broker, database, cloud provider, or programming language? If yes, it is more likely to be a requirement. If no, it may be a constraint or architecture decision.

---

Worked example: a behavioral detection pilot

Assume the product brief says:

“Build a multi-tenant pilot for SOC teams. By the end of the quarter, pilot customers should connect Microsoft Entra ID audit logs, identify suspicious sign-ins based on impossible travel, and investigate alerts. Tenant administrators set up data sources. Analysts see and close alerts. The pilot will serve ten enterprise tenants. Workforce users sign in through the existing corporate identity service. Event and alert data must not be visible across tenants.”

First, reduce the brief to a coherent product statement:

Pilot outcome: A SOC analyst can investigate and close a tenant-scoped impossible-travel alert derived from that tenant’s Microsoft Entra ID sign-in events.

That sentence exposes the minimum end-to-end journey. It also tells you what is not yet known. For instance, the brief does not define the impossible-travel rule, the audit-log delivery mechanism, retention duration, or what “close” means operationally.

Derived requirements

The following is a plausible first-pass requirements set. It is intentionally concise; detail is added where it makes behavior testable or resolves a meaningful ambiguity.

ID	Functional requirement	Priority	Rationale and source
FR-01	The system shall allow a tenant administrator to create and authorize a connection to the supported Microsoft Entra ID audit-event source.	Must	Without a tenant data source, the pilot cannot deliver detection.
FR-02	The system shall authenticate workforce users through the existing corporate identity service and associate each authenticated user with an authorized tenant.	Must	Stated dependency; tenant scope is required before users can use the product.
FR-03	The system shall receive audit events from a configured tenant connection, validate required event fields, and associate each accepted event with its tenant and source.	Must	Detection requires attributable, valid input data.
FR-04	The system shall create a normalized sign-in record from each accepted audit event containing the fields required by the approved detection rule.	Must	A stable record is needed for detection and later investigation.
FR-05	The system shall create an alert containing contributing sign-in records when a tenant’s events satisfy the approved impossible-travel rule.	Must	This is the core detection outcome named in the brief.
FR-06	The system shall present an authorized analyst with a list of that tenant’s alerts and the supporting records for a selected alert.	Must	Analysts must be able to investigate the detection result.
FR-07	The system shall allow an authorized analyst to close an alert and record its disposition.	Must	“Close alerts” is an explicit workflow outcome.
FR-08	The system shall indicate to a tenant administrator when a configured source has not delivered events for an agreed monitoring interval.	Should	Operationally useful for a pilot, but not explicitly required for the basic detection journey.
FR-09	The system shall support historical event import and replay for a tenant.	Not now	Valuable for later tuning and investigations, but not needed to prove the pilot’s core journey.

Notice that FR-03 and FR-04 could be split further if their validation and normalization rules become independently complex. At this stage, they are still coherent enough to discuss as one ingestion slice and one transformation slice.

Also notice the disciplined handling of “must not be visible across tenants.” It is not left as a vague security aspiration. FR-02 and FR-06 make tenant association and tenant-scoped authorization observable behaviors. The later security modules will deepen the threat model and authorization design; here, the key achievement is to make the required behavior visible and traceable.

Acceptance evidence for the core slice

For the highest-priority requirements, add examples that a developer, tester, product owner, and security reviewer can all inspect.

• FR-03: When a configured Tenant A source submits an event with required sign-in fields, the system accepts it and records Tenant A as its owner. When the event lacks a required identity or timestamp field, the system does not use it for detection and records the rejection reason.

• FR-05: When two accepted sign-in records for Tenant A satisfy the agreed impossible-travel rule, the system creates an alert linked to those records. Events from Tenant B cannot contribute to that alert.

• FR-06: An analyst authorized only for Tenant A can retrieve Tenant A’s alert and its evidence. The same request cannot retrieve a Tenant B alert, even if the identifier is known.

These examples do not prescribe a database schema or API shape. They do, however, provide enough behavioral precision to discover important design work later.

---

Prioritize by release value, not by component order

A backlog ordered as “database, API, connector, detector, UI” reflects implementation sequence. It does not tell stakeholders when a user can obtain value.

Instead, prioritize requirements around a complete but narrow user journey. A story map makes that visible.

For the detection pilot, the backbone activities could be:

Journey activity	Release-1 story slice	Deferred or lower-priority capability
Connect source	Administrator authorizes one supported Entra source	Multiple source types and advanced configuration
Access securely	Workforce user is authenticated and tenant-scoped	Fine-grained custom role administration
Receive events	Valid events are accepted and attributed to a tenant	Historical import and replay
Detect behavior	Impossible-travel rule creates evidence-backed alerts	Multiple detection models and configurable rule authoring
Investigate	Analyst views and closes tenant-scoped alerts	Collaborative cases, comments, and workflow automation
Operate the connection	Basic source-delivery visibility	Rich operational analytics and remediation guidance

The Story Map image makes the two dimensions explicit:

• Vertical order expresses priority within an activity. The top item is the earliest useful choice.
• Horizontal slices express a release boundary. A release should cross the journey rather than complete one technical component in isolation.

Use a simple priority vocabulary:

• Must: without it, the release cannot meet its stated objective, satisfy a binding obligation, or maintain an essential trust boundary.
• Should: strongly valuable, but the core journey still works without it for the target release.
• Could: beneficial if capacity permits.
• Not now: explicitly deferred, not silently forgotten.

Avoid calling every item “Must.” If all work is mandatory, priority has failed to communicate a release decision.

When deciding between two plausible requirements, use five questions:

1. Does this enable the stated user outcome in the target release?
2. Does its absence violate a contractual, security, regulatory, or trust obligation?
3. Is it a prerequisite for another user-visible capability?
4. Does it reduce a major uncertainty early, such as whether a customer can actually authorize the required data source?
5. Can it be deferred without making the released journey misleading or unsafe?

The final two questions are particularly important for cybersecurity products. A pilot that creates alerts but provides no tenant scoping would not be merely incomplete; it would undermine the product’s central trust claim.

---

The artifact you should leave with

For a brief at this stage, the output need not be a large formal SRS. A concise requirements brief is often stronger because it makes assumptions and release decisions visible.

A solid first-pass artifact contains:

1. Objective and success framing
   One or two sentences describing the intended user or business outcome.

2. Stakeholders, actors, and external dependencies
   Include approving or security-relevant stakeholders, not only end users.

3. Prioritized functional requirements
   Give each a stable ID, clear system behavior, priority, rationale, and source.

4. Acceptance evidence for the Must items
   Describe concrete successful and unsuccessful cases.

5. Assumptions, open questions, constraints, and out-of-scope items
   Keep uncertainty visible rather than burying it in vague wording.

Before accepting the artifact, run this short review:

• Every Must requirement traces to an objective, stakeholder need, constraint, or risk.
• Every requirement describes observable system behavior rather than a preferred implementation.
• The requirements collectively form a usable release slice, not a list of infrastructure milestones.
• Ambiguities are recorded as questions or assumptions.
• “Not now” items are explicit, so they cannot silently enter the release.

---

You have now established the first architecture input: a prioritized account of what the platform must do, why it matters, and what is deliberately deferred. The key habits are separating needs from solutions, preserving rationale and uncertainty, and prioritizing an end-to-end user outcome rather than technical layers.

Next, you will take the same kind of ambiguous product brief and extract measurable quality-attribute scenarios: the conditions under which the system must be secure, available, timely, and resilient—not merely functional.