The "how" of software development
Specifications
The requirements for a software can be compared to the sales prospectus of a house. From the customer’s requirements, the software developer creates the functional specification. Similar to the architect’s technical drawing and the building description, it describes how the software is to be created. In addition to technical aspects, the appearance of the software plays an overriding role here.
While the requirement profile contains the scope of services of a software to be developed individually, the requirement specification describes how the software is to be created. “Requirements specification” and “realization concept” are terms to be used synonymously in this connection. Both documents describe the technical implementation of the software.
Non-functional properties
A functional specification usually starts with non-functional properties of the software. These are boundary conditions that do not directly affect the functions of the software. Some examples are as follows:
- Purpose of the application
- Hardware and software requirements
- Development environment and programming language
- Quantity structure
- Screen resolution
- Languages
- Supported web browsers
- Documentation and help system
- Glossary
Functional properties
The functional properties describe the scope of performance of the software. This includes first of all the structure of the software consisting of:
- Software architecture
- Graphic design
- Colors and fonts
- Input and display elements of the user interface
- Menu structure
This rather general part is followed by the concrete details. Almost every software requires a user login. Here, the specifications describe how the user logs on to the software, what happens in the event of incorrect logons, and what roles and rights the software distinguishes.
All other program functions depend on the specific use case. For example, if there are customers in the software, then a separate chapter will cover the following topics:
- Displaying a customer list.
- Adding customers.
- Editing customers.
- Deleting customers.
For each of the topics, the functional specification will describe the following functional requirements:
Wireframe or mockup showing a view of the web page or form to display and edit the data.
Data origin description. This is a description of how the displayed input and display elements of the interface are connected to data fields and tables in the database.
Description of validation rules. The validation rules are validity checks that are performed when data is entered and edited. Saving the data is usually possible only when all validity rules are fulfilled.
For example, if a table or list is displayed, then the specification contains the columns to be displayed in the list, the sort order, and the options for filtering the list (search).
As a rule, the specification also contains a description of the interfaces of the software to be created as well as the reports and evaluations to be output. Special attention is paid to the database model. It contains all database tables and fields in which the software can store information. This also includes the relational links between the database tables.
Use of the specifications
The requirements specification becomes part of the contract between the customer and the software developer. It must therefore be checked for completeness and accepted by the customer. If corrections are required, these must be incorporated into the requirements specification. The finished and accepted requirement specification serves as basis for the calculation of the expenditure for the production of the software. When the software is accepted, all the program functions described in the requirements specification must be demonstrated in the software by the software developer.