Best Practices

Don’t give me best practices, they are yesterday’s news.

Give me emerging practices, they are tomorrow’s news.

What “Requirements Gathering” is all about is info transferring and sharing. The “Requirements” document can be considered as the real project contract between the user and the developer, and it is also the first draft of the project plan.

In brief:

The Requirements Document is
the Business coded version of
the User’s Specifications written using
the Human Programming Language!

To approach this description, there are some advised best practices to make sure that the user’s business requirements will be smoothly translated into the “required” program. Among these best practices are some suggested tips to be taken into consideration while producing the requirements artifact be it a document, a prototype, a list of features… using the aid of whichever techniques of the previously mentioned ones.

The requirements should include the following:

Approvals

The “Approvals” section is the first step determining stakeholders even if they don’t participate in the requirements gathering exercise. Approvals list includes the stakeholders names, their titles and their signatures.

Objectives

The “Objectives” section also known as the “Problem Statement” section gives the reader of the document a brief idea about the purpose of the project and the needed system. It gives an overview about the system and may describe the background of the problem and the impact of implementing the requirements.

Scope

The “Scope” section clearly states what should be covered by the proposed solution and what will not covered. It determines the “In Scope” and “Out of Scope” requirements.

Business Goals

The “Business Goals” section helps developer and business stakeholders understanding the goal of the project and sharing the same view.

Assumptions

As requirements gathering and analysis is an intermediate step between the business requirements and the to-be developed system, it is very important to ensure that all stakeholders and developers have a common understanding. As humans, this is almost impossible to achieve, at which point the importance of the “Assumptions” section emerges, it helps all stakeholders viewing, as much as possible, the requirements from the same viewpoint. Assumptions may include business, technical and planning assumptions.

Constraints & Risks

The “Constraints & Risks” section helps identifying problems facing the product implementation at early stages, thus facilitating decision making and project planning. Constraints and risks may be business and/or technical.

Pre-requisites

In the “Pre-requisites” section you can define any dependencies the project will be rely on and will not be launched unless they exist.

References

The “References” section refers to other helper systems or documentation.

System Actors/Users

In the “System Actors/Users” section, we define the users who will have access to the system with a brief description about their roles.

As an example, we can use a table to represent actors and their roles:

User/Actor	Role	Comments
Student	Review schedule

Functionality

Then comes the “Functionality” section in which each of the roles/functions is described clearly. As a best practice, you can give a little description about the functionality, the expected fields to be manipulated and the actions to be performed to achieve the required function.

Example:

After logging in to the system, the student should be able to review the schedule by viewing the list of subjects, dates and time. Fields to be accessed by the student can be:

Actions to be performed by the student are:

GUI Requirements

The “GUI Requirements” section headlines the user needs for the GUI. It can describe the look and feel, include some screen shots or refer to the prototype.

Non-functional Requirements

The “Non-functional Requirements” section includes the user’s requirements regarding hardware and software requirement of an application. It also talks about application performance, number of normal and concurrent users, page response time. They address business risk.

Non-functional requirements are properties the product/project must have, such as the desired look and feel, usability, performance, cultural aspects, availability, reliability, maintainability, extensibility, security and so on.

Questionnaires

It is also healthy to use questionnaires. Questionnaires help getting quick and precise answers to vague requirements. A proposed template is:

Signoff

Signoff is the final and most important step in the requirements gathering process. By signoff, the requirements should be freezed and later request for changes should be treated separately. Before signoff, it is a good practice to take a second opinion about the requirements, it is preferable to involve technical opinion in the requirements to ensure their feasibility before finalizing the agreement with the customer. To ensure the effectiveness of the requirements, it is better to review them with the customer before the signoff process.