Goals Oriented Requirements To Build the Right Software

Collaborating on deriving scope from goals is undoubtedly the most controversial topic in this book. In the last five years, the surge in popularity of value chains in software development has increased awareness of the idea of collaborating on scope and deriving it from business goals.

On the other hand, most teams I work with still think that project scope isn’t under their control and expect customers or business users to fully define it. In the course of my research for this book, I found a pattern of teams deriving their project scope from goals collaboratively – but this practice is much less common than other key patterns.

I originally thought about leaving this chapter out. I decided to include it for three reasons:

• Defining scope plays an important role in the process of building the right software. If you get the scope wrong, the rest is just painting the corpse.
• In the future, this will be one of most important software development topics, and I want to raise awareness about it.
• Defining scope fits nicely into designing processes from value chains, which are becoming increasingly popular because of lean software development.

Source: “Specification by Example – How successful teams deliver the right software”, Gojko Adzic, Manning,

Customers and end-users often see software requirements gathering as an activity where they are going to list the desired features of the new software application. In this quote, Gojko Adzic remind us it is more important to know where we are going before discussing what to do.

The scope of a project should be defined according to the business goals of the organization. This emphasis on defining goals before features is also the focus of his other book *Impact Mapping: Making a big impact with software products and projects“.

Why Should You Adopt a Goal-Oriented Approach to Requirements?

• Aligns software functionality with business and user objectives, improving stakeholder satisfaction and adoption rates
• Enhances clarity by framing requirements in terms of “what” the system should achieve rather than “how” to build it
• Facilitates change management through goal refinement when requirements evolve
• Supports conflict resolution by exposing and negotiating competing stakeholder goals

Key Activities in Goal-Oriented Requirements Gathering

Goal-oriented requirements gathering is concerned with using goals for many aspects. It will help to elicit, model, structure, refine, analyze, negotiate, validate, document, and modify requirements.

1. Goal Elicitation: Engage stakeholders to identify high-level goals that reflect needs, constraints, and success criteria.
2. Goal Modeling: Represent goals hierarchically or graphically (e.g., KAOS, i*) to show relationships such as refinement, contribution, or conflict.
3. Goal Decomposition: Break down high-level goals into finer sub-goals, making them easier to assign and verify.
4. Goal Refinement: Iterate on initial goals based on feedback and changing conditions, ensuring continued alignment with business objectives.
5. Operationalization: Translate refined goals into concrete functional requirements and acceptance criteria.
6. Conflict Analysis and Negotiation: Identify goals that conflict and negotiate trade-offs among stakeholders to reach a consensus.
7. Traceability and Validation: Maintain links from goals to requirements, design artifacts, and test cases to ensure each goal is fulfilled in the final product.