One of the most difficult aspects of gathering and documenting software requirements is to get all of your stakeholders and project team participants to agree on terminology, especially words commonly used in the business domain. Common usage is never very precise, and often business problems arise from ambiguities in common usage. In developing a conceptual…
Uncategorized
Transposition of the Familiar
Have you ever had the experience of having someone explain something new to you, and somewhere along the way, your brain replaced something new with something familiar? So when you went to the next step, to work on the new thing, you immediately became confused and either did the wrong thing, or did something that…
Document Driven Design
Software design is a process. It is a process of taking one abstraction – a business oriented model, and constructing a different abstraction – a technology oriented model. Since there are many different technology paradigms, the technology oriented model differs based on the paradigms selected. The business oriented model differs by business, and the problem…
A Template That Inspires Innovation
After adopting a new design process philosophy, and implementing a trial project using it, a design anti-pattern has presented itself. Document Driven Design – this anti-pattern is the practice of allowing whatever document template is mandated, drive the actual process or practice of design. It is common in the enterprise space, especially post Sarbanes-Oxley where…
The Solution
The notion that there is a single solution to any problem is a fallacy. There may be a solution to an equation, but every problem has more than one possible solution. We learned in math that there is one right answer for every arithmetic "problem". But in fact even that is fallacious, because we can…
A Framework
The first step in problem solving is root cause analysis. Identifying the root cause requires a framework. A simple set of questions, the answers to which allow you to rule out probable causes, so that you can investigate only the probable causes you can't rule out. I have watched as team members exercise a brute…
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…