Iteration 1 Requirements and Emphasis: Core OOA/D Skills - UML

In these case studies, iteration - 1 of the elaboration phase emphasizes a range of fundamental and common OOA / D skills used in building object systems. Many other skills and £teps - such as database design, usability engineering, and UI design - are of course needed to build software, but they are out of scope in this introduction focusing on OOA / D and applying the UML.

NextGen POS

The requirements for the first iteration of the NextGen POS application follow:

  • Implement a basic, key scenario of the Process Sale use case: entering items and receiving a cash payment.
  • Implement a Start Up use case as necessary to support the initialization needs of the iteration.
  • Nothing fancy or complex is handled, just a simple happy path scenario, and the design and implementation to support it.
  • There is no collaboration with external services, such as a tax calculator or product database.
  • No complex pricing rules are applied.

The design and implementation of the supporting UI, database, and so forth, would also be done, but is not covered in any detail.

Monopoly

The requirements for the first iteration of the Monopoly application follow:

  • Implement a basic, key scenario of the Play Monopoly Game use case: players moving around the squares of the board.
  • Implement a Start Up use case as necessary to support the initialization needs of the iteration.
  • Two to eight players can play.
  • A game is played as a series of rounds. During a round, each player takes one turn. In each turn, a player advances his piece clockwise around the board a number of squares equal to the sum of the number rolled on two six - sided dice.
  • Play the game for only 20 rounds.
  • After the dice are rolled, the name of the player and the roll are displayed. When the player moves and lands on a square, the name of the player and the name of the square that the player landed on are displayed.
  • In iteration - 1 there is no money, no winner or loser, no properties to buy or rent to pay, and no special squares of any kind.
  • Each square has a name. Every player begins the game with their piece located on the square named "Go." The square names will be Go, Square 1, Square 2, ... Square 39
  • Run the game as a simulation requiring no user input, other than the number of players.

Subsequent iterations will grow on these foundations.

In Iterative Development We Don't Implement All the Requirements at Once

Note that these requirements for iteration - 1 are subsets of the complete requirements or use cases. For example, the NextGen POS iteration - 1 requirements are a simplified version of the complete Process Sale use case; they describe one simple cash - only scenario.

Note also that we haven't done all the requirements analysis for the NextGen POS system, we've only analyzed the process Sale use case in detail; many others are not yet analyzed.

This is a key understanding in iterative lifecycle methods (such as the UP, XP, Scrum, and so forth): We start production - quality programming and testing for a subset of the requirements, and we start that development before all the requirements analysis is complete - in contrast to a waterfall process.

Incremental Development for the Same Use Case Across Iterations

Notice that not all requirements in the Process Sale use case are being implemented in iteration - 1. It is common to work on varying scenarios 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 completed within one iteration.

Use case implementation may be spread across iterations

Use case implementation may be spread across iterations


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

UML Topics