Re: [AM] Requirements Encapsulation

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Menthol Smokers Only! Click on the link below and=20
register to receive up to $50 in savings from one of=20
America's leading menthol brands.=20
http://click.topica.com/=
caab4S3bUrKDAbWnbtka/ Lorillard
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Mon, Mar 29, 2004 at 12:55:52PM -0600, Rick Lutowski wrote:
> > So what do we do that can guarantee that each software
> > requirement "object" we create will be at the right
> > granularity, and will 'abstract' the right things and
> > hide/expose the right things, and that the dependencies
> > with and upon other things will result in the "good"
> > properties of high-cohesion and low-coupling and
> > localization of change-impact and resiliency/maintainability?
> > Is there more to it than simply making software "objects"
> > for requirements in the "functional baseline" and for
> > interfaces and sub-items in the "allocated baseline"
> > that will ensure these properties?
>=20
>=20
> You are hitting on exactly the right things -- high-cohesion,
> low coupling, localization of change-impact.  Again, it takes
> a five day course to explain it all properly wrt requirements.
> (This assumes you already have some familiarity with basic OO
> and Java, or similar, programming.)  A web site is not the=20
> proper venue, as I have found through prior hard experience, so
> the details of how to do it, or even how to properly capture
> requirements (the more interesting part) are not on the site=20
> at all.  The site just covers a few fundamentals, and the fact=20
> that it can be done.
>=20
> BTW, in case you're just dying to hear the short answer to
> the requirements encapsulation question, (or maybe think I'm=20
> just being elusive because it's all vapor), here it is:
>=20
> "Create one functionality module for each unique stimulus
> set of the functionality tree."

Okay - so, from what little text there is above, and from
your references to Parnas, the following papers immediately
come to mind:
  "Specifying Software Requirements for Complex Systems:
   New Techniques and their Applications" by Kathryn Heninger
   (paper was a result of the SRC project the author worked
    with Parnas on)
   [BTW - there are some interesting parallels between what is
    described in this paper and the goals of FitNesse.org]

  "On the Design and Development of Program Families"

  "Designing Software for Ease of Extension and Contraction"

  "A Procedure for Designing Abstract Interfaces for Device Interface Modul=
es"

  "The Modular Structure of Complex Systems"

  "Software Aging"
    [interestingly enough, "retroactive incremental modularization"
     seems to be what is called "refactoring" today with its
     buzzword-buddy "emergent design"]

As of 2001, all these papers (and others by Parnas) are available
in the book "Software Fundamentals: Collected papers by David L.
Parnas" and some are even available online at the Software Quality
research Lab at McMaster University that Parnas heads up (tho
he is currently on LOA) at http://www.sqrl.ul.ie/publications.html
(also the paper "Requirements Documentation: A Systematic Approach")

So assume I have knowledge and understanding of these papers,
assume I even have an undergraduate-level understanding of
physics (lets assume two semesters each of kinematics, E&M,
thermodynamics, and maybe high-energy physics and quantum
mechanics) and basic mathematical knowledge of higher-order
multivariate calculus, combinatorics, abstract algebra,
linear algebra, discrete math, probability, and topology,

Rather than "information hiding" in a way that says "I can't
tell you because you don't know enough and don't have the proper
foundation Al background and you have to pay me to take my
training to acquire it", assume instead I'm a well-read software-type
with solid grounding in the above things and knowledge of or at
least access to the body of software engineering publications,
and solid grasp and understanding of object-orientation and
abstraction and encapsulation and separation of concerns,
and separation of interface from implementation, and of
policy from mechanism, etc..

So if you didn't have to talk down to me based on a presumed
lack of knowledge of the above things, what would be a more
peer-to-peer type of descriptive explanation you would use to
talk to someone who knows those things, tho not necessarily your
specific methodology, and how would you describe it to them in
say 100-200 lines of text, and the references you would provide
that are publicly available either online or in available books.

I hereby throw down a challenge to you to do this without hiding
evidence and details behind "you wouldn't understand" and/or
"you have to pay to take my training first" and make an open
and honest attempt to illuminate it here on this list in open
discussion with many other experts with genuine depth and
breadth of understanding in all the above things.

--=20
Brad Appleton <[email protected]> www.bradapp.net
  Software CM Patterns (www.scmpatterns.com)
   Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up=20
handfuls. It's the creativity unleashing, mood enhancing=20
desk toy!
http://click.topica.com/=
caab5n2bUrKDAbWnbtkf/ Crazy Aaron Enterprises
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

For more information about AM, visit the Agile Modeling Home Page at www.ag=
ilemodeling.com
--^----------------------------------------------------------------
This email was sent to: =
[email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.=
bWnbtk.=
Z2NtYS1h
Or send an email to: [email protected]

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=3DTEXFOOTER
--^----------------------------------------------------------------