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

Brad Appleton wrote:
>=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).

I'd love to answer your question about how to _effectively_=20
encapsulate requirements.  The answer is one short sentence=20
of about 13 words. Unfortunately, that sentence would be=20
incomprehensible, sort of like quoting a physics equation=20
without explaining any of the terms.  Even if the terms=20
were given, they would only be understandable to someone
trained in that branch of physics.

The req encap answer is covered in day 4 of a 5 day course.=20
This means that understanding the sentence (the "terms of the=20
equation") requires about 4 day's worth of prerequisite=20
concepts, techniques, and similar knowledge.

This should not be construed to mean that requirements=20
encapsulation is difficult.  Actually, it's quite easy,=20
*IF* the requirements are captured properly.  How to do=20
that, and associated concepts and terminology, are the=20
4 days worth of prerequisite knowledge needed to understand=20
the answer.  (Note: about half of the 4 days is hands-on=20
lab practice to reinforce learning by doing. So only=20
about 2 days of book learning. But I have found book=20
learning by itself without hands-on practice to be=20
inadequate. Requirements capture and encapsulation is=20
a skill set, and skills are learned by doing, not just=20
reading.)


> 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.


Absolutely correct.  OO is not just classes, methods, and
objects.  For example, make your field data public and you've=20
just blown OO right out of the water, and all the classes,
methods, and objects might just as well be old-style Fortran.=20=20

Conversely, I have used Fortran to implement informnation-hiding=20
in a passable manner. (When a university Fortran professor=20
somehow found out about it, he insisted it be published.  This
was in '95.)

Point is, programming artifacts, while they might make OO easier,=20
are not themselves OO.  OO is a set of concepts, the most basic
of which can be utilized in ANY language, even assembler.=20

The requirements encapsulation methodology applies these
basic concepts to requirements.  In doing so, it becomes
necessary to formulate requirements quite differently than
the way "the powers that be" are advocating today.  Hence
the need for 4 days of additional training to understand
how to better formulate requirements so they are=20
encapsulatable. After that, actually doing it is easy.=20


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


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.

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:

"Create one functionality module for each unique stimulus
set of the functionality tree."

Do that correctly and you will have effectively encapsulated
your customer's software requirements.

--=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
**** 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
--^----------------------------------------------------------------