Review of requirements

Our analysts put together the set of documents necessary to start the development process to understand how should your system perform and look like.

List of documents we produce when analyzing requirements

Business Vision

First of all, we conduct a preliminary interview with our customer, determining the purpose of system creation, its boundaries and its place in the real world. It’s sometimes called Business Vision.

Business Requirements Document / BRD

This is followed by the series of refining interviews where the customer enhances his ideas. We detail and deepen our understanding of tasks the system should achieve. The resulting document is Business Requirements Document (BRD).

Functional Requirements Document / FRD

At this phase we conduct careful analysis of business requirements. We’re searching for logical conflicts, detailing system’s requirements to the level understandable to developers.

We call this document that contains the functional requirements – Functional Requirements Document (FRD). Also it’s often called as Technical Specification (TS). TS is our main document, it’s the basis for the future system. The document usually contains:

— General list of the system components

— Detailed descriptions of each component’s functions

— Use cases

— Non-functional requirements: special hardware requirements, system performance requirements and maximal load requirements.

Test Plan

Test plan is a necessary for test team and it’s compiled on the basis of FRD and other related documents (design samples, server APIs, etc.). The goal of this document is to answer three main questions: what, how and when should be tested, in other words:

— Which components of the system should be tested

— What kinds of tests should be conducted and how

— In which order should it be performed

There is list of test scenarios combined with the test plan. Every test scenario contains necessary detalization for the test completion. This enables us to conduct the entire set of tests at any point again.

Risk List

There is also additional document frequently made together with FRD, it’s the Risk List. This document takes into account the major risks that could affect the development of the system in appropriate time; it points out how to react at any given risk. The Risk List contains the answers for many «What would happen if? » questions, includes the most pessimistic scenarios of the system’s development and implementation. This document, being internal, could be interesting for the customer too.

Why is it neсessary?

The work of analysts costs money. And why does the customer need this? BRD enables us to make a primary cost estimation of the project and to identify schedule risks. FRD enables us to
make the exact cost estimation of the project and to emphasize technical risks. FRD also is the cornerstone for the system’ testing and for resolving of all disputable questions between the customer and us. That’s why FRD is written in the most exact and formal phrases – first of all it’s made to avoid an ambiguous interpretation.

The list of prepared documents strongly depends on the scale of a project. For example, the business requirements for small projects could be written in a several sentences, FRD could be based on the results of the first interview.