For an accurate evaluation of a project's cost, its requirements specification should meet certain objectives. It should be absolutely clear. Having read the RS, the architect should have no unanswered questions as to the details of the described product. Of course, the architect will have a subjective perception, but nevertheless, the clients themselves often overlook very important issues when designing software or writing a requirements specification.
| 01 |  |
A requirements specification for software development should be written in such a way so that it can be added to the contract, and so that work can begin on it immediately. | ||
| 02 |  |
Information should be well structured. Solid bulks of text are difficult to read and analyze. | ||
| 03 |  |
The requirements specification should not contain contradictory data. | ||
| 04 |  |
The document should not include information that has nothing to do with the development of the system and does not shed light on one aspect or another of its functioning: footnotes, questions, colour markings, etc. | ||
| 05 |  |
There should be no abstract statements and general phrases: the more specific the better. | ||
| 06 |  |
The future system should be described in full. In the case of phased development the functionality of the corresponding phase should be described as thoroughly as possible. |
Examples
- If the system under development has equivalents, it would be useful to provide references to them.
- If the system presupposes integration with other systems or uses some other resources, they should be mentioned.
- While describing the purpose of the system, one should mention the main scenarios for how the users are going to use it.
- It is useful if the requirements specification is complemented by examples of input data and data format for the subsystems exchange: tables, databases, pages, etc.
- It also helps to provide examples of output data to the requirements specification: the appearance of reports, export files.
The structure of RS
- It is worth sketching the system's architecture (its skeleton) and also characterizing the interconnection between the subsystems.
- The requirements specification should describe the structure of the system: user interface, administrator interface, back-end, computational part, installer, auxiliary utilities, etc.
- Requirements specification for software development should include the following sections.
| 01 |  |
General information about the project. | ||
| 02 |  |
The purpose and goals of system development. | ||
| 03 |  |
Characteristics of the automation objects. | ||
| 04 |  |
General system requirements. | ||
| 05 |  |
Structure and content of the work to be done. | ||
| 06 |  |
The procedure of control and acceptance. | ||
| 07 |  |
Requirements on the structure and content of the work that must be done to prepare the automation object for the installation of the system. | ||
| 08 |  |
Requirements on the documentation, including the source code. |
Details
- Administrator interface should be thoroughly described.
- Expected user roles, their functions and rights should be carefully characterized.
- RS should contain descriptions of mathematical methods and models, typical algorithms and algorithms to be designed.
- Communications protocols to be used in the system should be listed in the requirements specification for software. For open protocols one should provide references to the specification of a particular version of the protocol. For private protocols their specification should be included in the text of requirements specification.
- The requirements on data safety and transfer should be stated. If it is necessary that the data be immune against a specific types of threat, this should be explicitly mentioned.
- All interfaces for interaction with other related systems should be described.
- It should be mentioned what payment systems need to be integrated with the software product under development.
- One should make an inventory of commercial and free components that are going to be used during the development.
Design
- When designer services are needed, it is necessary to offer a design concept.
- The document should contain requirements on the appearance of interface parts of the systemunder development. The design of interface blocks should be described.
- Sketches or ready-made layouts of all pages or forms of the application should be attached to the requirements specification.
- Web applications require a ready-made layout.
Efficiency and reliability
- For high-loaded systems the expected level of loading should be stated: what kind of workload the system should bear in routine mode: monthly, daily and at peak level.
- The productivity requirements that the system has to meet should be also specified.
- One should justify the equipment on which the system components are to be launched. It is necessary to state the location of server components: on a private server, on hosting or in a cloud.
- The requirements for data safety should be stated.
2002–2024