One of the ten big rules of writing a good MRD is writing attainable, or realistic requirements. These are requirements that can be practically implemented, by our team, according to our schedule. Practicality is a function of the skills of our team members, the costs that we face to implement a particular requirement, and the circumstances in which we are developing. Agile proponents use the phrases ‘people trump process’ and ‘politics trumps people.’
To write attainable requirements, we have to think about our people and our political situation.
The Big Rule of Writing Attainable Requirements
From our previous article, Writing Good Requirements – Big Ten Rules:
The requirement must be realistically achievable. Barbara and Steve make great points about understanding the cost of implementing something as expressed in the requirements. As we pointed out in our thoughts about good requirements management, there is an optimal tradeoff between costs and benefits for any given company or project. We can formally approach this using the techniques identified for more is better requirements using a Kano framework. In short, the investment must have an ROI that exceeds the opportunity costs by the hurdle rate.
Looking at cost-benefit tradeoffs also supports the argument that valuable should replace necessary.
Politics
What is the political climate in our organization? Are we trying to reduce costs for existing products and processes? Are our executives willing to invest in top-line growth through innovation?
Jeffrey Phillips writes on the results of an IBM Global Services Survey, following up on an analysis by Brian Edwards. Jeffrey points out that most of the CEOs think about innovation in terms of cost reductions, not top-line growth or disruptive change:
However, almost uniformly the CEOs indicated that cost reduction was the number one benefit they expected to receive from innovation.
Top line growth was third or lower on CEO lists.
In this type of environment, requirements that represent disruptive change can be impractical. We have to be able to sell the idea, and get at least VP or C-level sponsorship for an idea that contrasts with the beliefs of the head honcho.
People
Who are the developers on our team? Are they free electrons? Rands provides this definition:
The Free Electron is the single most productive engineer that you’re ever going to meet. I have not even provided a definition and I’m guessing a person has already popped into your mind that fits the bill.
A Free Electron can do anything when it comes to code. They can write a complete application from scratch, learn a language in a weekend, and, most importantly, they can dive into a tremendous pile of spaghetti code, make sense of it, and actually getting it working. You can build an entire businesses around a Free Electron. They’re that good.
Usually, we work with mortal humans (or at least homo-logicus, as Alan Cooper would call say). We have to explore the cost side of any requirement with our development team. They provide the feedback that allows us to understand what we can do for little, some, and a lot of money/time/effort. We have to balance that input with the benefit side of the equation. It isn’t enough for the requirement to be valuable, it also has to be cost effective.
Practical
Practicality is just a general way of thinking about attainability. Can 50,000 concurrent users access a website with subsecond response time? Sure. That’s a practical requirement, generally speaking. But is it practical for our team? Do we have the expertise, or the available funds and executive sponsorship to go get the expertise we need?
Conclusion
Determining if a requirement can be realistically achieved isn’t that hard. What we have to keep in mind is if we can realistically achieve it with our current team.
Even when the requirement is technically attainable, it may still be politically impractical.
