Number 3 in the series, “How to Shoot Yourself in the Foot: 7 ways to do software requirements poorly to set your project up for failure and what to do instead.”

1. Short-change Time Spent on Software Requirements or Don’t do Them at All
2. Don’t Listen to Your Customer’s Needs
3. Don’t use models
4. Use weasel words
5. Don’t prioritize requirements
6. Don’t  baseline and change control requirements
7. Don’t do requirements traceability

One good way to ensure missing, incomplete or inaccurate software requirements is not to use models or to use them poorly.

We use models all the time to understand the world around us and apply its resources for our benefit.  We have used models for thousands of years, from some unknown ancestor drawing diagrams in the dirt with a stick to physical models for astronomical events in ancient cultures to modern models for the human genome, smart phone or a huge corporate IT project.

The British Royal Navy made extensive use of models in the 18^th and 19^th centuries as a critical step in building complex warships. They still have thousands of them preserved in museums. They used models to provide a level of abstraction between the business requirement to “build a 100 cannon man-of-war” and the detailed requirements, plans and tasks to build the ship. They needed to:

• Organize large amounts of information
• Figure out what’s missing
• Give context to a collection of details
• Focus on a particular subset of requirements
  • E.g. the rigging team is interested in the mast and sails and the cooking team is interested in the galley
• Make it easier to find and fix requirements errors early
  • E.g.  it costs much more to fix these problems downstream. If the mast or beam is one foot too short, the project has failed.
• Provide traceability
  • E.g. tracing from the end product back to the model to the business requirements supported continuous process improvement.

Software Requirements models are used for the same reasons. As complex as building large sailing warships was 300 years ago, large modern software projects are far more complex if one thinks of a line of code as a “moving part”. (Dr. Fred Brooks discusses this “essential complexity” of software systems in his excellent 1986 IEEE-CS article “No Silver Bullet – Essence and Accidents of Software Engineering”)

Here are some common ways to misuse models for software requirements:

Don’t use models at all.

1. There is always the temptation to skip a higher level of abstraction and get down to doing the “real” work.
2. The amount of modeling needed is correlated to the size and complexity of the system to be built. There is a place for no models on really simple systems. The problem is not using models on non-trivial systems. Remember Barry Boehm’s study I referred to my introduction to this series – It can cost a 100 to a 1,000 times or more to fix a requirements error at the end of the software life cycle than it does at the beginning. What is the potential cost of not using models at all for your project? It is like the old Mr. Goodwrench commercial: “pay me now or pay me (more) later”.

Use only one model type

1. Different types of models give different perspectives. I think of the old parable about the 5 blind men each touching a different part of the elephant and from their individual perspective they don’t perceive that it is an elephant at all. For example, if one only uses process flows, you run the risk of missing requirements that would be obvious on a state transition diagram.
2. At ArgonDigital we think of models in 3 categories:

• People models show who uses the system and how. E.g. Org charts, Use Cases, Decision Trees
• System models detail the interaction between systems. E.g. Context Diagram, Cross Functional Process Flows, Display-Action-Response Tables
• Data models focus on the information in the system and how it is modified. E.g. Business Data Diagrams, Data Flow Diagrams, State Tables

Overload models

1. A model that shows process flow and data flow and actors and state transitions would clearly be absurd. But it is not uncommon to see two models mixed, for example, adding process flow to a data flow diagram, or mixing decision trees and process flows.
2. At ArgonDigital, each model in our RML^TM (Requirements Modeling Language)

• Is designed to be as simple as possible
• Conveys only necessary information about your requirements
• Is easily readable by business experts and developers

Don’t get feedback on the models until after finishing requirements

1. Getting the model right helps get the requirements right. If the system you are working on is complex, you want to find and fix requirements errors as early as possible (yet again, the Boehm error-fix cost curve).
2. Models help focus communication with your customers. If you wait until you have detailed textual requirements to talk to your stakeholders, you are not using their time effectively. You may miss an entire category of requirements or it may be incomplete. You may “miss the forest for the trees”.

Do models after the requirements are already done and reviewed

1. Doing models after the fact to “put a check in the box” misses the value of models as a level of abstraction for thoroughness of requirements. This is doing models as a book report. This problem is not unique to using software requirements models properly. Think of all the corporations that did ISO, CMMI, ITIL, etc., to put a “check in the box” rather than leverage these frameworks in a useful manner. Scott Adam’s comic strip character Dilbert called this check-in-the-box approach “creating a ‘Big Honkin’ binder”.

We have many blogs covering models. Here are some links to a sample set:

Don’t shoot yourself in the foot on your next project! Resolve today to use models and use them wisely for software requirements. The choice is yours.

Next time I will look at “Use Weasel Words”