The first milestone in the creation of a product is software design. EDISON's specialists have completed hundreds of design tasks and have dealt with software requirements specifications that are thousands of pages long. We are comfortable working with both 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 the 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. |
Cooperative design
The beneficiary should be able to describe the benefit that he wants to achieve. Unfortunately, he doesn't always understand the subtleties of the task at hand, and thus, he cannot offer ways to solve the problem. A two-stage process is the most effective: first, the client states his requirements for what the software should look like; then, an engineer, guided by his experience, adds algorithms and other descriptions. This procedure, henceforth referred to as projecting, considers the opinions of both interested parties. However, EDISON's architects are able to design a program independently, relying on answers to specific questions.
Projecting should be carried out in written form, since the requirements specification will later be used by the team, consisting of an engineer, the client, a project manager, a tester, a 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 software architecture is always profitable, since it significantly reduces the number of problems encountered at future stages of work.
Technical specifications
The national standard oversees 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 using 20 pages to project a one-day task. Neither should it be squeezed into 1–2 pages of general ‘sketches’.
A requirements elaboration can be done by carefully writing down the text on paper, and also through special software, which uses different notations, such as a list of requirements, graphs, schemes, diagrams, and layouts. The result is materialized as a detailed and clear description of the inner algorithms of the software, in addition to a specification of the software's visible properties.
2002–2024