of design modeling can get answers to these questions early, resulting in an even smoother agile experience.
If you use the RUP or a modified waterfall development method, you are likely producing use cases to articulate user requirements. I find the best way to arrive at use cases is by first deriving an event list. Using Ellen Gottesdiener's definition from her book, The Software Requirements Memory Jogger, events are the stimuli that trigger the system to carry out some function and their responses. Ultimately, the events are further detailed in the project's use cases.
Use your event list and whatever you have captured in the use cases (e.g., a list of named scenarios, such as "benefit clerk enters a new claim for an existing employee"). Produce an initial class diagram with events and use cases or scenarios. As with user stories, if I have a conceptual data model as well, the more sound the class diagram. These classes eventually become entity classes. From a design perspective, a single use case is an early indicator of a possible class (or classes) that will act as the software "conductor" for the scenarios contained within the use case. These eventually become control classes.
Sequence diagrams are derived by elaborating on scenarios within the use cases, just as they elaborate on user stories. Use cases can provide you with a clear-cut indicator on where to start your design models. Look for the main scenario or pathway through the use case. You don't have to produce one for every scenario through each use case. This depends on the development team that's going to build the software.
Regardless of how I got to the sequence diagrams, I also like to produce one sequence diagram showing all the classes reflecting my software architecture (depicted previously on my software architecture schematic). That is, if it's a .NET, Web-based application, I will have interface classes that are .ASPX pages. If it's a Java application, I'll have interface classes that are .JSP pages. This one sequence diagram would also have the backend classes that translate the entity classes into SQL calls or XPATH streams, depending on my persistence strategy. There isn't a need to do more than one of these sequence diagrams because they're basically the same (from an intent perspective) for all interactions with the system.
In reality, both agile and non-agile projects should use a combination of models to express both the requirements and design. Picking the right models for the type of project is an important decision. Whether you're using less formal or more formal methods, you must produce a roadmap to ensure your customer gets what they chartered you to do in the first place. That's a working solution done in a cost-effective and timely fashion.
- Ellen Gottesdiener, The Software Requirements Memory Jogger
- Paul Reed, Developing Applications with Java and the UML
- Paul Reed, Developing Applications with Visual Basic and the UML