Often the starting point in establishing requirements is a careful analysis of the existing process that needs to be automated. So,

• we help our clients to fit the design to the way their business actually operates


• we guide them to tap the possibility of modifying their business process to take advantage of the way computers can handle their information


• we encourage them to remain flexible, and look for opportunities to streamline certain tasks, without forcing them into any specific procedures

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).

Given the fact that:

• the client has specific needs


• the project must be met within a specific time frame


• 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.

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.

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

• to see what the final product will actually look like


• to get a sense of how much data will fit on one window


• to know how that data will be organized


• 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.

• 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.

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

• that the original requirements have been met


• that the business rules embodied in the system are correct


• that the system works as a coherent whole.

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.

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.