I've been trying to follow this methodology for a few years now... I like it, I think I understand it and I think it's improved the software that I produce.

Thanks to Dante Borillo for making these notes available online. Apologies if I've hijacked them inappropriately - I've reproduced them here in case the source disappears.

Ref: http://pst.web.cern.ch/PST/HandBookWorkBook/Handbook/SoftwareEngineering/UCDOM_summary.html

The approach in a Nutshell

  • Identify your real-world objects and the generalization + aggregation relationships between them (Domain model static diagrams)
  • (Possibly perform a rapid prototyping of the proposed system)
  • Identify your use cases (Use Case Diagrams)
  • Organize the use cases into package diagrams
  • Allocate functional requirements to use cases and domain objects

Milestone 1: Requirements Review

 

  • Write a description of the use cases, both "mainstream" + alternative courses
  • Perform Robustness Analysis:
    • identify objects which accomplished a stated scenario
    • update the domain model with this objects
  • Finish the analysis class diagram

Milestone 2: Preliminary Design Review

 

  • Allocate behavior. For each use case: (Sequence diagrams)
    • identify the messages between different objects
    • (if needed collaboration diagrams to show key transactions between objects)
    • (state diagrams to show the real-time behavior)
  • Finish the static model with the detailed design (Detailed design static diagrams)

Milestone 3: Detailed Design Review

 

  • (If needed produce deployment + component diagrams to help in the implementation phase)
  • Write/generate code
  • Perform unit + integration testing
  • Perform system + user-acceptance testing

Milestone 4: Delivery



And while I'm at it there's a document referenced there that is pure gold: "Issues in Requirements Elicitation" - M.G. Christel, K.C. Kang - SEI

 Here's an excerpt:

The goal of requirements engineering is the production of a good requirements specification.

The IEEE Guide to Software Requirements Specifications [IEEE 84] defines a good software requirements specification as being:

  • unambiguous
  • complete
  • verifiable
  • consistent
  • modifiable
  • traceable
  • usable during operations and maintenance

Recent requirements engineering literature is in agreement on this set of attributes, with the added property that the requirements should be necessary [Cordes 89], [Schouwen 90]. The requirements should be prioritized as well, particularly in novel situations where the order in which the subgoals are addressed significantly impacts the final solution [Holbrook 90].