Requirements

To develop software projects on time and budget there is nothing more important than gathering and clearly defining the requirements. In defining requirements, you are not specifying how the software will be built, but exactly what you need your software to do.

There are a few important principles in defining software requirements:

1. A software development project without agreed-upon requirements will always fail.
2. Software with loose or ill-defined requirements will be produced late and over budget.
3. Software that has well-defined and agreed-upon requirements has a high chance of success.

There are several bad excuses for initiating development with poorly defined requirements, but there none of them are acceptable. Clear requirements are so important that Global will not undertake development unless the requirements are precisely defined.

To define requirements, we work closely with your team to determine:

• Functionality: the essential things that the system must do.
• Interaction: how the system should work from the user's point of view.
• Other Needs: time, space, performance, scalability, security, and disaster recovery needs.

To gather requirements, we study the functionality provided by any existing system to be replaced, interview users, and conduct CRC (Class Responsibility Collaboration) card-based brainstorming, role plays, and analysis.

After we have explored and analyzed the requirements, we articulate the requirements in the form of Software Requirements Definition. Requirements Definition is a living contract between your users and us. It provides a common vocabulary and understanding of the problem space and the desired system behavior.

A Requirements Definition is not a single document. It is a collection of four specifications:

1. An introductory description and domain model that sets the context for the system to be built.
2. A list of requirement statements. Each statement is numbered and is a precise refutable notation of a specific requirement.
3. Use-case diagrams and descriptions using the Unified Modeling Language (UML) to capture typical interactions between a user and the system. Although the list of requirements is precise, most users have a tendency to not read it because it is not intuitive to them.
4. Use-cases put the requirements in the form of interactions in a familiar context.
5. Use-cases are, therefore, a better way to capture the users' expectations. Prototypes, if necessary, to further explain complex interactions.

Requirements are bound to change during the course of your project. Unmanaged changes, however, can be harmful to the project. They can cause delays, increase cost, decrease quality, or outright kill the project. That is why we manage your requirements very conservatively. We store requirements in a controlled database and negotiate every change-request to ensure that additional project risks brought in by the change-request are justified.

Only with rigorous requirements definition and management will you be able to finish your project on time and on budget. If you are about to start a project and are looking for assistance, give us a call. Whether you're looking for a full Requirements Definition, or you simply want some free advice over the phone, we will be happy to assist you.