Michael Latta wrote: > I would suggest a different approach to organizing the features. ... > Requirements changes have a different workflow than implementation > bugs. I would recommend you track that difference in your project > management system. Keep an eye on how much changes after > implementation to measure how good your requirements capture has been. > > Michael
This is probably another case where I simply have not yet established in myself a sensible mental framework for working with BDD. Bear with me as I struggle through this adjustment. My apprehension so far is that features are intended to drive out the design requirements by explicitly stating concrete examples of what the client considers desirable. The idea of a contract between developer and client arises from the mutual agreement on functional expression as given in the feature scenarios. Definition steps, on the other hand, are the purview of the design/development team. They can take any reasonable form so long as they: 1. test the functionality of the implementation in a meaningful way 2. meet the requirements of the scenario Unit tests are the purview of the implementers and are tied to their respective code modules. My concern arises from a desire to establish how I should organize the features in relation to one another. Given my understanding respecting features I proceeded from the belief that one could arbitrarily start anywhere in the system design. Features would allow one to elaborate both up and down in detail as appropriate for the stage of the project and the area of immediate concern. As a practical matter it appears to me that the logical flow is Authentication/Authorization, administrative functions relating to record maintenance, algorithmic user applications, report generation, utilities, and finally loose ends. The application can be sliced so that all or most of these issues are dealt with within one specific aspect before tackling another. We are using Redmine to administer the project so milestones, issue tracking and such are kept in there. However, I have acquired this notion of functional decomposition relating to features. As i see it the basic gross requirements of the system (there will be clients, there will be invoices, etc.) are expressed as scenarios in a feature file somewhere. Then as more detail is driven out more features are inserted into the composition tree as appropriate. Is this completely at odds with what I should be doing? -- Posted via http://www.ruby-forum.com/. _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
