Re: Virtual Functions in OO Analysis

From: Rod Sherwin (gmail_at_sherwinprosperity.com)
Date: 08/22/04


Date: 22 Aug 2004 03:09:57 -0700

cycoe@hotmail.com (Cy Coe) wrote in message news:<1bd6d89a.0408201542.46c20fd7@posting.google.com>...

<snip>

> > So, to paraphrase, requirements are too important and too crucial to
> > gather and understand up front without feedback from a short cycled
> > iterative approach.
>
> While it is true that a strictly upfront requirements gathering
> approach is not the best way to do things, I think that it is also
> possible to err on the other side - to not spend sufficient time
> trying to understand the problem domain and business requirements
> before plunging into individual features and the concrete world of
> source code and acceptance tests. I think requirements are too
> important and crucial to gather on a strictly trial-and-error basis.

This is one of my concerns being that the development team rushes off
to start coding before actually understanding what the problem is they
are trying solve - along the lines of "Are you lights on?" by Gause
and Weinberg.

I have completely changed the course of a project simply by asking the
stakeholders to write down a problem statement. In doing this they
realised they needed a different focus then the initial direction they
were heading and had already started development on.

>
> The mistake with waterfall was expecting that the requirements (or our
> understanding of them) would not change during the course of a large
> project. Thus, waterfall makes an easy target when comparing it to
> any iterative and incremental approach. But while the waterfall model
> may have been flawed, the discipline it created in terms of
> requirements analysis is still useful, if less crucial than it was
> when you were expected to get it all right the first time.

> Why not have the best of both worlds - a priming scan of the
> requirements space done by competent analysts, and an iterative and
> incremental process which allows the understanding of those
> requirements to be refined and informed by implementation?

A budget may have been granted to the project based on the development
team's estimates of the 'primary scan' of requirements. And then the
development team and steering committee get upset when further
refinement of the requirements results in the inevitably longer
estimates of the work to be done within a fixed time frame and the
already granted budget.

>
> > To paraphrase differently: the best, and possibly only, way to truly
> > understand requirements is to gather and implement them in very tight
> > iterative cycles with lots of feedback from implementers, designers,
> > and users.
>
> That will get you there - eventually. Economically, you will hit a
> point where the next new feature or refinement isn't worth what it
> costs, provided that you have enough time and resources to get you to
> that point. At that point, you're done, until a new requirement comes
> in that's worth incorporating into the software.
>
> One of the issues I have with the XP model is that it insists on one
> hand that requirements are chaotic and subject to frequent change. On
> the other hand, it assumes that requirements can be reliably sorted
> into order of business value, and that this intrinsic business value
> is not only independent of the other features, but is also reasonably
> durable.
>
> If the business and requirements are really that volatile, the list
> would have to be resorted or amended on a daily basis. I've worked in
> shops where priorities changed like this. Feature-by-feature
> priorities, were they maintained there, would have changed too
> frequently to make the list useful.
>
> One thing on which we probably agree is that traditional methodologies
> did not emphasize prioritization/triage of requirements. Scope had a
> tendency to bloat because of the assumption that the
> economies-of-scale of a big project automatically justified the
> inclusion of nice-to-haves that were not worth developing on their
> own. The opposite error is to assume that such economies-of-scale do
> not exist at all, and that all features need to be cost-justified as
> individual development efforts.

Maybe finding that balance of priorities and enconomies of scale adds
to the persisting need for the requirements modelers/business analysts
role.

>
> Discovering requirements purely on a feature-by-feature basis
> precludes the use of many tools and techniques that I have
> successfully used to gather, analyze and refine requirements. And I
> don't think you've replaced what I do with something better.
>
>
> Cy