23.1. Case Study: NextGen POS
Use Cases
No refinement is needed for the use cases this iteration.However, at a process level I recommend (as does the UP) a second short one- or two-day requirements workshop this iteration (near the end of iteration-1 and again near the end of iteration-2), within which more requirements will be investigated and written in detail. The previously fully analyzed use cases (for example, Process Sale ) will be revisited and probably refined based on insights gained from iteration-1 programming and tests. In iterative methods, note the interplay of early programming and testing with parallel requirements analysis that is improved by feedback from early development.
SSDs
This iteration includes adding support for third-party external systems with varying interfaces, such as a tax calculator. The NextGen POS system will be remotely communicating with external systems. Consequently, the SSDs should be updated to reflect at least some of the inter-system collaborations, in order to clarify what the new system-level events are.Figure 23.1 illustrates an SSD for one scenario of paying by credit, which requires collaboration with several external systems. Even though the design of paying by credit is not handled in this iteration, the modeler (me) has drawn an SSD based on it (and probably several others as well), to better understand the inter-system collaboration, and thus the required support for varying interfaces in the external systems.
Figure 23.1. An SSD scenario that illustrates some external systems.
[View full size image]
Domain Model
After a little experience in domain modeling, a modeler can estimate if a set of new requirements will have a minor or major impact on the Domain Model in terms of many new concepts, associations, and attributes. In contrast to the prior iteration, the requirements being tackled this time do not involve many new domain concepts. A brief survey of the new requirements suggests something like PriceRule as a domain concept, but there are probably not dozens of new things.In this situation, it is quite reasonable to skip refining the Domain Model, move quickly on to design work, and let the discovery of new domain concepts occur during object design in the Design Model, when the developers are thinking through a solution, or indeed even while coding.A sign of process maturity with the UP is understanding when creating an artifact will add significant value, or is a kind of mechanical "make work" step and better skipped.On the other hand, there can be not only too much modeling, but too little. Developers often avoid any analysis or modeling because it seems like a low-value and time-consuming affair. Yet, modeling can add value if one masters the basic guidelines of analysis and design, becomes comfortable with the "languages"be they use cases or UML or UI prototypes on a walland applies these in the spirit of agile modeling.
System Operation Contracts
No new system operations are being considered in this iteration, and thus contracts are not required. In any event, contracts are only an option to consider when the detailed precision they offer is an improvement over the descriptions in the use cases.