[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

RE: [ba-ohs-talk] Solving complex problems - Requirements and Constraints


Gary,    (01)

Thank you.  It is amazing how rich some of the exchanges have been lately.
Also, in some sense it is inspired as the result of someone taking an
apparently strong fixed position!  It seems to have some others look at what
is the unrecognized fixed position that is latent in our easy acceptance of
some viewpoints and not others.  One valuable quality of participants here
is that they are willing to look when asked what has them accept something
unquestionably.    (02)

I have a request.  Working in a different and more narrowly-technical
setting, I recently used "requirements and constraints" in a note designed
to bring another discussion back from conflicting proposed solutions to
agreement on requirements and constraints.  I have used that pairing in the
past, but my latest effort showed me that I am not very accomplished at
getting to the requirements (stripped of commitments to particular
solutions) and distinguishing them from constraints.    (03)

Do you know somewhere that has "requirements and constraints" laid out in
more detail?  I want to raise my competence in that area.    (04)

-- Dennis    (05)

Dennis E. Hamilton
AIIM DMware Technical Coordinator
------------------
mailto:dennis.hamilton@acm.org  tel. +1-206-932-6970
http://DMware.info/             cel. +1-206-779-9430
     ODMA Support http://ODMA.info/    (06)

-----Original Message-----
From: owner-ba-ohs-talk@bootstrap.org
[mailto:owner-ba-ohs-talk@bootstrap.org]On Behalf Of Garold (Gary) L.
Johnson
Sent: Thursday, September 12, 2002 16:30
To: Ba-Ohs-Talk
Subject: [ba-ohs-talk] Solving complex problems    (07)

[ ... ]    (08)

Note that this is dramatically different from obtaining everyone’s view of
how to solve the problem. Views of solutions may give a handle to the
concerns, the proposed solutions are not requirements or constraints, and
tends to promote the polarization that can stall fruitful discussion.    (09)

Let’s take a crack at some definitions.    (010)

Situation – the actual state of affairs. This has nearly been corrupted to
mean “an undesirable state of affairs”, but I intend this in its emotionally
neutral form. Note that statements of the situation are impacted by
individual perception, amount of information, viewpoint, etc.
Here is an area where open discussion and large-scale participation can be
extremely useful.    (011)

Problem – an undesirable state of affairs, a departure from the ideal scene,
a situation that needs to be changed. This must e stated in terms of
outcomes, not proposed solutions.    (012)

Proposal or Solution – some change in the existing situation that claims to
be workable and to move the situation in the direction of meeting more of
the concerns that cause the situation to be seen as a problem.    (013)

[ ... ]    (014)

As the set of concerns develops, it reaches a point where we can attempt to
design a solution that takes the requirements and constraints into account.
Each proposed solution needs to be evaluated as to the extent to which it
addresses each concern, and how the solution can be improved. Designing such
solutions is not easy, but until we know what the requirements and
constraints really are, starting polarized arguments over proposed solutions
that were never designed, validated as workable, and reviewed for impact is
counter productive.    (015)

There are system development technologies that attempt to do some of this
that may serve as models.    (016)

[ ... ]    (017)