Usage Scenarios

When you read requirements, do you ever wonder "How will an end user get value from this?" or "What does the user do with that information?" or "How does this detail matter in the big picture?" You may be missing some usage scenarios. Usage scenarios tell you why the user is doing something. Where use

Un-embellished Prose

In authoring software requirements, there is very little room for embellishing prose. When I read requirements that contain embellishments like adjectives or adverbs, I often think that each embellishment represents a requirement that has not been completely articulated. For example, when I read a requirement that has words like "robust", "complete", "performant", "responsive", or my

Quotables

Over my career I have heard or said some amusing things… “Fix like a car, or fix like a cat?” – John Merenkov, M.D. When you fix a car you restore normal operation. When you fix a cat, you prevent the “problem” from recurring. This may be accomplished by brutally removing the source of the

Objective perspective

Sometimes things that appear obvious when viewed from a distance are much less so up close. Organizations and situations appear completely from the inside than from the outside. In order to become objective, one may need to gain some perspective. This may require viewing from different sides and distances. It may require putting yourself in

100% SLA Requirements

Sometimes our customers fail to understand the complexity of modern technology. Our customer expects a system that NEVER fails to complete some critical process. The problem is that when that critical process reaches a certain level of complexity, and/or has a single point of failure this is not a feasible requirement. We all recognize that

Impact Owners

How well do you own the impact of your actions, decisions, and communications? How frequently does the impact of our actions, decisions, and communications not closely reflect our intentions? You intend to partner with someone, but you end up alienating them instead. You propose an aggressive schedule for a project to get people focused quickly,

Specificity

Have you ever received a communication that raised more questions than it answered? A defect report that doesn’t describe expected result, only that the feature is broken? A review of a draft document with a sweeping condemnation of the content, without example or recommendation of desired changes? A project status report indicating that the project

Sooner

We all know that nine women cannot make a baby in one month. When developing a project schedule, projected duration can be calculated as estimated effort divided by full time equivalent resources multiplied by some P or “rho” factor of productivity usually a fraction between six and eight tenths. According to this formula, given an

Vendor Candidates

When purchasing software for your business function, one must consider the following: The software vendor has two value propositions: 1) The capabilities already built in the software product.2) The vendor's capacity to add more capabilities over time. These values must be compared to: 1) the prioritized requirements of your business function.2a) your assessment of the