On Mon, 18 Oct 2004 16:40:08 +0200, Christoph Hormann wrote:

> Andrew Clinton wrote:
>> So, when discussions begin for POV-Ray 4.0, will the Team provide an
>> open forum for user suggestions?  My vote is for "povray.wishlist".  As
>> a programmer, I'm also wondering how you really keep "requirements" and
>> "design" seperate.  A discussion of requirements necessitates some
>> degree of discussion of feasibility,
> 
> No.  As an engineer i can tell you that when planning a new design you
> start with the requirements alone.  Limiting the requirements from the
> beginning to only require what is feasible will result in no innovation
> at all (and i am quite sure this applies for program design as well). So
> what you write here to me indicates that you have no idea what
> formulating the requirements actually means.
> 
> 
I never said to limit the requirements to what is feasible.  What I
believe is that there is a progression of discussions that might happen as
interesting suggestions are brought to the table (requirements), where
they are first discovered and discussed from the user's standpoint, then
considered in a more technical context by the programmers (feasibility and
design).  I don't see any reason that should necessitate a full
requirements gathering and accounting (up front) and then a design phase.
As an engineer, you should recognize this as a waterfall model.  From my
experience (which so far isn't too much, only ~2 years programming in
field, but this is what I've been accustomed to), a much better method is
to design things in a more flexible way, in which the process can loop
back to revisit and integrate changing requirements, and improving
knowledge of the target that you are aiming to achieve.

I've been able to do design up front (waterfall) for only extremely small
projects.  The types of projects that I am thinking of, are those where
you can fit the entire design into your head, because either you have a
vast background in the technical area that you are designing for, or you
have "done it all before". If the POV-Team has this level of knowledge of
what they intend for the next version of POV-Ray, the foresight to plan
for future needs, and the technical knowledge to put it all together
(within reasonable timeframe), this is probably the best method to use and
I would agree with you.

> So again my suggestion: if you want to start some discussion helpful for
>   future POV-Ray design start with talking about requirements.  The most
> useful discussions usually arise from users talking about something they
> would like to do but that seems difficult/impossible with current
> POV-Ray.  The majority of such postings can of course be answered with
> an already existing and well working solution but from time to time you
> see things that really hit a weak point.  If you then really try to
> formulate what you actually want to do - as concrete as necessary but as
> general as possible - you are already half way finished.
> 
> A povray.wishlist newsgroup will only result in a lot of feature
> suggestions and i have already explained why there is not much use in
> proposing features at the beginning.  Everyone who likes to make an 'i
> would like feature xxx in POV' should ask himself what he wants feature
> xxx for and voila - you are again talking about requirements.  A
> separate newsgroup for discussing requirements would only make sense IMO
> if the discipline to keep the discussions on-topic is maintained there.
> 
> 
While I agree that there may be some superfluous discussion in such a
group, I don't agree that this is necessarily harmful.  The other
newsgroups here seem to have been well moderated to encourage users to
post on-topic responses, so why not for a requirements group?  As for
stating general requirements, there will be some users who can bring their
statements to the quality level that you are looking for.  The others,
although less refined, can still be interpreted and understood with a
small amount of effort from the moderators, like is done in any reasonable
company with good customer support.  You just need to have the ability to
abstract a multitude of requests into a few core features that could
support the vast majority of items people are requesting (which I believe
is one of the first things should be done in coming up with a good design).

Post a reply to this message