The Analysis Business

We left off last time with the idea that although software projects can go wrong for lots of reasons that tech folks can’t control, there are some ideals we can (and should) strive for in the areas we can control. We don’t control market forces, competitors, or business needs, and we rarely control dates or budgets (we may be tasked with spending what budget there is wisely, but corporate economics are certainly beyond our purview).

We do control the way we build software and the way we operate it to deliver against business service expectations. My contention is that because we capture and feed requirements into the build process, we also control what is built. Or rather we have a duty not to treat this dividing line between business and IT as a dividing line at all. The primary reason for this is that if the wrong things go in, then the wrong things come out. And this is both common, and bad, for all sorts of reasons:

• Business plans are often reactive and at the mercy of the market, leading to whole sets of requirements that are plainly inappropriate

• Human nature and corporate fiefdoms tend to politicise requirements, pushing unnecessary or poor requirements through against the needs of the greater good

• Many requirements are simply irrelevant. I can’t remember how many times I’ve seen a lovely new project concept shaped, polished, sold to the executive board, given life in the form of a budget, only for it to be used as a dumping ground for all the dirty laundry and lost opportunities of every middle manager that can grab the BA long enough to bark out their demands and claim the diplomatic immunity of “stakeholder”. The requirements then outstrip the budget, time passes, requirements get cut (not always the irrelevant ones, it depends who shouts loudest) and placed in the cupboard ready for the next passing budget bucket.

• The Right Thing (what will best help the business achieve it goals) may not exist in any of the requirements

• IT always carries the can for failure and this can create a pernicious cycle that eats away at morale and pride, making future success less likely

All sounds very depressing doesn’t it? But it doesn’t have to be. As I also pointed out at the end of the last article, even quite large groups of people do tend to make good collective decisions eventually. What people are generally pretty poor at is cooperation at work - forward motion tends to rely on a few lively individuals who do all the running around and connecting of activities. But if there’s a good benchmark to measure the question and answer against, then things are very much more positive.

The theoretical biologist Norman Johnson performed an experiment whereby he gave people a traditional maze to solve (the objective being to find the way out). As you’d expect, they initially wandered around, seemingly randomly, until they discovered the exit. Those allowed to try again were naturally just a bit better at getting out in fewer steps. What was rather extraordinary was that if you took the majority decision of left or right at each step, the collective wisdom found the way out in the fewest steps along the optimal path, every time.

So the good news is we know it’s possible, the trick is applying the right leadership to make the goal objectively clear (i.e. the right thing discussed last time). The goal “escape from the maze” is pretty clear, as is “launch” when you are working in a start up, or “release product X”, but while objectives such as “support a new pricing structure”, “implement a new billing system”, “restructure the ERP application” may have a similar impact on the bottom line, they clearly don’t have the same visceral impact.

To make projects that may not initially appeal to our survival imperative successful, we need to make our requirements and our mission gel into a clear objective, or else risk some of the woes I listed earlier. We can define the mission by painting the picture of what success look like and we can structure our requirements so that they only point that way. Requirements that don’t sit on this roadmap are less likely to be raised, and will stick out like a sore thumb if they do.

So let’s look at what requirements actually are.

Karl E. Wiegers wrote an article in Dr Dobbs Journal last year asking exactly this question. His supporting paper Ten Requirements Traps to Avoid also makes good reading. He breaks down requirements into three levels:

• Business Objectives: what the business needs to achieve

• User Requirements: what the operators need to have to achieve the business object

• Functional Requirements: what the designers and builders must make to deliver the above

He also defines quality attributes and non-functional requirements as key contributors to the SRS, or Software Requirement Specification.

Not a bad start, but I have two concerns with this kind of approach.

The first is that the notion of a definitive SRS is an illusion. The famous Chaos Report, generated by the Standish Group, suggests that 45% of delivered requirements are in fact never used. This doesn’t just represent wasted effort, it’s a significant factor in increasing code complexity and maintenance overhead that will make the 55% of future project requirements that will be used very much harder to deliver.

You could say that the 45% is due to bad judgement by business owners, and an inability on the part of some to weed out wish-list fantasies, but in my experience that 45% figure actually starts out as something closer to 90%, which is then watered down by new requirements added later, as the business firms up its ideas about what is wanted. The 45% is the fossilised dinosaur bone in the code, that gave way to the 55% of evolved super-species able to survive market forces.

The second is that partitioning requirements likes this creates a hierarchy that can reinforce organisational silos, rather than blur them. If the business objectives aren’t very clear, there’s lots scope for users to map any old favourite requirement to them. Functional requirements become subservient to user requirements, and non-functionals subservient to both. Additionally, there may well be many functional requirements, that also map to the business objectives, but that are much more elegant and easy to deliver than the ones that would be derived by the user requirements.

Thanks to an email from Keith Bines at Oracle, I’m also now of the opinion that there’s something insidiously divisive about these categorisations, and it’s this:

User requirements will tend to be seen as the preserve of business end-users, functional requirements of developers and non-functional requirements of architects. Three groups that, shall we say, do not have a great history of rapturous cooperation in the corporate enterprise.

