Creating a Requirements Matrix for Application Constraints

Hello, and welcome to the first module of this AWS DevOps course. This module starts where real company work usually starts: not with choosing AWS services, but with an incomplete business request that must become clear, testable engineering requirements.

A DevOps engineer is often handed statements such as “the application must be highly available,” “it should handle Black Friday traffic,” or “deployments must be safe.” Those are useful business intentions, but they are not yet buildable requirements. In this lesson, you will learn to turn such language into a requirements matrix that records availability, scalability, security, delivery, and cost constraints—along with the assumptions and unanswered questions that matter before architecture begins.

---

From a brief to constraints that can be built

A functional requirement describes what a system does: “customers can check an order status” or “staff can upload product data.”

A non-functional requirement describes the conditions under which it must do that work: how reliably, securely, quickly, economically, and changeably it operates. For AWS architecture and DevOps work, these conditions drive many of the consequential decisions: whether a workload needs redundancy, how it scales, which access controls are required, what a deployment pipeline must prove, and which costs the business accepts.

The key move is to replace adjectives with observable commitments.

Vague statement from a brief	Buildable requirement needs
“The system must be highly available.”	Which user journey? What percentage availability? Measured over what period? Are planned maintenance and third-party outages excluded?
“It must scale for Black Friday.”	Expected baseline and peak requests, concurrent users, growth horizon, response-time target, duration of the peak, and what happens beyond the expected peak.
“Keep customer data secure.”	Data classification, regulatory obligations, who may access it, authentication expectations, encryption requirements, audit evidence, and retention.
“We need fast releases.”	Deployment frequency, acceptable interruption, automated test gates, approval needs, rollback objective, and who owns releases.
“Keep AWS costs low.”	A monthly budget or unit-cost target, environment scope, forecasted demand, a definition of included costs, and cost-versus-resilience trade-offs.

“Highly available” does not automatically mean multi-Region. “Secure” does not automatically mean adding every AWS security service. “Low cost” does not mean selecting the cheapest option without considering outage risk and operator time. Each is a trade-off that the business must consciously make.

The AWS Well-Architected Framework is useful here because it prevents requirements gathering from becoming narrowly focused on features alone. It gives a structured set of lenses for reviewing a workload.

The diagram shows the five pillars emphasized in the provided AWS material. AWS’s current Well-Architected Framework also includes a Sustainability Pillar. For this course, we will focus first on the pillars that map directly to the application delivery and operations decisions you will make as a DevOps engineer.

For this lesson, map the company’s brief into five working categories:

1. Availability — how continuously important user journeys must work, and how failures are detected and handled.
2. Scalability — the workload volume and growth it must absorb without violating its performance commitments.
3. Security — data, identities, network exposure, audit, and compliance constraints.
4. Delivery — how safely and frequently teams must change infrastructure and application code.
5. Cost — the budget, cost drivers, usage assumptions, and trade-offs the organization accepts.

Operational excellence runs across all five. A requirement is only useful if someone can operate, observe, validate, and improve the system that satisfies it.

---

A requirements matrix is a decision record

A requirements matrix is a shared, versioned record—not merely a spreadsheet completed once at the start of a project. It connects the business owner, application team, security team, operations team, and cloud team around the same constraints.

A practical matrix should include these columns:

Column	Why it matters
ID	Lets the team refer to an exact requirement in tickets, designs, test plans, and change reviews.
Category	Availability, scalability, security, delivery, cost, or a cross-cutting category.
Requirement statement	States the required outcome in precise language.
Measure and acceptance evidence	Defines how the team will know the requirement is met: metric, test, configuration evidence, or audit artifact.
Priority	Makes trade-offs explicit. Use labels such as Must, Should, Could, and Won’t for this release, or your company’s equivalent.
Source and owner	Records who supplied the requirement and who can resolve ambiguity.
Assumptions, dependencies, and open questions	Stops guesses from silently becoming architecture decisions.

