You are currently browsing the tag archive for the ‘software requirements’ tag.

When requirements analysts are thorough, those who read and use the requirements can easily get lost in the muck and mire of the details. I have found that diagrams can add much more specificity to requirements than lengthy narratives describing business rules. This diagram depicts a small excerpt from a requirements model of a financial system.

This tiny drawing eliminates the need to write out all of the following business rules, because they are all clearly shown in the model:

  • Every account must be associated to one customer.
  • An account cannot be associated to more than one customer.
  • An account cannot exist if it does not have a corresponding customer.
  • A customer must have at least one account.
  • A customer may have more than one account.
  • An account must be either an individual account or a corporate account.

Some restrict the use of drawings like this for design, others argue that domain models are old school. I have had great success using this approach for describing business rules. The economy of words eliminates ambiguity, is much more thorough, and can be easier for a designer/developer to use when designing a solution.

Advertisement

The first mousetrap was invented over 100 years ago. To this day, many have pursued the perfect mousetrap. Ralph Waldo Emerson added fuel to the fire when he said, “Build a better mousetrap and the world will beat a path to your door.” So what is “better”, anyway?

The de facto mousetrap choice is the “two for a dollar” Victor snap trap (pictured.) It’s easy to use and has a nearly 90% success rate in achieving its intended goal. So if that’s the case, why have over 4400 mousetrap patents been issued by the US Patent Office? What are we looking for in a mousetrap anyway?

In surveying the market, I found everything from mouse electric chairs to mouse gas chambers . (The latter actually sends you a text message when the deed is done.)

If building a better mousetrap were a software development project, I’d be fascinated to learn what the world really wants in a mousetrap. My guess is that some want cheap, some want exotic, and still others want humane. If I were assigned to the “build a better mousetrap” project, there may truly be 4400 viable (and vastly different) solutions. Therein lies the problem for requirements analysts – The primary functional requirement of all mousetraps is the same (don’t make me say it.) Nailing the surrounding requirements, the values of the stakeholder, the attributes of the target solution — it’s all this stuff that can turn a simple project into a huge project. In my many consulting assignments around the world have encountered very few requirements analysts who truly know how to manage these requirements very well…and it’s these surrounding requirements that can make the difference between project success and project failure.