Figure 14 depicts the flow of a classic Waterfall/BDUF approach: In the Analysis phase the requirements for the ATM system may be documented in a “System Requirements” document as the result of discussions, negotiations, analysis, and compromise between the customer agent and the contractor’s system engineer or business analyst. This document is usually named something akin to “System/Subsystem Specifications” (SSS). Once the SSS requirements for the system are “locked-in”, the next phase “Requirements Specification” can begin.

Using a functional decomposition approach, the next levels of requirements are developed: the architecture is produced, which defines three main subsystems, in this ATM example:

·         A User Interface subsystem or component, encapsulating the software for interacting with the ATM user.

·         A Database component, which is responsible for communicating with the bank’s central database and accessing account information.

·         A Hardware Controller subsystem for interfacing with the actual ATM hardware.

For each of subsystem, a “Software Requirements Specification” (SRS) document is produced. Also, interfaces between the subsystems/components are specified in some sort of document, named something like “Interface Requirements Document” (IRS) or “Interface Control Document” (ICD). In theory, if each component meets its SRS requirements, and adheres to applicable ICDs, then the system will function as specified in the original SSS.

Next, an individual or team is assigned to the design and development of each subsystem, based on its SRS. A design is produced for each subsystem, followed by the coding of each software module to implement the design. Then, each module is individually tested (Unit Testing.) Once unit testing is completed, the subsystem is tested as a whole, bringing together the individual modules in a “Software Integration and Test” (SWIT) activity. Finally, the components are integrated and the ATM software system is tested as a whole and validated against the original SSS.

Story/Feature Driven

Figure 5 illustrates development of the same ATM software using a Scrum methodology. Using a Story/Feature driven approach, the ATM system is segmented not into functional components, but rather into a set features corresponding to the system’s use cases: In this example, the ATM software’s list of features may be: Check Balance, Withdraw Cash, Deposit Check, Deposit Cash, and Transfer Balances. Note that in featuredriven approaches, not all features are equal in size or effort. In Scrum, each feature is sized by “story points”, a relative measure of the amount of effort estimated to be needed to implement that feature. For the purposes of this example, let us consider these features equal.

The development team follows by then prioritizing the set of features and starts to develop the software feature-by-feature or a subset of features at a time in short “Sprints”. As each sprint is completed, the set of features developed are added as an increment to the software product’s baseline producing a “potentially shippable product increment.”