[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 10:45:59AM -0600, Rick Lutowski wrote:
> Hardly anyone in the industry today even remembers that Parnas said
> *requirements* could be encapsulated for ease of change.
[...]
> I could not agree more.  The requirements encapsulation
> methodology does exactly this -- recording requirements
> in a manner that permits their encapsulation for ease of
> change leads naturally to an improvement in "beneficial=20
> interaction between user and developer."=20=20

Could you say more about "how" the requirements are
_effectively_ encapsulated? I've read the material at your
jreality.com website - and have seen the material about treating
requirements as black boxes, and creating software objects
corresponding to the requirements such that there is a 1-1
mapping (and hence "traceability" is automatically attained
from that point onward).

So I see how that attempts to encapsulate a requirement.  By the
same token, I can write a class/object and a set of methods,
and I can think I'm doing O-O, but I'm sure we've all seen
examples of code that did this that wants very object-oriented
at all and wasn't very well encapsulated.  Just because I use a
class and methods doesn't mean I am automatically successfully
employing encapsulation and abstraction and information hiding,
or that I am attaining high-cohesion and low-coupling, and
am appropriately separating concerns and dependencies at the
appropriate boundaries and scope.

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?
w


--=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
Are you looking for savings on products you use everyday?=20
Visit Quality Health today and see the coupons, free=20
samples and special offers our members enjoy each and=20
everyday.
http://click.topica.com/=
caab3ozbUrKDAbWnbtkf/ Ivo Interactive
=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
--^----------------------------------------------------------------