Colin Law wrote: > On 8 October 2010 03:34, Marnen Laibow-Koser <[email protected]> > wrote: >> involved before thinking about the desired functionality. >> I'll turn the question around: why would you want to consider >> implementation before functionality? �What possible benefits could it >> produce? > > Well of course you need some idea of functionality before anything can > be designed. If I can bring back a quote from your earlier post: > >> ... when I >> put together an application, I usually think first about how I want it >> to present itself to the user and what the user should be able to >> accomplish (and write Cucumber scenarios accordingly). Only as a result >> of making those scenarios reality do I write model classes or anything >> else. > > I am suggesting that there is a phase before considering in detail how > the application should present itself to the user.
There is the phase of deciding in very general terms what the broad goal of the application is -- in your case, something like "people should be able to order products from us". > For example to > take the ubiquitous shopping app, before considering how the logon > page should operate there is the decision that there will be users and > that there should be a page where the user can logon. Sort of. Out of the idea that users can order products comes the idea that we need a way to tell the system who's ordering. From that idea may come the fact that we want user accounts and a login interface. That's probably as far as I'd go down that particular path in initial requirements gathering with my client. > Similarly > before considering how precisely the user adds a product to his > shopping cart there is the decision that there will be products and > shopping carts. First step: Users should be able to order products. Second step: We want to present them a shopping cart interface to do so. Third step: Users should be able to do the following things from that interface. The domain concepts emerge from requirements gathering. They are not considered before it so much as simultaneously with it in my experience. > It is at this stage that initial stabs at what the > models will be can be made (note that I am not suggesting writing any > code here, merely thinking about what the models will be). No! It's premature. The business domain objects are a good start for guessing what model classes you'll need, but it's absolutely wrong to be thinking like a programmer when you're doing business analysis. > It does > not seem feasible that one can write a Cucumber scenario for user > logon and then go from that to the idea that maybe one needs a user > model. I assure you, it is entirely feasible. I do it all the time: write a Cucumber scenario with perhaps only the vaguest idea of what models I need, then start experimenting with the best way to make it pass. Remember, Cucumber scenarios are written in English for a reason: they're meant to test user-facing behavior, not code. You could completely rearchitect a system and still have the Cucumber scenarios pass. > Is it not true that the concept of a User must exist before > one can write the scenario? The business concept, sure. But it's premature to translate that into a concept of a User class in the requirements gathering stage. (To be fair, user management is simple in most cases and requires a User class. But I've been doing stuff with my medical records application where I may have a bunch of features gleaned from the client and translated to Cucumber stories -- and still have no idea what the underlying models should look like.) > Note again that I am not suggesting > writing any code at this time, just thinking about what the models > should be. And I'm telling you that that's a bad idea. Don't think about models till you actually need to write them. > > Colin Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] Sent from my iPhone -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