The statement should describe an outcome, boundary, and condition. For example:

During the seasonal sales event, the public order-status endpoint must sustain 3,000 requests per second for two hours while maintaining the agreed response-time objective.

This is better than “use autoscaling.” Autoscaling may become part of the solution, but it is not the requirement itself. Separating outcome from implementation makes it possible to compare AWS options later without losing sight of the business need.

A useful rule is:

• Requirement: what outcome is required and how it will be verified.
• Constraint: a non-negotiable limit on the solution, such as “must run in the EU” or “must use the company identity provider.”
• Design decision: the selected technical implementation, such as ECS on Fargate behind an Application Load Balancer.

Do not write a design decision in the requirements matrix unless it is genuinely imposed by the organization. For example, “the service must run on ECS” could be a valid platform constraint if a company’s approved container platform is ECS. Otherwise, it is a decision to be justified in a later architecture discussion.

---

How requirements are gathered in an AWS company environment

The application owner rarely has every answer. A product manager may know the seasonal demand forecast but not the database dependency. Security may know the data classification and retention rules. Operations may know incident history, change freezes, and on-call coverage. Finance or FinOps may own the budget. Requirements gathering is therefore a short series of focused conversations, backed by evidence.

AWS Prescriptive Guidance recommends identifying stakeholders, using existing documentation and programmatic data, and recording the fidelity of that information. This matters in practice: an undocumented claim that “we only get 100 requests per second” is a poor basis for an AWS capacity decision if CloudWatch, load balancer, or application telemetry tells a different story.

A repeatable intake method

When you receive a brief, work through the following sequence.

1. Extract the business outcome and critical user journeys.
   Identify what success means and who is affected. “Increase online conversion during a campaign” is a business outcome. “A customer can search, view stock, and submit an order” identifies user journeys whose availability and performance may matter differently.

2. Identify stakeholders and sources of evidence.
   Typical participants include a product owner, application lead, security/compliance representative, operations or support lead, finance or FinOps representative, and network/platform owner. Prefer evidence from monitoring, logs, prior incidents, contracts, and forecasts over memory alone.

3. Classify each statement.
   Mark whether it is a functional requirement, a non-functional requirement, a constraint, an assumption, a dependency, or an open question. This prevents an assumption from being treated as a fact.

4. Make each non-functional requirement measurable.
   Add scope, metric, time period, priority, and acceptance evidence. Ask: “Could a tester, operator, or auditor determine whether we met this?”

5. Record trade-offs and unresolved decisions.
   A multi-AZ design, frequent release target, strict recovery objective, and small budget may conflict. The matrix should reveal the conflict early and name the person who can prioritize it.

6. Validate the matrix with stakeholders.
   Read it back in business language: “If the order-status API is unavailable for 30 minutes during the campaign, is that acceptable?” Then document the answer, not your interpretation of a vague nod.

---

Worked example: turning a company brief into a matrix

Imagine this company-style request:

A retail company is launching a customer-facing order-status application before a seasonal sale in ten weeks. Customers in the EU must be able to view orders at all times. Typical traffic is 500 requests per second, with an expected peak of 3,000 requests per second for up to two hours during campaign announcements. The application stores customer names, email addresses, and order references; payment processing remains with an external PCI-compliant provider. The product team expects releases several times per week. Production spending should normally remain below 7,000 USD per month, with a separately approved peak-event allowance.

This brief is a useful start, but it does not yet say what “at all times,” “several times,” or “below 7,000 USD” operationally mean. A first-pass matrix could look like this:

