Getting started.

Now, where to start... We need to figure out what the user wants in as little explanation as possible. The more you talk to the user the more chance they have to get a vision. Once they get that vision, it will be your responsibility to achieve it. If they start asking specifics or what you think, let them know you just want to get a “feel” for what they want. They can add details once you get the baseline in place. We don’t need/want to know every fringe case and how to handle it. Nobody knows the real business rules anyways. I don’t know how many times I’ve had an expert tell me it “HAS to work this way!”, then during the last week of testing (crazy scenarios are ignored until then), the final user tells the expert that rule was dropped years ago. Same thing with technology targets. I take our build server as an example. We purchased Team Foundation Server, plus Architect licenses for every developer we have. As a skunk works project I setup CruiseControl.Net to build and deploy our dev environment. My counterpart setup TFS, and the whole build process in there. Ran across 2 minor details that he didn’t feel like working out, that CC.NET could handle easily. And here we sit, with our SVN+CC.NET dev environment. If you build it, and it works, nobody will care about the details. So, you have survived the initial requirements gathering. Hopefully with no more than a little sketch of the interface you need to build. And pages of scribble to make it look like you were paying attention. Next time Proof of Concept.