In last month's DataCore Up Close we presented the benefits and in fact, the need for planning an IT project. In this month's edition, we will discuss the importance of defining and recording requirements for an IT project and why experience in gathering requirements is necessary for the project to be successful.

Consider you were having a house built. You told the builders you wanted to have 4 bedrooms, 2 bathrooms, a half-sized basement, and a big kitchen with a double sink. So they start building the house ...and then you realized that you REALLY wanted to have a fireplace and oh, it'd be great to have a FULL basement for that home theater or work out area, and you didn't really need that double sink in the kitchen after all. So, the builder removes a wall for the fireplace, digs out more ground and pours cement for the bigger basement, and has to order a new sink, all of which adds weeks to the overall finish time and increases the cost of labor and materials.

What happened above is several things. First, the initial requirements established for the house were incomplete, ambiguous, and immeasurable. In addition, the requirements changed mid way through the project, (also known as scope creep – where the scope of the project increases) all of which led to prolonging the time taken to build the house and making the house more expensive.

The same is true of an IT project. If the requirements gathered up front are unambiguous, complete, and measurable, the project will be more likely to success than not, in terms of budget and timing. It is important, however, to select your builder, or software implementer, carefully. In the above scenario, a good builder would have inquired about things like the size of the rooms, type of heat, whether a fireplace was wanted and placement of the house on the lot. The builder would have asked all the right questions to obtain the necessary requirements for the house. As in construction, the implementation of an IT project necessitates experienced and skilled software engineers to ask the right questions during the requirements gathering process.

DataCore has significant experience in requirements gathering and recording, which helps keep the cost of your project within budget and timeframe. This requirements gathering is included in DataCore's Define Phase. The Define Phase describes and documents what is required. This phase analyzes the existing system and processes and identifies specific requirements for the proposed system. The Define Phase requires your input and feedback in what DataCore calls a requirements gathering meeting. This meeting usually includes representatives of all affected staff, for example:

• Management of the area seeking a solution - they will have specific business needs of the system.
• Users - they will be using the system regularly and will require different, more detailed functions than those at the management level.
• IT department - to help determine any system requirements that must be met and to ensure the hardware exists on which the solution must run.

During this meeting, DataCore asks questions about common requirements that may be needed as well as not so common system requirements. DataCore ensures that each requirement is specific, measurable, attainable, ranked, and traceable – all the attributes of a well-written requirement. Based on your responses and discussions that occur during this meeting, DataCore records the requirements in a System Requirements Specification (SRS) document. An SRS defines relevant business rules as well as user, system, and functional requirements. In an SRS, priorities are usually assigned to each requirement to determine its criticality in selecting a solution.

Based on the information included in the SRS, DataCore is able to write a Functional Specification (FS) document. In a Functional Specification (FS), you would see information on how the new system will meet the requirements listed in the SRS. This document includes inputs (information that must be entered into the system by a user) and outputs (information the system displays or reports based on the inputs) for each function, and may include user interface items (prototype screen shots, reports).

Once the documents are complete, the involved parties approve them, enabling the project to continue. DataCore and you use both the SRS and FS throughout the project as points of reference for designing (if applicable), configuring, and testing the system. These documents are also referenced when questions arise about what was agreed upon to be included in the system.

So, what happens if, during development, you find out that a needed requirement was not included in the requirements document? Depending on the impact the change will have on functionality and project schedule and cost, DataCore and you can include the function in the current phase of the project or wait until a later phase.

So you see, by simply writing down and agreeing to the requirements you have for a system, you will be able to better plan and budget for system development/configuration, testing, and implementation. Defining your business, system, and user requirements and finding an experienced implementer, such as DataCore, will decrease the amount of time and money expended on an IT project.

To learn about the Design Phase, click here to continue.