(I)f you don't know what you want why do you want me to do something that you will change?

Because it's the best I can do.

As a client, I probably don't know exactly what I want until I try to do it. I can give you a general idea of what I want, and when you give me a program that does it I can use it for a while, see what I like and what I don't, and ask for updates.

Making people sign off on requirements ahead of time isn't a great idea

I have to disagree here. If this was the case then there would be no need for a business case for a project.

Okay, I think I stated my point a bit too strongly. I don't mean that specifications are useless, and that design and development should proceed on an ad-hoc, seat-of-the-pants basis. What I mean is that getting your clients to sign off on a comprehensive business case that doesn't change, ever, is probably going to result in unhappy clients. If nothing else, the business environment is probably going to change between specification and delivery.

By all means, maintain the project's business case: solving the business problem is what your software's all about. When the business case changes, make allowances in the schedule, because changing the program takes time. But it's much better to keep getting feedback over the course of a project's lifetime than it is for the developers to deliver a product that satisfies the initial requirements perfectly and is completely unsuitable for what the company's trying to do now. ("Hey, you signed off on it two years ago, don't come complaining to me if it isn't what you wanted.")

Finally there is a difference between the following (using your example):

all textures will be created from a bitmap.

and this

All textures will be created by our designers. We must agree the formats the application will support as part of the new workflow in the design team.

Sure there is: the first one is a technical requirement, while the second one is not. Only the first one is at all interesting in the context of my example, which was purely technical. Your misunderstanding is probably my fault; I'm using technical jargon with subtle semantic nuances in a public forum that isn't dedicated to graphics programming. (To me, a "texture" is a chunk of memory that the graphics card can map onto polygons, while a "bitmap" is a chunk of memory representing pixels in a raster image. No designers are involved at this level of abstraction.)

This thread is an example of what I'm talking about: we don't really understand each other's assumptions, so we need to go back and forth, clarifying our points and (with luck) iteratively coming closer.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.