21.3. Iteration 2 Requirements
Iteration 2 of the NextGen POS application handles several interesting requirements:
Support for variations in third-party external services. For example, different tax calculators must be connectable to the system, and each has a unique interface. Likewise with different accounting systems and so forth. Each will offer a different API and protocol for a core of common functions.
Complex pricing rules.
Pluggable business rules.
A design to refresh a GUI window when the sale total changes.
These requirements will only be considered (for this iteration) in the context of scenarios of the Process Sale use case.
Note that these are not newly discovered requirements; they were identified during inception. For example, the original Process Sale use case indicates the pricing problem:
|
Main Success Scenario:
... |
Furthermore, sections in the Supplementary Specification record details of the domain rules for pricing, and indicate the need to support varying external systems:
Incremental Development for the Same Use Case Across Iterations
Because of these requirements, we are revisiting the Process Sale use case in iteration 2, but implementing more scenarios, so that the system incrementally grows. It is common to work on varying scenarios or features of the same use case over several iterations and gradually extend the system to ultimately handle all the functionality required. On the other hand, short, simple use cases may be completely implemented within one iteration.
Iteration 1 made simplifications so that the problem and solution were not overly complex to explore. Once again—for the same reason—a relatively small amount of additional functionality is considered.
In a development project the requirements chosen for this iteration in the book would not be the undisputed choice—another possibility is updating inventory, credit payment handling, or a completely different use case. However, this choice is rich with valuable learning opportunities.