Investigation

In Review

1. Introduction

Investigation is the time to develop what the software is going to do, who the user is, what resources will be required, and about what the schedule will be.

Deliverables:

Requirements Document - describes what the software will do
Any feasibility studies needed - proves that it can be done
Schedule - shows when each phase will be completed
Budget - how much it will cost to create
Resource Plan - people, computers, space, data, and other items that will be needed to complete the job

2. Requirements

The most critical factor in any software project is to make sure the software meets the user and stakeholder expectations. It does not matter if the users are millions of people accessing a website or a couple of people you work closely with. Stakeholders are those who are funding you or can influence your funding and are just as important in the software process. Specifying the requirements for a software program and reviewing it with stakeholders can help ensure project success and may help your career.

The requirement are simply what the software will be required to do.

Main features
Platform (ArcGIS, operating system)
Performance requirements
Reliability (robustness)
Limitations

It can be just as important to specify what the software will not do as what it will do. Part of a developers role is to clarify what can be done with software and what cannot (or is not feasible within the schedule).

3. Use Cases

Use cases document how the software will be used. If you were creating a tool that provided information for the watershed behind a dam, the use cases might include:

Installing the tool
Determining the area of the watershed behind a particular dam
Running the tool with a DEM that does not overlap with the selected dam
Un-installing the tool
Updating the tool for a new version of ArcGIS

The first two were probably obvious but the rest may not have been. It's important at this phase of the project to make sure that you have a feel for everything the user will be doing that revolves around your software. If you miss something here, it could take a lot longer to build the software than you imagine.

Use cases are critical in that they scope the project and the provide the first inputs into the testing phase.

4. Feasibility Studies

Before committing to a schedule, it is important to make sure you can really do everything the tool promises. This may mean making sure a new algorithm performs as expected but it could also mean making sure a library works as promised (or does not crash Arc).

A good approach for feasibility studies is to make classes of the code you are creating. Then, when the implementation phase starts, you can just plug your new classes into the code base.

5. Requirements Document