Goal-Oriented Requirements Engineering: Starting from your Product Goal

In many project environments, teams often begin with a clear picture of the end goal or desired product outcome. This approach demands a reverse-engineered method for defining requirements, one that aligns deliverables and technical details with strategic objectives.

Known as goal-driven requirements engineering, this process ensures that every specification is rooted in tangible business or user value.

This article outlines the structured process for translating product goals into requirements, explains what product goals are, and details the steps to craft actionable, traceable requirements from them.

A top down approach to Requirements Setting

When starting from product goals, the requirements-setting process involves several deliberate stages. The following is a typical process you can follow:

1. Clarify the end goal: The process begins with articulating the final outcome, often described in terms of performance, user impact, or business value.
2. Break down the goal: The product goal should be broken down into sub-goals, each addressing a component, system, or function.
3. Identify stakeholders challenges: Each goal may have different stakeholders whose needs and constraints shape the nature of the requirements. Users, customers, regulators and engineers all have different challenges.
4. Formulate requirements: This step involves translating goals into specific, testable, and traceable requirements categorized as functional and non-functional.
5. Review, validate, and iterate: Stakeholders must review and validate the requirements to ensure they remain aligned with the original goal.
6. Trace and manage: Throughout the lifecycle, requirements are tracked and modified as needed, maintaining linkage to the product goals they serve.

This top-down process ensures that each requirement has a rationale and contributes to the larger vision.

What are Product Goals?

Product goals are strategic targets that define what the product should achieve from a business, user, or operational standpoint. They are often qualitative and forward-looking, but can be made measurable through key performance indicators (KPIs).

Types of Product Goals:

• User-centric: Enhance user satisfaction or engagement (e.g., “Reduce user onboarding time by 50%.”)
• Business-oriented: Increase revenue, market share, or compliance (e.g., “Achieve GDPR compliance for EU markets.”)
• Technical performance: Improve system scalability or efficiency (e.g., “Support 100,000 concurrent users with ≤ 200ms latency.”)

Product goals serve as the north star for the development process, influencing decisions across design, implementation, and quality assurance.

Setting Requirements Based on Product Goals

Once product goals are well-defined, the task shifts to transforming these high-level intents into implementable requirements. Here’s how this transformation occurs:

1. Goal decomposition

Break the product goal into smaller, manageable sub-goals. For example, a goal to “improve application speed by 40%” may decompose into:

• Optimizing database queries
• Reducing front-end load times
• Implementing caching mechanisms

2. Define functional requirements

These describe what the system should do in response to inputs or in interaction with users. For instance:

“The system shall cache API responses for 15 minutes to reduce response times.”

3. Define non-functional requirements

These refer to performance, reliability, usability, or security. For the above goal:

“The average page load time shall not exceed 1.5 seconds under a load of 500 users.”

4. Use SMART criteria

Requirements should be:

• Specific
• Measurable
• Achievable
• Relevant
• Time-bound

This ensures they are not only understandable but also verifiable and actionable.

5. Maintain traceability

Every requirement should be traceable back to a product goal. Tools like traceability matrices or requirements management software (e.g., ECLIPSE, Jira, DOORS) are essential for linking each requirement to its purpose.

6. Prioritize based on impact

Not all requirements have equal weight. Use MoSCoW (Must, Should, Could, Won’t) or Value vs. Effort matrices to focus development on requirements that drive the most value toward the goal.

Conclusion

Starting with a product goal offers an advantage; it anchors development in outcomes that matter. However, success depends on translating those goals into well-defined, testable requirements that guide the team through the design, development, and validation process.

A structured process that includes goal decomposition, stakeholder alignment, and traceability ensures the project stays aligned with its strategic objectives. In doing so, teams not only meet technical deliverables but also deliver products that fulfill their intended purpose with precision and clarity.

Explore our Requirements Management Solution to streamline your process, ensure traceability, and meet compliance standards with ease.