Often
the starting point in establishing requirements is a careful analysis of
the existing process that needs to be automated. So, (a) we help our
clients to fit the design to the way their business actually operates;
(b) we guide them to tap the possibility of modifying their business
process to take advantage of the way computers can handle their
information; (c) we encourage them to remain flexible, and look for
opportunities to streamline certain tasks, without forcing them into any
specific procedures.

Requirement Analysis:

As soon
as we embark on a project, our Systems Analysts would take account of
the “Situation Analysis” and the “Settings” in which a software or a
website is required. Their analysis refers to the task of understanding
the business problem at hand. Therefore, a discussion process starts
with the client’s representatives, leading to the actual “Requirement
Analysis”. What is to be developed is properly documented as “Software
Requirements and Specifications” (SRS).

Consolidation of SRS:

Given
the fact (a) that the client has specific needs; (b) the project must be
met within a specific time frame; and (c) the budget for any project is
“always” limited, we determine the “needs” for a minimal set of features
to be supported and ask the client to plug in the actual “wants” in
terms of their priorities. Working back and forth, the Project SRS gets
strengthen; features of an ideal system get established; and the
constraints of project time and budget are tacked. …..The success starts
peeing through the window.

Putting the Option on the Table:

Moving
through the process, the SRS often becomes too strong and “lucrative”
but the budget becomes a constraint……so we make it a point to split the
project into convenient phases with minimum project requirements
included in the First Phase. A large project, therefore, gets rolled out
successfully through multiple development cycles with “High Priority,
Mission-Critical Features” implemented in earlier phases. Once the SRS
has been established and prioritized, an initial timetable is
determined. …. The Project Development Team fastens its seatbelts and
the project takes off.

Validating the SRS Through Prototyping:

With our
experience for more than a decade now, we have found that prototyping is
a powerful tool for establishing the project requirements, particularly
user interface requirements. Therefore, depending on the complexity of
the project we often develop their prototype, in the first few days, to
allow the client (a) to see what the final product will actually look
like, (b) to get a sense of how much data will fit on one window; (c) to
know how that data will be organized, and (d) to visualize the steps
that will be required to perform specific tasks; and so on. By
delivering this dummy application that looks like the final product,
without any of the business logic built in, our Systems Analyst tries to
ensure that usability issues are addressed early in the development
process, while they're still easy to correct.

Seeking Continuous Participation From the Clients:

During “Requirements Gathering” to identify the business problem /
need at hand.

As
we work towards understanding the business process at hand, our
analysis is shared with the client for their concurrence.

The process of planning the solution to their problem is documented
and shared with the clients as a resource for the actual Project
Design.

The Project Design is disintegrated into the detailed specification of
each business module, window, and function within the system.

Establishing a detailed database design, or schema.

Performing a detailed design to allow changes to be made.

Streamlining the foundation for the technical documentation of the
system.

Writing a blueprint to guide the development phase.

Determining a firm timetable for project delivery.

Specifying the different parts of the system, and how they
interrelate.

Decisions-making re hardware and operating systems, as well as what
software tools will be used.

Establishing User interface standards based on the prototype discussed
above, so that every window has a consistent 'look-and-feel' in its
presentation, and is consequently easier to use.

The software testing process is done in close coordination with the
eventual users of the system. This is another reason why it's
important to have the participation of the end user in gathering the
project requirements.

Development:

It
usually comprises the majority of the project life cycle, taking the
design established in the previous phase and actually writing the codes
for the desired application. As mentioned earlier, often the system is
built in multiple phases so that critical functionality can be deployed
as early as possible. The bulk of the “testing” actually
occurs during the development phase. “Unit testing” is targeted to make
sure that the individual components of the system work well, both
separately and in conjunction with other parts of the system. “System
testing is targeted to make sure (a) that the original requirements have
been met,; (b) that the business rules embodied in the system are
correct; and (c) that the system works as a coherent whole.

Documentation:

We make
it a point to produce appropriate “Documentation” of the projects,
technical documentation serving as a guide for future developers to make
changes to a system months or even years later. It also helps us in
training client’s s taff in the use of the system. We support our
clients with software documentation different forms, from printed
manuals to online help files.

Deployment:

This is
where it all comes together. Hardware is installed, and the network
configuration is established. Depending on the design of the system,
database, application, and web servers are installed on dedicated server
machines. Existing data, if any, is converted to the new system. The
finished application is then installed, and final testing is done to
make sure that all of the pieces of the system are working correctly in
concert with one another.