If you noodle around the Internet you can find some very gloomy reports showing the number of software projects that fail to meet users expectations. Whilst many of the reports are paid for by vendors of Requirement Management software, they are still pretty depressing. Why are we so bad at delivering software to our customers? There are many reasons and volumes have been written about it, however I think we can distil it down to three main issues:
  • Lack of Domain knowledge. We don't understand the language and needs of the user because we do not speak the same language. This can be a hard problem to spot because we are apparently speaking the same language e.g. Spanish. However human communication is overlaid with myriad assumptions and unspoken meanings. In a complex business environment then these assumptions often become invisible and hidden meanings become more and more significant. So our customers make assumptions about our understanding and we make assumptions about their meaning and intent.
  • Poor documentation. We write the customers requirements in such a dense manner (and even the humble use case is pretty dense to most business users) that our users cannot continue the requirements conversation in any meaningful way. It's hard to see the omissions, assumptions and dependencies in our documents -- a seven page use case is not something to be proud of!
  • Poor Requirements Lifecycle. Properly managed requirements can be used throughout the product lifecycle to answer two keys questions
    • Are we creating value for the customer in what we are doing today?
    • Have we created something that is correct and useful?
    Unfortunately, after they are written, requirements are often tucked away in a word processed document and forgotten until the law suites start. They are hard to use and cannot be exploited by the design or test team to provide relevant designs or tests. With appropriate document formats and linking of information then the information can and must be be used throughout the development process
How can we address these issues?
  1. Keep it simple. Use simple language to describe requirements that can use understood by customers and developers. Using Casual Use Cases or XP style User Stories. Creating these types of documents involves you in having conversations and making agreements with your customers -- make sure that everyone understands these agreements and the assumptions they are based on. Make of note of these assumptions and decisions.
  2. Place the information in an accessible place. E.g. Pinned to the wall, located in a WiKi (my personal favourite)
  3. If you really need a "proper" requirements document you can consolidate and reformat your simple document into something that can be signed off.
  4. Only have one single definitive set of requirements. Don't keep the same information in two different places
  5. Show how the information flows and links in the Requirements and Development process e.g.
    1. Vision lead to
    2. Objectives lead to
    3. Business requirements break down into
    4. User Stories lead to
    5. Acceptance tests
    (These are only examples -- you will need to agree a document hierarchy with your team and stakeholders. It will depend on your culture and process)
  6. Constantly check back to the requirements and accommodate changes to them (big of a big one slipped in there!). Keep having those important conversations and talking about assumptions and hidden meanings.
So what is the requirements 'Elevator Pitch'?
Requirements drive everything we do so make them useful and easy to use!!