Development Tasks, Part 1

See Software Development Process and Development Methodology for the context
of this topic.

Vision Statement

A vision statement sets the goals for the project. It puts forward an idea
for others to consider. It will usually outline the problems that need to be
addressed and suggest some sort of solution.

The vision statement remains an important document for the life of the project.
It should be the first document that is read when wanting to understand what a
project is all about.

A vision statement can also help to keep a project constrained to its original
goals and help prevent scope creep.

Preliminary Analysis

This task elaborates and clarifies the client’s statement of need. It allows the
client to tell if the analyst has really understood the problem.

Discuss with the domain experts and do research into similar problems.
Investigate the implications of the requirements.

From the article "Making a success of preliminary analysis using UML"

“It is necessary to define the application domains on which a system is to be put in place, and the processes that the system must support. Terminology, definitions and domain boundaries are clarified, in order to explain the problem in a clear context. In this domain, functioning modes must be explained, in the form of business procedures, but also in the form of rules and business constraints."

One of the outputs of the preliminary analysis task is the first draft of the
project data dictionary or glossary.

Feasibility Study

The primary purpose of a feasibility study is to demonstrate that there is at
least one viable solution to the problem. For a solution to be viable it will
need to be realizable with the resources available and technically possible to
implement.

A feasibility study should concentrate on the technically novel components
of the system. There is no point in re-examining things which are readily
available such as web servers or databases.

It is not necessary for the study to produce the best solution, just one
which satisfies the minimum requirements, or which demonstrates that with
more development effort a satisfactory solution should be possible.

Modelling

This task applies when there is some existing system that is being replaced.
The existing system might be automated, or entirely manual paper based, but
either way it is important to document what it does before we try to reproduce
it.

From the article "Making a success of preliminary analysis using UML"

"An analysis of what already exists must be carried out, by representing it as a system whose structure, roles, responsibilities and internal and external information exchanges are shown. All preliminary information must be collected, in the form of documents, models, forms or any other representation. The nature of the products developed by the processes is explained.”

Requirements Gathering

This task involves creating a formal list of things that the proposed system
must accomplish. The list should have a well defined numbering system so that
requirements can be unambiguously referred to for the remainder of the project,
and beyond into the maintenance phase.

The functional requirements list what the system is supposed to do. These are
usually the things that most interest the users of the system.

The environmental requirements describe the environment in which the system
must operate. For example the system might have to operate using Windows
based computers, or it might have to operate in an aeroplane.

The quality (or non-functional) requirements will drive the architecture of the
system. Obtain the limits on the performance (speed and size), security, safety,
and resource usage (disk, memory, band-width). Determine the availability
requirements, how modifiable the system must be, the ease with which it can be built
and tested. Consider how soon the product must be delivered. Usability is often
an important requirement. This needs to be considered for the various users of
the system, from the occasional user to the “power” user. Describe what
is required to administer the system.

Deliverables

At this stage of the project you should have use case descriptions describing
how users will interact with the system, a list of the main actors and objects,
detailed interface formats for external systems (and memorandums of understanding
with the owners of those systems) and an initial idea of the increment plan.


This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.