An architecture document not only describes the solution, it must trace back to individual functional requirements, and also should satisfy the non-functional requirements. In most cases, the requirements must be prioritized, and there will be tradeoffs for meeting absolutely all of the requirements.

In some cases, an architecture exists, and …

Requirements describe the problem, and provide a direction for composing a solution. The remaining deliverables, leading up to the creation of software, are created from the requirements. These includes the architecture, design, implementation and deployment documents.

By defining the problem, the requirements document also serves to bracket the scope of …

Kenny YoungBuck approaches the Master and asks, "What is good design?"

The Master replies, "Kenny, you innocent little monkey, it's a wonder you haven't joined a cult. Good design maximizes business value while minimizing costs including development, maintenance, adaptation and operation."

"Master, are there circumstances where this is not true …

Sometimes a column is not the atomic piece of data you thought it was. See Essay 10.1 for the first part of this rant, which address multi-dimensionality.

A second example of a column not being an atomic piece of data is when we have to support navigation through a …

Software development evolves through four phases:

1. Identification of a problem and inception of a project to implement a solution.
2. Elaboration (analysis) of that problem to determine the most effective solution.
3. Design of software to implement that solution.
4. Implementation of the solution; installing and configuring software, training, and everything that goes …

There are two layers of use case authoring and minimal consensus on which level is "right" for any particular purpose.

1. Business Level use cases - ignore the presence or absence of a GUI, and pursue the business problem. This leaves designers free to create any GUI, perhaps one that is not …

We know something is wrong or can be improved, but we lack the will to drill into details and write a problem statement. It isn't a lack of ability, it is purely a lack of will.

A common source of serious issues with software comes from proposing a solution without …

We're told, repeatedly, to avoid changing horses in mid-stream. We're told not to follow the crowd blindly.

Once upon a time, we made a technology decision that -- at the time -- was right. But things have shifted around a bit, and what was once prudence is now folly. When do you …

The challenge in starting a project correctly is to get a problem statement written down in spite of the lack of clue. There is a pervasive unwillingness to tackle problem description because it is so hard. It's hard because there is a potentially lengthy search to separate proximate from root …

See Holub's column "Requirements Gathering" [Requirements Gathering ] for the goods on what is actually useful and what isn't so useful in this activity we call "Requirements Gathering".

I have to applaud the notion that "focus on the minutiae" misses the whole point. A clear problem statement is perhaps more important …