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
**** 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/=
caab4CEbUrKDAbWnbtka/ 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

On Mon, Mar 29, 2004 at 08:10:54AM +0100, Jason Gorman wrote:
> > "Create one functionality module for each unique stimulus
> > set of the functionality tree."
>=20
> Or you could encapsulate your requirements as executable (and
> self-explanatory) system tests :-)

Suppose I did that? Suppose for each "requirement" I create
an object that implements a "Requirements Object" interface,
and that instance of the requirement object is responsible
outputting description/explanation of that requirement and
running and executing its tests and presenting the results.

How might that code "evolve" over time in structure assuming
I continually apply "incremental structural modularization"
(e.g., refactoring) as new requirements and information come
in to maintain high cohesion and low coupling and good
encapsulation/localization of these objects?

I have worked in an internal IT shop where "requirements"
were formally captured in the form of use cases, and since
the number of projects being worked on was huge and "good"
IT portfolio management and governance was highly valued,
use-cases where captured in a global database rather than
a project-specific one, and keywords were used to aid
searching, and when a new request came in against a particular
project one could first to some amount of querying to see if
any existing project in the department already had documented
(and maybe even implemented) a similar requirement based on
functional category, bottom-line business functions supported,
actor/role (user-type) category, technologies used/requested,
interacting "agents" (e.g., manual, software, or hardware
systems/events/stimuli) and a few others.

And this usecase-"base" eventually took on a hierarchical=20
structure, with different kinds of relationships between
use-cases (extends, generalizes, subpart-whole, exception)
and both the relationships and content of and between use-cases
would be "refactored" to support better encapsulation/independence
of the use-cases in usecase-base and localize impact of changes.

So we had what you might call a "use-case" tree which sounds
a lot like a "functionality tree" (actually, it was more like
a forest) and different sets of relationships, actors, related
events, and input-types. And we would "refactor" regularly so
we could more easily identify when a new requirement matched
(and how closely it matched) that of an existing project and
help decide which project (old or new) was the most suitable=20
one to try and work it, and to allocate funds/materials to in
order to best serve that business function being supported.

How is this the same or different from what Rick describes
as a functionality-tree and a stimulus-set and a functionality
"module"?

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