We have a wealth of experience in developing long-term projects; EDISON specialists have carved out a reputation as a successful team that you can rely on to:
- Design software product architecture
- Develop technical solutions
- Elaborate requirements specification
- Design organisational charts and conduct business-process modeling
- Elaborate project documentation
- Correctly schedule work and deadlines
- Conduct risk management in software development
- Handle the management of permanent projects
- Carry out project recovery
Examples of requirements specifications, reports, briefs, instructions and concepts may be viewed below.
In layman’s terms, without going into the science of information technologies, requirements elaboration is necessary for written specification and formalization of users’ requirements so that the project is sure to be completed later. It is important to remember that 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 is more productive in practice, since it considers the opinions of both interested parties.
However, EDISON’sarchitects 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, 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.
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.
National standard foresees several stages of projecting, and specifies output artefacts at each stage. The most commonly known artefact is the requirements specification. The volume of the document almost always signifies the level of detail of the task description. EDISON specialists have worked with requirements specifications more than a thousand pages long; but one shouldn’t forget about rationality and sufficiency criteria: there is no sense in describing a one-day task on 20 pages. However, neither should it be squeezed into 1-2 pages of general “sketches”.