Thanks for your input, Luiz. I can see what you mean, I just hope to minimize the number of artifacts. If I can do without the UML-drawings (or whatever), or include them in the Use Case directly, I would be happy (in theory, at least...) /Mattias
________________________________ Fr�n: Luiz Esmiralha [mailto:[EMAIL PROTECTED] Skickat: ti 2004-12-28 17:44 Till: [EMAIL PROTECTED] �mne: Re: SV: [XP] User Stories and 'the Big Picture' Hi Mattias, The way I see them, neither User Stories nor Use Cases are supposed to document the design of the system. IMHO, User Stories, are a commitment between Developers and Customers that some feature is to be implemented. They might contain a few data like the estimate time to implement it, their business value to the Customer and a short description, but do not represent the system's design.They are about "what" not "how". Design is the "how" and should be inferred from tests, code and some drawings (UML or whatever). I think it's the same with black-box Use Cases (the preferred UC type at every place I worked). On Tue, 28 Dec 2004 16:08:28 +0100, Mattias Vannerg�rd <[EMAIL PROTECTED]> wrote: > > > > Hi, Mattias. Ron's answer is, as usual, excellent, but I thought I'd add a > > couple of questions for you: > > Yep, thanks Ron! > > >> 1) Where is the "Big Picture" kept when working with stories? (see > >> below) > >> > >> 2) Where do the design go? > > > When I read this, I wonder: which big picture? And which design? > > Q 1) was with the restriction that the User Story was ripped. I think my > option right now is to not ripping the user story, but to save it if needed. > (Maybe not needed if I still got the Big Picture in my head) > > > For any given product, there are lots of different design representations > > one could make, each one of which captures interesting information. And > > before you start building, when you have a complicated branching tree of > > potential paths through the design space, the problem is multiplied. > > Agreed, and the design space is spanned with user stories in their simplest > form. > > And, therefore I like to keep them. > > I like also to think in terms of expanding the User Stories into Use Cases, > to capture the interesting design issues. But you describe your system's design in the Use Cases? AFAIK, black box use cases are the rule at most places. > > > So which parts of the problem that you are looking to represent that > > aren't represented by story cards? > > For example: User Interfaces and maybe also non-functional requirements, that > is interfacing to some function, can be expressed in the > "user-story-exapnded-to-a-use-case." We usually sketch user interfaces when we are developing them. But storing the drafts after you have the real thing is really necessary? For non-functional requirements, could you use their acceptance tests as the documentation? > > > Thanks, > > Does that answer your question? > > > William > > /Mattias > To Post a message, send it to: [EMAIL PROTECTED] To Unsubscribe, send a blank message to: [EMAIL PROTECTED] ad-free courtesy of objectmentor.com Yahoo! Groups Links [Non-text portions of this message have been removed] To Post a message, send it to: [EMAIL PROTECTED] To Unsubscribe, send a blank message to: [EMAIL PROTECTED] ad-free courtesy of objectmentor.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
