Our Process
Requirements Specification
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:
- deadline
- budget
- 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 the following:
- product name
- names of its authors
- version of a document
- history of changes – usually presented in the 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.
It also clarifies expectations regarding security, data protection, and terms of use (system requirements).
The Requirements Specification is not only technical documentation (specification of functional requirements), in the complete 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 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 detailed 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 a principal or other contractors perform?
- On what devices, 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 creating the Requirements Specification, while the document's content 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.
With such a framework in place, the development team can supplement it with specific proposals for technical solutions.
The UX designer plays an equally important role, indicating the requirements for the usability and ergonomics of the system. Business Model Canvas and User Stories are useful tools for creating Functional Specifications.
A method for making more concrete requirements is to write them in the form of sentences stating a possibility (e.g., I can 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)
- achievable 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
- definitions
- 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 make it possible to achieve 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 various time frames.
Business Rules - Non-Functional Requirements
A fundamental 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 essential source that defines software requirements (e.g., non-functional requirements for a web application).
The purpose of collecting them is to check for inconsistencies between them and the Requirements contained in the Requirements Specification.