Thursday, 27 September 2007 14:13

Dividing Requirements into Iterations for a Staged Delivery

Written by Joy Matthews

Dividing the Application into Versions

When assembling the project plan it is important to decide how you want to divide the applications into manageable “buckets”. This is an iterative process and will be refined later in the Requirements Analysis, Analysis and Design phases.



The iterative approach divides applications into smaller versions for incremental delivery. The diagram is a simplified illustration of how an application might be divided up by segmenting the application in a top down fashion. When a team divides an application, it has to balance between meeting the needs of the users; working within available resources, and minimizing project risk.


Because the application will be delivered in several versions, the project manager, technical project manager, and the technical team must decide on delivery options such as:

  • A small number of functions with a greater depth of detail
  • A larger number of functions with less depth of detail

The project team should select a broader range of functions to a lesser depth of detail if:

  • The business needs for the application are not well understood
  • Management support is weak. (i.e. they may need to see some intermediate proof-of-concept)
  • The business and/or technical requirements are a moving target that is quickly changing. (i.e. you risk developing something outmoded if you go deep too quickly)

The project team should select a smaller range of functions to develop to a greater depth of detail, if:

  • The underlying structure of the function is well understood and the user also has a good understanding
  • Users can identify 20% of the functionality which returns 80% of the benefits
  • There is a mandatory deadline, such as a federal mandate to quickly get the functionality up. The project is small.

Definitions of Application Versions in an Iterative Approach

Business mock-ups

These are automated facsimiles that present the external look and feel of the application system. Mock-ups are used to clarify user requirements. They are usually not working versions of the system planned for release to a production environment. Creating a mock-up will help the technical team to define the structure and skeleton of the system. The activities in this step include iterations of prototyping to demonstrate the appearance and navigation of the system to its intended audience.

Proof of Concept

The goal of the proof-of concept step is to explore technical options available and prove the feasibility of any key technical portion of the application that is in doubt. Proof-of-concept models are very useful for preventing set backs later in the project when a technical approach is found impractical or impossible to implement.
Unlike the mock-up, which is largely non-functional, a proof-of-concept is a working model that clearly demonstrates that a particular technical approach will work. Proof-of-concept models are often incorporated into the final application version.

First Functional Version

The purpose of this step is to create the first functioning version of the application for the target environment. The emphasis in this version is placed on finding and selecting design solutions. It is important to have a sound architecture as the foundation for future version releases. Changes can be made in future versions but the cost of the change will increase dramatically.
The activities include defining interface requirements, designing internal and external features, building the first functional version, performing usability testing, adjusting the infrastructure and rolling out the version.

Second Functional Version

The focus of the second delivery is on creating core functionality of the application. Rather than working from a “blank sheet”, the technical team is now making changes and additions to an existing baseline of functionality. The team must set up mechanisms to manage changes to the application:

  • As users provide feedback from the first version, there should be a mechanism to track these requests and their status.
  • A software configuration management process will have to be established to track versions of screens, modules, and databases.

Third Functional Version

The focus of the third version delivery is on creating additional functionality and more maintenance style changes. At this time, involve a permanent maintenance team member to facilitate a transfer of knowledge. The focus is on the construction and testing activities. A change control management process will be utilized to prioritize the request for enhancements.

Final Version

The focus of this step is the delivery of the final system functionality. The application is now turned over to a maintenance function. This completes the project. Some choices will have to be made about which functions will be implemented, and which will be held over until a possible later version of the application. The deciding factor will be which functions must be delivered to the end users in order to have a workable application system.

The business system is migrated from a test mode into the production environment. In addition, documentation will be distributed and a user-training program will be developed. The finalized security procedures for the application(s) will be installed. An implementation schedule, including turnover procedures, etc. to operations for production implementation is also created.


Joy E. Matthews is the cofounder and Vice President of Training and Consulting Services for Pierson Requirements Group, Inc., which was founded in 1990. She is an Information Systems Specialist with expertise in implementing Iterative Development and Joint Application Development using many development tools. She is accomplished in business modeling and facilitation techniques. She has participated in all phases of Information Engineering systems development and Total Quality Management projects. She has successfully completed Business Process Re-engineering, Information Strategy Planning, Business Area Analysis, Functional Area Analysis and Business System Design projects for a number of organizations and is a certified facilitator.



Joy trains the latest in UML and the use case methodology using JAD. She is an expert in JAD and UML best practices and industry standards. She is the co-author of Pierson’s repeatable development Methodology for Multi-Tier Architecture projects using Object-Oriented methods and JAD. Joy is the author of the JAD Facilitation and Requirements Gathering Seminar: A Process for Implementing Object-Oriented Projects. She is accomplished in Object-Oriented Requirements Analysis, Analysis and Detailed Design. She has facilitated and managed projects for all phases of the system development life cycle. You can reach Joy at

© BA 2020

macgregor logo white web