Project-oriented deliverables, or scope, support the project management and IT development processes that are defined inthe information technology project methodology (ITPM). Project scope includes such things as thebusiness case, project charter, andproject plan and defines the work products of the various ITPM phases. Project-oriented deliverables also include specific deliverables such as a current systems study, requirements definition, and the documented design of the information system. These are deliverables supported by the systems development life cycle (SDLC) component of the overall ITPM.

Project-oriented deliverables require time and resources and, therefore, must be part of the overall project schedule and budget.

Their role is to ensure that the project processes are being completed so that the project’s product (i.e., the information system) achieves the project’s MOV and objectives.

Project-oriented deliverables also provide tangible evidence of the project’s progress (or lack of progress). Finally, they allow the project manager to set a baseline for performance and quality control because they usually require someform of approval before work on the next project phase or deliverable begins. In general, the application system will be the largest project deliverable and will, therefore, require the most time and resources to complete.

Identifying the features and functionality of the application system (and their complexity) will be pivotal for estimating the time and cost of producing this deliverable. Product-Oriented Scope Definition Tools Product scope therefore focuses on identifying the features and functionality of the information system to be implemented. A useful tool for refining the scope boundary and defining what the system must do is a modelling tool called a context level data flowdiagram (DFD). A DFD is a process model that has been available for quite some time and is often taught in systems analysis and design courses.

A context level DFD, however, presents a high-level representation of the system that has one process (i.e., a circle or rounded rectangle that represents the system as a whole) and depicts all the inflows and outflows of data and information between the system and its external entities. The external entities are usually represented by a square and can be people, departments, or other systems that provide or receive flows of data.

Arrows represent the directional flow of data between external entities and the system. Each arrow and entity should be labelled appropriately.

Lower level DFDs can be developed later to model the processes and flows of data in greater detail. An example of a context level DFD for our banking electronic commerce system is provided in Figure 5.4. As you can see, the high level features and functionality of the system focus on what the system must do.

Another useful tool for defining the product scope is the use case diagram, which has been used in the object-oriented world as part of the Unified Modelling Language (UML).

While Jacobson (Jacobson, Christenson et al. 1992) introduced the use case as a tool for software development, a use case diagram can provide a high level model for defining, verifying, and reaching agreement upon the product scope.