Dividing Requirements into Iterations for a Staged Delivery

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. Mockups 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. www.piersonrequirementsgroup.com, 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.