ID	Category	Requirement statement	Measure and acceptance evidence	Priority	Open question / AWS implication
AV-01	Availability	The customer order-status journey must achieve 99.9 percent monthly availability, measured from successful HTTPS requests to the public endpoint.	Synthetic checks and endpoint success metrics; monthly availability report.	Must	Confirm exclusions for planned maintenance and external payment-provider failures. Design must avoid a single-AZ application dependency.
SC-01	Scalability	The endpoint must sustain 3,000 requests per second for two hours and maintain the agreed latency target during the campaign peak.	Pre-production load test using the expected request mix; production dashboards during the event.	Must	Obtain read/write mix, payload sizes, expected concurrent users, and a target latency. Scaling limits must be known and tested.
SE-01	Security	Customer personal data must be encrypted in transit and at rest. Production access must use individual identities, least-privilege permissions, and auditable actions.	Architecture review, encryption configuration evidence, IAM policy review, and audit-log retention evidence.	Must	Confirm data classification, retention period, identity provider, incident-reporting obligations, and whether any PCI scope reaches this workload.
DE-01	Delivery	Application and infrastructure changes must use version-controlled automated pipelines. A failed production release must be reversible to the prior approved immutable artifact within 15 minutes.	Pipeline run records, deployment test, and documented rollback exercise.	Must	Confirm required approval gates, change-freeze dates, acceptable deployment interruption, and on-call ownership.
CO-01	Cost	Normal production AWS cost must forecast at or below 7,000 USD per month; development and test costs must be reported separately. Costs above the agreed threshold require alerting and review.	Monthly forecast, cost allocation tags, budget alerts, and event-period cost review.	Must	Define included costs: data transfer, observability, backups, support, and shared-network charges. Confirm approved peak-event budget.

Notice several important qualities of this matrix.

First, the user journey is named. “The application” may contain an admin portal, asynchronous reports, email notifications, and a public API. They should not automatically receive identical availability targets. A ten-minute delay in a non-critical notification might be acceptable; an unavailable public checkout might not be.

Second, measurements have a scope. Availability measured at an Application Load Balancer, for example, means something different from availability measured by a browser-like synthetic journey that includes authentication and database access. The exact indicator and objective will be formalized in the next lesson; for now, the matrix captures the decision that must be made.

Third, the matrix exposes missing information rather than inventing it. We do not know the latency target. We do not know whether the peak consists mostly of reads, whether traffic is concentrated in one country, or whether the order system is an upstream dependency with its own limit. These become tracked questions with owners.

Finally, cost is a requirement, not a late-stage clean-up task. A workload cannot be evaluated honestly against a “7,000 USD per month” cap until the team knows whether that includes logging volume, data transfer, backups, non-production environments, support charges, and peak-event capacity. Cost must be compared with the cost of failure and the cost of operational effort, not treated as an isolated number.

---

Questions to ask under each category

The following prompts are useful in stakeholder meetings. They are designed to produce requirements, not to force an AWS service choice.

Availability

Ask which journeys must work, for whom, and during which periods.

• What is the business impact of 5 minutes, 30 minutes, or 4 hours of unavailability?
• Is the target continuous, or does it apply only to business hours or campaign periods?
• Are reads and writes equally critical?
• What failures are acceptable to degrade temporarily, and which are not?
• What is the current incident history and known single points of failure?
• What recovery expectations already exist in customer contracts or internal SLAs?

Capture recovery requirements as business statements at this stage. For example, “orders entered before a failure must not be lost” and “the service must be restored within two hours.” The next lessons will translate these into formal SLOs, RTOs, and RPOs.

Scalability

Scalability is not simply “automatic scaling.” It is the ability to handle a defined workload pattern within agreed service objectives.

Ask:

• What are current and expected requests per second, transactions per second, concurrent users, and data volumes?
• What are the baseline, expected peak, extreme peak, and duration of each?
• Is demand predictable, seasonal, or caused by unpredictable events?
• Which components are likely bottlenecks: database connections, third-party APIs, background processing, or network throughput?
• What behavior is acceptable when demand exceeds capacity: queue work, throttle some users, reject requests clearly, or degrade non-critical features?
• How far ahead must capacity be ready for an event?

