Loading ...
Sorry, an error occurred while loading the content.

[usage-centered] Re: Documenting Business Requirements thruUCD

Expand Messages
  • Nuno Nunes
    ... It depends a lot on the development team and project. Our approach is also a process improvement approach so we work with different companies and teams
    Message 1 of 5 , Dec 3, 1999
    • 0 Attachment
      on 02/12/99 15:44, Larry Constantine at lconstantine@... wrote:

      > I am curious about the scope of your projects using evolutionary
      > 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
      > description)?

      It depends a lot on the development team and project. Our approach is also a
      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 and
      > communication with users and save the diagrammatic arcana for the software
      > engineers.

      We also use the formal representation only internally. User sessions are
      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...

      >(...)
      > the problem and solution; they are separate but interconnected and should be
      > kept that way: separate, interconnected.

      Couldn't agree more.

      Cheers
      Nuno

      --
      Nuno Jardim Nunes
      University of Madeira - Teaching Assistant
      Mathematics Dep. - Computer Science Unit
      phone: +351 91 705160 (direct) 705150 (secretary)
      fax: +351 91 705199
      URL: http://math.uma.pt/njn/
      Address: Campus Universitário da Penteada
      9000 - Funchal - Portugal
    Your message has been successfully submitted and would be delivered to recipients shortly.