Requirements and specification

In order to solve the customer’s problems, you must first understand the problems, the customer’s business environment, and the available technology which can be used to solve the problems. Once you have done this, you can meet with the customers and users to decide on a course of action that will solve the problems. If you decide that developing or modifying software is the best course of action, then you can decide in detail what facilities the software should provide.

This overall process may include the following activities.

 Domain analysis: understanding the background needed so as to be able to understand the problem and make intelligent decisions.

 Defining the problem: narrowing down the scope of the system by determining the precise problem that needs solving.

Requirements gathering: obtaining all the ideas people have about what the software should do.

   Requirements analysis: organizing the information that has been gathered, and making decisions about what in fact the software should do. The term ‘requirements analysis’ is often used more broadly to include some of the other steps in this list.

  Requirements specification: writing a precise set of instructions that define what the software should do. These instructions should describe how the software behaves from the perspective of the user, but should not describe any details of the implementation.

One of the most important principles of requirements is to separate the ‘what’ from the ‘how’. The ‘what’ refers to the requirements – what is needed to solve the problem. The ‘how’ refers to how the solution will be designed and implemented.

Although initial requirements should be established early in a project, the customers’ needs tend to change. Requirements analysis therefore should be continued throughout the life of a software system.