Working With Axel Van Lamsweerde's Goal-Oriented Approach
I spent about three years trying to get my team to adopt a goal-oriented requirements framework after a consultant pushed Axel Van Lamsweerde Software Requirements Engineering on us. It didn't go smoothly at first. The theory is solid, but the gap between the academic papers and actually using these techniques in a real project with stakeholders who just want their dashboard shipped by Friday is significant. The core idea behind Van Lamsweerde's work, particularly the KAOS methodology and the i* framework, is that requirements should be modeled as a hierarchy of goals rather than as a flat list of functional specifications. You decompose high-level softgoals into refineable hard goals, trace dependencies between actors, and identify conflicts before they become expensive rework. That's the promise. Here's how it actually plays out.
Axel Van Lamsweerde Software Requirements Engineering in Practice
The KAOS method rests on three operations: refinement, decomposition, and resolution. Refinement replaces a goal with a more specific sub-goal. Decomposition breaks a goal into a conjunction of sub-goals that must all be satisfied. Resolution deals with conflicts between competing goals by identifying which one takes priority or finding a third goal that satisfies both. In the i* framework, you model three types of elements: actors (who can be participants or resources), goals (what an actor wants to achieve), and dependencies (links between actors expressing trust or information flow). Softgoals are goals that can't be binary-true or binary-false, like "system usability" or "scalability." They get evaluated on a gradient instead. Here's a concrete scenario I worked through. We were building a clinical trial management system for a mid-sized pharmaceutical company. The stakeholder initially said they wanted "real-time patient data synchronization across all sites." That's a softgoal. When I tried to decompose it using KAOS, we hit a wall almost immediately because "real-time" meant different things to different people. The data engineers meant under 500 milliseconds latency. The site coordinators meant "I refresh the page and it updates." The compliance officer meant "every change is logged and auditable."
The workaround was to introduce a dependency diagram first, mapping every actor and what they actually needed from the system, before touching any goal decomposition. Once we had that, we could see the real constraint was auditability, not speed. The data engineers' latency requirement became a separate performance goal that could be optimized independently. This took about two weeks of workshop time instead of the three days we originally budgeted, but it prevented a conflict that would have surfaced during integration testing and cost us roughly six weeks of delays. That's the tradeoff you need to accept upfront.
Get the Full Details
Why People Get This Wrong
The biggest mistake I see is treating goal models as deliverables rather than as reasoning tools. People produce pretty dependency graphs and file them away. The actual value comes from arguing through the decompositions and watching the logical gaps appear on paper. If your stakeholders aren't actively challenging the goal hierarchy, you're not doing it right. Another common failure mode is over-refinement too early. There's a temptation to decompose every goal down to atomic, implementable units in the first pass. Don't. You'll spend hours modeling things that will change when you learn more about the domain. Van Lamsweerde's own papers emphasize progressive elaboration, but teams tend to rush past it because there's pressure to start coding. Leave the lower levels of the goal tree underspecified until the higher levels are stabilized. Softgoal satisfaction is where most implementations break down. Evaluating whether "maintainability" is satisfied "enough" sounds straightforward until you need to negotiate it against "performance." The i* framework gives you notation for this, but it doesn't give you a decision procedure. You end up making subjective calls and documenting them as best you can. There's no getting around that.
The Tooling Situation
There isn't a great open-source tool that fully supports the KAOS and i* modeling conventions out of the box. jUCMNav is probably the closest thing and it's still maintained, but it has a steep learning curve and the interface feels dated. For a small team just starting out, I'd recommend beginning with a whiteboard or a shared Miro board and mapping the actor-dependency-goal structure manually. The act of drawing it forces you to think through relationships that you'd otherwise gloss over. Once the models stabilize and you need versioning and traceability, then move to a dedicated tool. If you're looking for a practical starting point, the jUCMNav project is available through SourceForge. The academic literature is where you'll find the formal semantics. Van Lamsweerde's papers from the late 1990s and early 2000s, particularly the ones on KAOS and goal-oriented requirements specification, are still the primary references. They're dense but they're where the method comes from.
When This Approach Fails Completely
Goal-oriented requirements engineering doesn't scale well to large distributed systems with more than eight or ten independent stakeholder groups. I tried applying it to a platform project with contributors from five different organizations and the dependency graphs became unmaintainable within a month. The notation wasn't designed for that level of actor count. In those situations, a lighter-weight approach like-driven analysis with explicit priority voting from each organization's lead tends to work better. Not as rigorous, but it actually gets finished. It also struggles in agile environments where requirements change weekly. The whole point of maintaining a goal hierarchy is stability and traceability, which conflicts with a process that expects the requirement set to evolve rapidly. You can adapt it by keeping the goal model at a higher level of abstraction and updating it less frequently, but then you lose much of the detail that makes the method useful. It's a genuine tension. The method assumes your stakeholders can think abstractly about goals and tradeoffs. If you're working with business users who only think in terms of features and bugs, you'll spend most of your time translating between their language and the goal-modeling language. Some of that translation is productive. Some of it is just friction. Knowing which is which is something you figure out through experience, not from reading the papers.
