We build systems to meet the requirements of our users. As we build systems, we take our user's requirements and derive more requirements from them. Derived requirements are lesser than user requirements. It is easy, however, to forget this relationship, and this can cause many problems for our projects.
A derived requirement is something that we infer or derive from a user requirement. (For this article, let's use the term user for the customer, user, and client. Let's also use the term "user requirement" for something that the user wants.) For example, suppose a user requirement is "the system must work outdoors, 12 months a year in Minnesota." Several derived requirements are (1) the system must work in temperatures below 10 degrees F and (2) the system must work in the snow. We derive these requirements by delving into the details of the user requirement.
Derived requirements do not come straight from the user, so they are not as important as user requirements. We forget this sometimes to our dismay. As an example, I came into a four-year, $30M project in 1999. We built an embedded system that had a laptop computer as a controller. Everyone was using Windows operating systems by then, but we were still using MS-DOS for the controller. The programmers had to use tricky and expensive programming to create graphics and fit the software into a limited memory space.
MS-DOS was a requirement. Several years earlier, the users wanted to use a palm-held PC as a controller. That little PC only ran MS-DOS; it couldn't support Windows. Hence, MS-DOS became a derived requirement. The palm-held computer went away (the manufacturer dropped it), but we stayed with MS-DOS on the laptop computers.
In the year 2002, we were still using MS-DOS. We could no longer afford to maintain the controller software. We had to do something, but MS-DOS was a requirement - or was it? It was difficult to uncover the history, but we finally learned that MS-DOS was a derived not a user requirement.
Requirements drive projects. That is okay because we conduct a project to deliver a system that meets the user's needs. Meeting requirements is often difficult and expensive work that wears out project managers like me. I have enough work to do to meet the user requirements. I don't need to kill myself and my team to meet non-essential requirements. Especially those that I derive or create myself.
I have learned several techniques that help prevent derived requirements from becoming more important than user requirements. I group these techniques into (1) identifying, (2) tracing, and (3) change management.
My projects go smoother when I uniquely identify each requirement (e.g. give each requirement a unique number). Ensure that you can easily differentiate a derived requirement from a user requirement. Give the two types of requirements different types names (e.g. UR001 vs. DR 001) and put them in different places.
Requirements should trace from their origin to their implementation and test. Each requirement points to a design element; each design element points to an implementation, and each implementation has a (set of) test(s). It helps when each user requirement has a user's name as its parent, and each derived requirement has a user requirement as its parent.
Changing a requirement once the project is in progress is a significant effort with many ramifications. Derived requirements should be easier to change than user requirements. You should neither do as much paperwork nor hold as many meetings to change a derived requirement as to change a user requirement.
Derived requirements are not the same as user requirements. We derive them and we can delete them. I have forgotten this and seen other people forget it as well with bad results. As project managers, we should remember what the user tells us and what we derive from the user requirements.
About the Author
Dwayne Phillips has been a computer and systems engineer with the U.S. Government since 1980. He co-authored "It Sounded Good When We Started, Working with People on Projects" with Roy O'Bryan and wrote "The Software Project Manager's Handbook, Principles That Work at Work" now in its second edition. Dwayne Phillips can be reached at d.phillips@computer.org. His web site is http://home.att.net/~dwayne.phillips.