A requirement such as “support 3,000 requests per second” is incomplete without the user journey, latency objective, duration, request mix, and overload behavior.

Security

Security requirements must describe data and access, not merely say “use IAM.”

Ask:

• What data is processed, where is it stored, and what is its classification?
• Which regulations, contracts, or internal policies apply?
• Which users, services, and teams need access? What access is prohibited?
• Does any component need public internet access, or can it remain private?
• How are users and workloads authenticated?
• What audit evidence, security logs, vulnerability findings, and retention periods are required?
• What is the incident-notification process and ownership?

For AWS, the matrix will later guide choices around IAM roles, network boundaries, encryption, Secrets Manager or Parameter Store, CloudTrail, AWS Config, and logging. Do not add those services just because they are available; add them because the workload has a recorded security or operational need.

Delivery

Delivery requirements protect the business from unsafe changes. They should include both speed and control.

Ask:

• How often does the business need releases?
• Are there campaign windows, accounting periods, or change freezes?
• What tests must pass before production?
• Who approves production changes, and when is automated approval appropriate?
• Is a short interruption acceptable? If not, what counts as a customer-visible interruption?
• How quickly must rollback complete, and has it been tested?
• Who monitors the release and owns the first response if it fails?

AWS operational excellence emphasizes safe automation, small reversible changes, observability, and learning from operational events. A mature requirement might require infrastructure as code, traceable pipeline runs, test evidence, deployment health checks, and a tested rollback procedure—not just “CI/CD.”

Cost

A cost requirement needs a budget, a scope, and an owner. “Optimize cost” by itself cannot be verified.

Ask:

• What is the monthly budget for each environment?
• Which costs are included or excluded?
• What demand forecast and growth assumption support the estimate?
• Is extra spending approved for a known seasonal event?
• Is availability more valuable than the savings from reducing redundancy?
• Which cost allocation tags are required for team, product, environment, and cost center?
• Who receives budget and forecast alerts, and what action should they take?

---

Handling conflict, uncertainty, and changing requirements

Real requirements often conflict. Consider these combinations:

• Near-zero downtime, multi-AZ resilience, very aggressive recovery objectives, and a minimal budget.
• Frequent releases but a long manual approval process.
• Strong network isolation but a dependency on a public third-party service.
• Rapid growth targets but no evidence about expected traffic.

Your responsibility is not to silently choose one side. Make the conflict visible, quantify it where possible, and identify the decision-maker. A good matrix entry might say:

Decision required: The desired 99.99 percent availability target may require substantially more redundancy and operational investment than the approved monthly budget supports. Product owner and finance owner to select the target before detailed design.

Also record confidence in important inputs:

• High confidence: recent CloudWatch metrics, contracts, tested recovery records, or system-generated inventory.
• Medium confidence: a current architecture diagram or a statement confirmed by multiple owners.
• Low confidence: an old spreadsheet, undocumented institutional knowledge, or a forecast without evidence.

Low-confidence information is not useless. It simply needs a validation task before it becomes a binding design assumption. For example, if an application owner estimates the peak at 3,000 requests per second, validate that estimate through historic access logs, business campaign forecasts, or a load test before committing production capacity.

Treat the matrix as a living artifact. Update it when a business forecast changes, a security classification is clarified, a dependency is discovered, or a production incident reveals that an assumption was wrong. Version it with the architecture and delivery documentation so the team can explain why a design exists—not merely describe what was deployed.

---

A company brief becomes useful to an AWS DevOps engineer when it is converted from broad intent into measurable, owned, and testable constraints. The requirements matrix should distinguish outcomes from AWS implementation choices; include availability, scalability, security, delivery, and cost; record sources and confidence; and surface conflicts before they become production incidents.

The Well-Architected Framework provides the review lenses, while a disciplined matrix provides the day-to-day decision record. In the next lesson, you will take the availability and performance statements from this matrix and define precise service-level indicators and service-level objectives for an AWS-hosted application.