The word “non-functional” itself isn’t exactly helpful. As Joe Schultz in his article “How Fast is Fast? Using Non-functional Requirements to Test Software Quality” notes:

Unfortunately, the name non-functional requirements is somewhat misleading. From the name alone, it sounds like non-functional requirements are requirements that don’t function (i.e., things that don’t work). Obviously, this is just the opposite.

I’m not disagreeing with Karl Wiegers particularly, his dissection of requirements and what can go wrong with them is as clear a one as you’ll find, I’m just saying that the structure and naming conventions can be dangerous when applied in a world where there are lots of subtly competing views, politics and ambiguity.

Joe Schultz goes on to talk about having Security Requirements, Topographical Requirements, Timing Requirements, Frequency Requirements, Performance Requirements, Scalability Requirements, Usability Requirements as mapped to why, where, what etc. These aren’t contradictory, in my view, to Wiegers’ breakdown, but clearly these categories make more difficult targets for any would-be usurpers, belonging (as they should) to all parties.

A good requirement will, in any case, always combine relevant categories into one clear sentence, with subject/predicate or noun/verb constructions indicating functional aspects, and adverbs or modifying clauses indicating qualities or constraints.

The requirement:

The web system will collect completed orders periodically and quickly despatch them to the fulfilment system

contains some of these features, although note that it’s not a ‘good’ requirement yet, as issues like periodically and quickly need clarification.

During some background reading I did over the holidays I came across some papers on something called the “i* framework” by Eric Yu and John Mylopoulos, the intro to which can be found here. They develop the idea of soft goals (goals which bend to differing circumstances) and strategic dependencies (use case actors that rely on each other to meet their goals), their walk through the ‘non-functional’ aspects of this model is enlightening (if a little heavy-going), but I did pick out this nice quote:

Most conventional approaches to system design are driven by functional requirements. Developers focus their efforts primarily on achieving the desired functionality of the system. Although decisions about how to achieve functionality are made along the way, usually with non-functional requirements in mind, these considerations may not be systematic, and may often not be documented. Furthermore, these software quality attributes may often be viewed as consequences of the decisions, but not something that the developer can strive for in a coherent, well thought-out way.

Johanna Rothman in a great blog article from 2003 picked up on a key theme in a Joel Spolsky post about moving into his new office - that he did not separate functional and non-functional requirements but instead looked for something that represented both. She was teaching architects how to consult with customers better that week (say no more) and concluded:

The lesson I’m taking away this week is that if you want a coherent architecture, it’s more important to discover the primary system attributes rather than all the functional requirements. No matter how you approach requirements, make sure you take a holistic approach. Don’t use techniques that separate functional and non-functional requirements. If you do, you won’t see the architecture emerge.

Exactly. And because you want success next time, and the time after that, and you want projects to get easier and not harder, and you want good separation, and loose coupling, and process alignment and all that other stuff, you have to forget all this nonsense about non-functional requirements being distinct, and on the edge. Having the right architecture is fundamental to delivering the right thing.

Those architects may have personality issues and poor dress sense, but you should never manage requirements in such a way as to marginalise what they do. One final quote from Steven Lott, an interesting chap who often posts provocative thoughts on the topic of architecture, who had this to say on requirement confusion:

The core issue is that everyone wants to design the solution. The more people you interview, the more you discover that everyone is an architect, and everyone has very strong opinions on precisely how to build the software solution.

His amusing post “Use Cases, Why Cases and The Bentley Test” takes us full circle to Weigers’ article in Dr Dobbs. Lott sees Weigers structuring as inadequate because users sneak all kinds of unrealistic demands into ‘functional’ requirements, or demand ‘non-functional’ requirements that are nonsensical (to which he adds, then he’ll have a Bentley as part of the requirements as this is equally ludicrous).

So let’s summarise:

• Requirements are the lifeblood of any project, and the effect of bad ones feeding into the build process can have extremely serious consequences beyond the day of deployment

• Dissecting requirements to make sure all angles are covered is a reasonable pursuit, but this should be for coverage purposes only, never as a vehicle for management once they are captured

• Never make a public distinction between functional and non-functional requirements because it drives a wedge between architecture and development, risking both marginalisation of system qualities, whilst opening up the door for them to be ‘designed’ by those not qualified (or accountable) for the job

• Instead focus on agreeing the primary system attributes that directly support the business objective because this is your goal, not the requirements, they merely substantiate it

• When you have your attributes, hang fully formed requirements off them, if you can’t find a hook ask whether the requirement really belongs

• Beware the wish-maker in stakeholders clothing, if their requirements don’t fit but are otherwise good, then they should create a project vehicle of their own to realise them

• Model, simulate, walk around and through everything that you have to make sure all aspects are covered. This is where categorisation is useful because it helps ask questions about security, timing, scalability, and so on that may not naturally come through in the analysis

• And, wherever you can, do all this iteratively and not up front. Beware of the fact that 90% of what you start with in traditional approaches has the potential to be a requirement that is never used. If you get the primary system attributes right and they map to the business goal, then major change should only come from a change to the goal itself (i.e. demanded by the business) which is beyond your control anyway