[usage-centered] Re: Documenting Business Requirements thruUCD
- on 02/12/99 15:44, Larry Constantine at lconstantine@... wrote:
> I am curious about the scope of your projects using evolutionaryIt depends a lot on the development team and project. Our approach is also a
> prototyping, both in size and in time. How long do you take to develop
> initial models? How long is each iteration through the development cycle.
> How many use cases result and how complex is each (e.g., in pages of
process improvement approach so we work with different companies and teams
within user organizations.
On average (if that makes sense in process improvement) for a 12 man.month
project with a team already working out the basics of the method and
notation I would say that initial models in the early iteration would take
from 1 to 2 weeks. From them on evolutionary releases (actual functional
releases) would take also 1 to 2 weeks. Typically there would be a customer
deployment every month or every other month. The actual product evolves
incrementally through a succession of evolutionary prototypes so the
mentioned releases are in fact snapshots of the product as times goes by.
> In short, one should use narrative forms for requirements gathering andWe also use the formal representation only internally. User sessions are
> communication with users and save the diagrammatic arcana for the software
carried out using a modified version of a popular participatory technique
called the Bridge [Tom Dayton et al]. What happens in that users work and
discuss over sticky notes that get translated to activity diagrams in
internal brainstorming sessions. We found out this works very well for all
kinds of initial models (including domain and use cases). There is little
concerns about formality in user sessions, i.e., it unimaginable to use
fork/join constructs with users, although they can appear in the internal
translation. Interestingly users make extensive use of spatial placement of
sticky notes, very similar to your approach in essential use cases. It's a
pity we have some many problems formalizing that kind of information within
UML and modeling tools...
>(...)Couldn't agree more.
> the problem and solution; they are separate but interconnected and should be
> kept that way: separate, interconnected.
Nuno Jardim Nunes
University of Madeira - Teaching Assistant
Mathematics Dep. - Computer Science Unit
phone: +351 91 705160 (direct) 705150 (secretary)
fax: +351 91 705199
Address: Campus Universitário da Penteada
9000 - Funchal - Portugal