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.
|01||We create the software architecture.|
|02||We write a software requirements specification (SRS).|
|03||We model business processes and draw organisational charts.|
|04||We design the interface.|
|05||We create a development schedule.|
|06||We evaluate the risks and save the project.|
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.
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.
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.