My ISP decided to stop delivering services to me this weekend. I suppose they got tired of taking my money and would prefer to see how things would work out if I didn’t pay them any more. Anyway, I get itchy when I don’t write for a few days so I took my lunch hour to finish this draft…
When you are developing a product of any kind, you need to keep track of the requirements that dictate what goes in the product. Of course, some products have more requirements than others. But even simple products have a surprisingly long list of requirements. Consider beer, for example. We’ve been brewing beer for hundreds of years, right – can’t be that complicated! Unfortunately, not true. I’m no brewer, but just off the top of my head I figured that when developing a new brand a brewer must think about color, clarity, head, CO2 content, time to brew, complexity of the brewing process, cost, bitterness, hoppiness, special ingredients, and shelf life. A master brewer can certainly keep track of all those requirements in his or her head. But if your company brews 10 different types of beer, then it becomes more and more difficult to keep track of them all. Easy solution: Type up your requirements into a document – one document for each product. As your requirements change, you can issue updated documents to all stakeholders in the company.
If your business moves at a faster pace and the number of stakeholders is larger than you might find at a typical brewery, then occasional re-issues of hard-copy requirements documents will no longer suffice. Project contributors need to have up-to-date documents, and the documents will change often enough – early in the project, at least – that hard copies will not do. Clearly, the situation calls for a central database of requirements documents. This is not much harder than paper, really – that’s what word processors are for, and shared drives.
Unfortunately, even that isn’t good enough for an increasing number of companies. Some of my company’s customers have thousands of requirements in each product, and they sell thousands of different products. For companies like these, the overhead associated with keeping track of all those documents becomes prohibitively expensive. Word documents on shared drives will no longer do – you need a database.
Many of the requirements are identical from one product to the next. Sometimes they are identical because the product itself has a few variants that differ in minor ways such as how they are labelled, or what color the outer shell is, or the type of battery. If everything is in a database, then it seems straightforward to simply allocate each requirement to one or more products, and run a query each time you want to gather together the complete list of requirements for the product. So for example, you might have a requirement “REQ.902.J42: Uses no more than 10mW while in not in use” resulting from a regulatory requirement that is being considered in a number of jurisdictions in North America.This requirement is tagged with the name of each product that falls under the jurisdiction so that when you run the query “All requirements for product PRD.83.22a”, then you will find REQ.902.J42 in the list. This approach has a number of problems.
- Requirements change. If a requirement is initially allocated to a few products then it is changed in some way for one of those products, then you must create a new requirement for the exception, derived from the original. If the original requirement has been traced to test cases, design documents, and documentation artifacts, then you must also copy some or all of those traces, too.
- Requirements changes need to be tracked. If you drop a requirement from a project, it will no longer show up in the query results. If somebody asks the question “Which requirements changed in the past week?” you won’t have a record indicating that the requirement was dropped. You will be able to say which ones were changed, but dropping a requirement is a pretty significant event that I’m sure you’d like to keep track of.
- Usually you want to group together requirements that share common features without having to label the requirements. Even if you did go through the hassle of labelling the requirements, your grouping needs will almost certainly differ from somebody else’s grouping needs. For example, you may wish to group requirements in functional categories while somebody else may wish to group them according to the group that will be responsible for testing them.
- You want to grant certain people the authority to create or change requirements in a given project, but the permissions will change constantly, both globally and for certain subsets of the requirements, as the work progresses. The user interface and data model needs to manage such an approach are complex and challenging.
The alternative to the query-based approach is to collect requirements into documents. Or at least something that looks very much like a document even if its raw format is not Word or Excel. In a previous post I talked about a user interface that looks and acts like a file-based operating system even if it is not. This is a similar situation. A database can contain records that, when interpreted by a clever UI, looks and acts like a Word document that contains requirements. With a document interface you can build up functionality that addresses the problems listed above, and in a future post I will go into the details. One of the main advantages, however, is that you will begin to see that the kind of functionality you need to manage requirements is similar in many respects to what you need to manage software. The many years of experience we have with managing source code can be transferred to this domain. Another advantage is that the user has expectations about how he or she can interact with a document. This is useful because it reduces training. People understand copy and paste – go with it! Finally, the document paradigm can also be seen as an ownership hierarchy like folders in an operating system. This introduces other (semi-)physical gestures and paradigms that can be re-used with requirements documents. Once again, it takes only a minor push to get users to accept the new paradigm.
The alternative – reading requirements from a database – is less physical. It is more abstract, and therefore is a barrier to acceptance. The future of software is in making the abstract concrete. Why are first-person shooter games so popular? Because it’s almost like you are there. Why is data visualization a hot field these days? Because data needs to be made concrete before it can be used effectively by untrained users. When software is concrete, asking the question “where do you want to go with this?” does not seem odd. Concrete software paradigms open up new semantic avenues down which your users can drive. Straight-up database access is more about manipulating data than about engaging your users.