Problem System Perspective
Problem System PerspectiveJackRing 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 of SystemsEngineering. 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:
Else? -- c.f., RabidPrototyping.
Note that this essentially demands that the operational users be considered a regular component of the PCS; not users or actors 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 encouraged DavidTaylor 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 CompositeUseCase? 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? -- JackRing
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! -- WayneWymore
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 obviously false!
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
EditText of this page
(last edited August 9, 2011)
or FindPage with title or text search