A web application, a mobile app, a website, SaaS software, or virtually any digital product, regardless of its level of complexity, cannot be created in the set:
- form and usability
without a thoroughly and comprehensively prepared Requirements Specification.
What is a Software Requirements Specification?
A specification is a document that collects all the functional and non-functional expectations of a future system (e.g., functional and non-functional requirements of an application).
A standard document of this kind contains:
- product name
- names of its authors
- version of a document
- history of changes – usually presented in a form of a table
- table of contents
- a section on the characteristics of a company (its needs, business problems)
- description of the future/current system that a company wants or already uses
- dictionary of terms used in a document
- description of a business model (including in particular stakeholders, rules, and business processes)
- description of functional requirements
- description of non-functional requirements
- list of requirements (including prioritization and description of use cases)
- system model.
The Requirements Specification covers, on the one hand, the business utility of a system, on the other hand, it organizes information regarding the scope of work, the time of their execution, methods, and distinguished stages (Statement of Work).
The Software Requirements Specification describes all possible interactions that will occur between users (external and internal administrators) and a system.
It provides knowledge of purposes that a web application allows you to achieve, the means of achieving them, the conditions necessary to achieve them, and the exceptions it does not apply to.
The Requirements Specification is not only technical documentation (specification of functional requirements), in the full sense of the word, but also is a document that allows to:
- quote a project (it is especially useful in the Fixed Price billing model)
- specify execution time
- divide a project into stages (Sprints)
- define a team of specialists necessary for its implementation
- select appropriate technologies
- plan possible integrations
- adapt a product to current standards
- allows developers to understand what the system is supposed to be used for and how it is supposed to work (e.g., use cases).
Preparation for creating Requirements Specification
It is time-consuming and work-intensive to take into account all the requirements that are placed on the system.
However, it definitely translates into the speed and quality of digital product creation. It prevents unnecessary errors and reduces the number of revisions and changes.
It is therefore worth taking the time to prepare exhaustive answers to the most common questions:
- Is a solution to be created from scratch, or is it to be a development of an existing system?
- Does a website or application have to be created with a Design System in mind?
- What is the main business objective?
- What is the scope of production work, and what will be the scope of service related to system maintenance and development?
- What will be the main benefits for the company and future users of the system?
- What functions and modules must it have, should it have, or may have?
- What work and to what extent will be performed by a principal or other contractors?
- On what devices, on what operating systems, and in what environment will the system ultimately run?
- To what extent is it intended to be a typical system (similar to existing ones), and to what extent is it meant to offer additional functionalities?
- What analytical tools will a company use to track user behavior?
- With which external systems will it be integrated?
Exhaustive definition of:
- tasks that a digital product will perform
- benefits it will allow to achieve
- means of their execution and accomplishment
translate directly into the satisfaction of system owners and its users.
Requirements Specification specialists
Several specialists are usually responsible for the creation of the Requirements Specification, while the content of the document should be consulted with employees of all departments during its creation.
A Business Analyst is responsible for translating business goals into the language of programming requirements. The result of his work is to answer the question “What is to be done?”. It is the responsibility of a System Architect to answer the question “How it is to be done?” and determine its structure and how it is to be implemented.
The development team, having such a framework in place, is able to supplement it with specific proposals for technical solutions.
An equally important role is played by the UX designer, which indicates the requirements for usability and ergonomics of the system. Very useful tools in creating Functional Specifications are Business Model Canvas and User Stories.
A method for making more concrete requirements is to write them in the form of sentences stating a possibility (e.g., I have the ability to create an account, I can watch videos).
Sentences can be formalized into a formula: I/role – I can/function statement – press, select /action statement – in order to/result statement.
Requirements Specification in the SMART formula
Each requirement (functional and non-functional) should be specified and expressed in a:
- simple/specific manner
- measurable manner (through standard metrics)
- achivable manner (achievable within a given time, with the commitment of available resources)
- relevant manner (adequate to function and purpose)
- traceable manner (possible to control).
In addition, each requirement should be easily identifiable through its attributes:
- alphanumeric identifier
- category of requirements to which it belongs
- priority (usually of three levels: very important, important, unimportant).
Business and functional requirements
The created website, web application, or mobile app must provide equivalent value to its users and owners. It should allow to achive common goals.
At the same time, it is worth noting that functional requirements, as opposed to business requirements, are achieved when the work is completed.
Business goals can be measured by different indicators and achieved over different time frames.
Business Rules - Non-Functional Requirements
An extremely important matter that must also be included in the Requirements Specification is Business Rules.
They are constituted by standards (formal and informal, habitual), which are different in each industry, and which regulate the internal and external operation of the company.
These standards have their source in:
- statutory law (regulations on the conduct of the particular business activity, e.g., food production, management of a doctor's office)
- internal regulations of a company (e.g., regarding the bank's conditions and terms for granting credit)
- regulations and recommendations of industry organizations to which a company belongs (e.g., IAB Poland)
- industry Codes of Ethics (e.g., the code of ethics for psychotherapists of the Polish Psychiatric Association)
- industry Codes of Good Practice, regulating what actions are worthy of emulation and what should be considered harmful (although not against the law).
Business Rules are limitations, a framework within which a company operates, and are an important source that defines software requirements (e.g., non-functional requirements for a web application).
The purpose of collecting them is to check any inconsistencies between them and the Requirements contained in the Requirements Specification.