Software requirements specification (SRS)

The first milestone in the creation of a product is software design. EDISON specialists have accomplished hundreds of design tasks and dealt with software requirements specifications thousands of pages long. We are equally comfortable working in English and Russian. Examples of requirements specifications, reports, briefs, instructions and concepts may be viewed below.

Writing a software requirements specification
01 Design architecture We create the software architecture.
02 Technical solution We write a software requirements specification (SRS).
03 Business-processes We model business processes and draw organisational charts.
04 Interface We design the interface.
05 Schedule work We create a development schedule.
06 Assess the risks We evaluate the risks and save the project.

Cooperative designing

The beneficiary describes the benefit that he wants to achieve. As a rule he doesn't understand the subtleties of the task, thus he cannot offer ways to solve the problem. A two-stage process is most effective: first the client states his requirements for what the software should look like then an engineer, guided by his experience, adds algorithmic and other descriptions. This projecting procedure considers the opinions of both interested parties. However, EDISON's architects are able to design a program independently, relying on answers to specific questions.

An exclamation mark

Projecting should be carried out in written form, since the requirements specification will later be used by the team, consisting of an engineer, client, project manager, tester, designer, etc.

In every case we believe that projecting is worth paying for. First of all, this job is carried out by the most experienced specialists in the company, who no longer make the mistakes that trainees make. Secondly, investing in the architecture of software is always profitable, since it significantly reduces the number of problems encountered at future stages of work.

Technical specification

National standard foresees several stages of projecting, and specifies output artefacts at each stage. The volume of the document almost always signifies the level of detail of the task description. There is no sense in describing a one-day task on 20 pages. Neither should it be squeezed into 1–2 pages of general “sketches”.

Requirements elaboration can be done by actually writing a text down on paper, and also by special software means using different notations: lists of requirements, graphs, schemes, diagrams, layouts. The result is materialized in: a detailed and clear description of the inner algorithms of the software product; specification of software's visible properties.