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

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


The basic idea of information-hiding is to identify things that have=20
a high probability of change, and encapsulate those things to make=20
the implementing code easier to change later.  If requirements (or=20
data structures, or hardware) never changed, then there would be no=20
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=20
maintenance phase of the software life cycle are requirements changes.
If this is true, then requirements are THE most volatile of all=20
software information.  Requirements therefore should have the highest=20
priority for encapsulation, and should result in the highest financial=20
payback to the customer of any application of the information-hiding=20
approach.

So the answer to your question is an unqualified 'yes.'  Freedom
fully expects the functionality tree will be incomplete or=20
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=20
should make future changes to the code easier when the functionality
tree changes.=20=20

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

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

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


A requirement will never straddle two stimulus sets.  Changes that=20
affect multiple stimulus sets are considered multiple requirements=20
changes, not a single requirements change.  Requirements have=20
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=20

   "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 gen=
erally resistant to change.


As mentioned above, Freedom in no way demands or expects all=20
requirements to be defined up front. The whole approach is=20
predicated on the assumption that requirements WILL change=20
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=20
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 an=
d 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=20
properly.  Various well-established rules of thumb come into play=20
in this regard. One of the better known and most important is the=20
Rule of 7+-2.  Thus, the problem you postulate is not a problem=20
in practice. If it did become a problem due to poor functionality
tree specification, the users would probably be the first to drag=20
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=20
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=20
register to receive up to $50 in savings from one of=20
America's leading menthol brands.=20
http://click.topica.com/=
caab4S3bUrKDAbWnbtkf/ 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.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
--^----------------------------------------------------------------