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
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/=
caab5n1bUrKDAbWnbtka/ 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

"The basic idea of information-hiding is to identify things that have
a high probability of change, and encapsulate those things to make
the implementing code easier to change later.  If requirements (or
data structures, or hardware) never changed, then there would be no
need to encapsulate them."



 I reckon this is at the essence of agile. Encapsulation has many
advantages, but I have found that the view which produces the easiest to
maintain systems is semantic clarity.
 If the code "says" what it is doing, it is easier to understand. And easie=
r
to maintain.



----- Original Message -----=20
From: "Rick Lutowski" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, March 30, 2004 4:42 AM
Subject: 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
Are you looking for savings on products you use everyday?
Visit Quality Health today and see the coupons, free
samples and special offers our members enjoy each and
everyday.
http://click.topica.com/caab5n1bUrKDAb7u5T4a/ 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

Steven Gordon wrote:
>
> Is it possible to identify a "unique stimulus set", let alone "the
functionality tree",
> without knowing all of your customer's software requirements?


The basic idea of information-hiding is to identify things that have
a high probability of change, and encapsulate those things to make
the implementing code easier to change later.  If requirements (or
data structures, or hardware) never changed, then there would be no
need to encapsulate them.

So what is the probability of change for requirements?

I have a paper that indicates 60-80% of all changes during the
maintenance phase of the software life cycle are requirements changes.
If this is true, then requirements are THE most volatile of all
software information.  Requirements therefore should have the highest
priority for encapsulation, and should result in the highest financial
payback to the customer of any application of the information-hiding
approach.

So the answer to your question is an unqualified 'yes.'  Freedom
fully expects the functionality tree will be incomplete or
otherwise need to change in the future.  This in no way hampers
its development, or the development of the software.  Quite the
opposite.  Freedom specifies techniques for writing code which
should make future changes to the code easier when the functionality
tree changes.

Note that encapsulation doesn't make it easier to change
the requirements spec, but rather the code that implements it.
Encapsulation is a code-centric concept.  But it relies on proper
specification as a prerequisite.  This why we have OO design --=20
it wasn't possible to encapsulate design decisions like data
structures using the old functional design approaches.  Design
specification had to change.

Likewise, requirements encapsulation requires new approaches to
requirements specification.  It is quite ironic that these new
requirements spec approaches are NOT equivalent to OOA.  OOA is just
as inappropriate for requirements encapsulation as functional
requirements!  That may sounds oxymoronic, but it's true. Freedom's
approach to requirements specification has nothing to do with
either OOA (object requirements) or Use Cases (functional
requirements).  If anything, it is closer to Use Cases (depending
on how one defines "Use Cases"; I have encountered at least two
different views of what they are.)  In reality, tho, it is not like
either. A requirements spec that permits encapsulation is neither
functional nor OO, it is external interface-centric.


> What happens when a new requirement or requirement change comes along
later that
> effectively straddles 2 or more stimulus sets that were previously unique=
?


A requirement will never straddle two stimulus sets.  Changes that
affect multiple stimulus sets are considered multiple requirements
changes, not a single requirements change.  Requirements have
sufficiently high granularity under Freedom to make this a non-issue.

It is also worth pointing out that requirements are NOT
recorded using natural language prose (i.e., sentences) in
Freedom.  Parnas once wrote

   "PROSE IS THE SIGN OF AN ERROR" (his caps)

in a requirements spec.  Freedom follows this guidance and
totally avoids prose for requirements capture.  This also
helps avoid "straddling" and similar sticky issues that
can easily result from using prose.


> I have found that approaches that depend on knowing all the requirements
at the beginning of a > project are delusional in most domains, and are
generally resistant to change.


As mentioned above, Freedom in no way demands or expects all
requirements to be defined up front. The whole approach is
predicated on the assumption that requirements WILL change
throughout the entire life of the software, including during
development.  This includes all ways that they might change:
add, modify, delete.  Freedom handles all these requirements
change possibilities equally cleanly.


> What happens when a "unique stimulus set of the functionality tree" leads=

to a "functionality module" that is so large that further decomposition and=

encapsulation is highly desirable?


The granularity of requirements is sufficiently fine that overly
large requirements encapsulation classes never result when the
functionality tree and its constituent stimulus sets are specified
properly.  Various well-established rules of thumb come into play
in this regard. One of the better known and most important is the
Rule of 7+-2.  Thus, the problem you postulate is not a problem
in practice. If it did become a problem due to poor functionality
tree specification, the users would probably be the first to drag
your tail to the carpet about it.  So the users act as another
sanity check against this happening.


Good questions.  They show an appreciation of important issues,
and a healthy constructive skepticism for Freedom's ability to
address them.  It's a pleasure answering such questions.  I
hope you found the answers informative. Thanks very much, Steven.

--=20
Rick Lutowski
Principal, JReality
[email protected]
http://www.jreality.com

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
register to receive up to $50 in savings from one of
America's leading menthol brands.
http://click.topica.com/caab4S3bUrKDAb7u5T4f/ 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

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/=
caab4CEbUrKDAbWnbtkf/ 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
--^----------------------------------------------------------------