This thread is going to be about Goal Oriented techniques. There’s been some good academic work in this area — you could look up Goal-Oriented Requirements Engineering (GORE) — and some successes in practice. I’ve been following this area for about 10 years, and have used it for a few engagements.

I think the concepts are really interesting, and that it could be a useful addition to our modeling toolbox. But it’s not a panacea at all — it can become top-heavy if you document everything, and there are some other issues that arise in practical use. For one thing, there aren’t many software packages that support this methodology (although there is a new entrant that’s pretty good.) For another, multiple syntaxes for expressing goals and their relationships have been developed by academics, and a winner hasn’t yet emerged. So in addition to looking at the strengths and benefits of goal orientation, I’d like to examine when it’s appropriate to use, and how to best avoid or handle its limitations.

I’m going to start by commenting on a blog post I read this morning.It was from an agile software practitioner who had been to our seminar in February to the IEEE: “Getting beyond ‘The System shall…..’ .” (His blog is called A Random Blog, and can be found here –> https://speakercity.blogspot.com/2006…sentation.html.)

He disagreed with just about everything we said in the seminar — but at least he was listening! 😉 Someday (in the far distant future when I have the time,) I’d like to answer each of his points, because he got me all riled up. But for now I’ll just speak to a couple of things he said:

“As ArgonDigital states they are in the business of ‘creating requirements documents.’ I think this whole mission is just missing the bigger picture. No one cares about better requirements documents, people want better software products….. the requirements document is not an end goal.”

Well, sure. But you could also say that about languages, and compilers, and test plans, and development methodologies, and all the other tools and techniques we use to tame the wild beasts of software. I suppose he said it because agile folks like to dive right in. And that can be a lot of fun out of the box, and it’s great when it works. (Not so great when it doesn’t, but that’s not on topic.) Anyway, we think that specializing in this specific part of the development cycle is important, because there’s a lot more to getting to the right requirements than at first it might appear — and our clients agree, or else they wouldn’t use us!

Another issue he raised was the use of models, which he thinks inappropriately stray into the realm of design. As we know there is an intimate relationship between requirements and design that increases as constraints on the solution are identified. As a simplified example, let’s say the requirement is to get people from New York to Washington, D.C. faster. We could build a superhighway or we could build a high-speed train track. If the decision is for high-speed trains, then do we build a super-flat and strong base for the rails, so that the train won’t bump and sway (or derail) when it hits speeds of 150+ mph? Or do we build a mag-lev system? The requirements for each would vary greatly, and as the funding authority made decisions on exact technologies, the requirements would become more and more detailed, until finally we come to “a laser calibration system for measuring the variation of rail placement from specs, with an automated system for generating work orders.” And then we plunge further into that.

At each level a requirement can be seen either as a constraint on possible design solutions, or in itself as an element of a design solution to a requirement from the “next higher” conceptual level. In this sense a requirement has a dual nature. As an element of a design solution to a higher-level requirement, a requirement is a “satisfier” of a goal implicit (or expressed) in the higher level. And in turn it implicitly or explicitly expresses a sub-goal for the next lower level to hopefully satisfy.

So from this perspective any requirement has two components that are both needed, although one or the other might be implicit — a goal component and a constraint component. So a requirement has a dual nature twice! (Anyway, that’s my proposition for you to consider.)

(BTW, there is a big area of research in the AI field where truth is defined through “constraint propagation.” It’s used for visual scene recognition, scheduling, and a lot of other things. Google it if you’re interested in that area. (Maybe someday we could steal some of those algorithms and apply them to requirements? I have no idea if that would work or not.))

Because of the goal/sub-goal relationships, most of the methodologies tend to show examples of hierarchical structures. But the real world is more complex than that – often goal trees are not enough, and inter-connected goal webs have more fidelity.

That’s all for now. Let me know if you want to hear any more on this subject, OK?