Re: How to design proper classes when the requirements are quite complex?

Mark Space wrote:


You are correct. Actually, I was talking at cross purposes to your points, so
let me correct myself.

When I proposed two weeks for something to call a "product", I was not
referring to any kind of finished work at all. I have directly experienced
well-managed projects where requirements gathering was done via a tool that
directly captured screen ideas as executable interfaces, with no real
behaviors or data behind them. In one notable case, we spent three months
solid in this way before deciding we had the right screen flow. Our first
crude attempts were in place within two weeks, and took heavy criticism.

At all times, we had a document person keep the user manual up to date with
screenshots, and proposed functional requirements for the interface and its
underlying logic. Over three months the changes from one meeting to the next
became smaller. Our meetings were daily, at least three times a week with a
subject matter expert who understood the needs and psychology of the people
who would operate the product from day to day. The finished product was done
in about six months, and was virtually bug free. The major consulting firm to
whom I was contracted got much praise for the result from their large-scale
client.

In fact I am a strong proponent of thorough requirements gathering up front,
participating deeply with the client on an ontological and linguistic level.
Capture the requirements in as realistic a prototype as possible, meaning in
running code that people can see on their computers. Spend a long time
getting the requirements right. Keep the programmers responsible for feeding
every darn change, no matter how tiny, through version control and
notification to the documentation team no less frequently than daily. Use
integrated build-and-test cycles.

Certainly a full-fledged, highly complex system can take up to two years to
build out, but it can still be with staged, evolutionary, live prototypes from
the get-go. This has the added advantage of increasing reportable milestones,
objectively stated, with fine granularity. Project management is actually
facilitated.

I do agree with the original advice offered to the OP, that one must plan
one's business for at least a two-year growth cycle, and prepare funding
appropriately. I additionally propose that certain development methodologies
lend themselves to astonishingly rapid development and satisfyingly complete
visibility during that well-funded, extended business cycle.

--
Lew