JackRing offers this perspective as an alternative to UseCase based engineering.
... What is needed is a list of testable
assertions about ways the business can be helped with automation of
information and decision. We should be testing whether the business is
helped by the "system" not simply whether the "system" exhibits
capabilities 1, 2, 3, etc., as listed in the requirements.
The solution is found in the principles of systems, especially ControlSystems?
, and especially GoalSeekingControlSystems?
, and in the practices
. The answer is to create a model of the problem
(the problem system, PS) and a companion model of the conceptual solution
(the problem control system, PCS). Then inspect and observe how the models
interface and interact (the inspecting and observing will be several-fold
more effective if the models are animated or the Problem System operation
can be simulated).
When those responsible for creating the problem control system can:
- describe the stimulus scenario that emanates from the problem system,
- determine which stimulii will be handled by the problem control system and
- specify the necessary and sufficient response that the PCS must deliver,
then, and only then, are they qualified to proceed with the design of the PCS.
Else? -- c.f., RabidPrototyping.
Note that this essentially demands that the operational users be considered
a regular component of the PCS; not users
outside the system
who are merely interacting with screens.
Furthermore, the developers and maintainers of the system, including the sponsors, funders and decision makers, also all need to be considered as components of the PCS. Initial and ongoing software development is an integral part of the required solution. What we want is not just solution, but ongoing SolutionEvolution?.
This approach, which has been used successfully for years by a few, makes
the chronic problem of RequirementsEngineering
go away (IvyHooks?
notwithstanding). In my view, use(less) cases are yet another attempt at
discerning and documenting requirements. Unfortunately, they invite a
focus on each point
of interface between the Problem System and the Problem
Control System, but not on the scenario
of systems interaction.
Accordingly, they are comparable to data modeling when we all know we need
to model behavior.
It is true there is not much in the literature, especially the computer
science and software engineering literature, because those disciplines
never discovered general systems, cybernetics and the like. But there is a
good body of literature on systems think, principles, and practices which
I'll be glad to cite if you promise to read it. I am detecting such
thoughts in the recent exclamations by AdeleGoldberg
, for example, so
suspect she is coming to see the light.
Literature is not the answer, however, because systems think, principles,
and practices involve TacitLearning?
which must be experiential. It is
learned in a studio or conservatory, rather than a lecture hall or library.
(My learning was on automobile race tracks.) This is why I strongly
to start his Institute. Today it is primal but
eventually it will be like Julliard or the Bauhaus.
We don't have to argue about use cases -- we just have to use the "fit for
purpose" test. It is interesting how people strive to hang onto what they
know even when it doesn't meet their needs. Some of my use case friends
have even tried to respond to the above advice by creating the notion of a
wherein they bring together the details from the several
(hundred) individual use cases and merge them into an overall model. This
is better than individual use cases but is essentially futile because it
amounts to trying to back into an understandable model of the Problem
System without actually modeling it.
It would be much quicker to do ConvergentEngineering?
to describe the
Problem System. Then some DivergentEngineering?
to nominate Problem
Control System models followed by some convergence engineering to settle on
the Problem Control System design and architecture.
Why is it we keep looking for a simple recipe when we are being asked to
choreograph stimulii catchers?
Why is it
that people continue to think they can design systems when
they know absoutely nothing about system theory? You
wouldnt expect someone to design a circuit without knowledge
of Kirchhoffs law, would you? And yet that is exactly what
people expect themselves to be able to do at the system level.
I know that serous, fatal, errors in system design have been
made that no amount of domaine expertice
can even discover
let alone cure. You can get all the experts in all the hardware,
software and bioware fields together, a "dream team", and they
still will not be able to design a system without fatal flaws unless
someone knows something about system theory at a level above
his domain experise. And the only way to learn this is through
mathematics, in my opinion, and you know where they can find that!
I don't understand this. People build systems that work all the time.
We build software systems, companies, and communities. We fail a lot,
but we succeed a lot, too. Perhaps you really mean that we could be
more successful if we knew this system theory. But perhaps you *really*
should start by defining system theory. I read some books
on what I vaguely recall was system theory about 15 years ago, and at
the time I didn't think they were useful. I'm willing to think about
the subject again. But not just because of some wild claims that seems
When designing an automatic breaking system for a car, would you like someone
to have an idea about control theory, or would you want it TDDed into existence?
Neither... I'd like someone with an idea about control theory and
have it TDDed into existence.
Please do not work on my breaking system.
What? You have a problem with somebody knowing the underlying dynamics of control theory having an automated way of determining if each change he makes to the system both accomplishes what he was intending and notifies him of any previously noted possible regression? Please, do not work on my
braking system. ;p