|
| Stable Dependencies |
| Dependability in the direction of stability |
|
Enterprise software is a body of knowledge. We want to know how stable and secure this body of knowledge will stand. The answer is in the foundation of software, the design. We want to know how stable and secure the design will be. The answer is in the foundation of design, the user requirements. The foundation of user requirements is the business model, and the foundation of business model is the customer model, the DNA of enterprise software. Accordingly, we have a hierarchy of knowledge, with the customer model at the bottom and the software at the top. Each level depends on the level below, which is the foundation of the level above.
To develop software is to grow this hierarchy of knowledge. Knowledge is all-important, and it grows all the time through discoveries and decisions we make. Requirements change is due to this un-ruled knowledge growth and is largely internally, not externally, induced. An inherent assumption of the systems thinking worldview is that problems are internally generated -that we often create our own "worst nightmares." A carefully planned knowledge growth strategy can greatly reduce requirements volatility. One knowledge growth strategy that minimizes requirements volatility is identifying the purpose or the essential invariant need (often called abstraction). Once such a need is identified, exhausted, and modeled, next is to search the next-level essential invariant need. This second-level need realizes the first-level need. This realization is derived through the transformation of the first-level need or sub-classing the first-level need (e.g., biology is a special kind, or subclass, of physics), by adding more information. This process can go on until all needed requirements information is encapsulated in this hierarchy of requirements model that is parsimonious, invariant, precise, and inclusive.
The UCRequirement model is built upon a stable foundation by first identifying the purposes of the enterprise software system's customers; second, by modeling business processes that realize the purposes; and then, finally, by building user processes that realize the business processes. It minimizes rework when you start with the most independent level and build up level by level.
|
| |
|
|
