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, can't be created in the set:
- Deadline
- Budget
- Form and usability
without a thoroughly and comprehensively prepared software requirements specification.
What is a software requirements specification?
A specification is a document that collects all the functional, non-functional, system, and external interface requirements of a future system (e.g., functional and non-functional requirements of an application).
It's a tool that can significantly simplify and speed up the work of project managers, product managers, and business analysts. It improves cost, time, and risk management.
A standard software requirements specification document contains the following:
- Product name
- Names of authors
- The version of the 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 software requirements specification covers a system's business utility; it organizes information regarding the scope of work, the time of execution, methods, and distinguished stages (statement of work).
The software requirements specification describes all possible user interactions (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 its exceptions.
It also clarifies expectations regarding security, data protection, and terms of use (system requirements).
The software requirements specification is not only technical documentation (specification of functional requirements) but also a document that allows you to:
- Quote a project (it is especially useful in the fixed price billing model)
- Specify execution time
- Divide a project and development process into stages (sprints)
- Define a team of specialists necessary for its implementation
- Select appropriate technologies
- Plan possible integrations
- Adapt a software product to current standards
- Improve project management processes
- Understand what the system is supposed to be used for and how it is supposed to work (e.g., use cases).
Create Requirements Specification!
Types of software requirements specifications
Software requirement specification (SRS)
The SRS document collects all the requirements related to the system and its functions. It defines conditions that need to be met for the successful development of software. It encompasses aspects such as functional and non-functional features, performance, scalability, etc.
Functional requirement specification (FRS)
Functional project requirements include all product aspects connected to the functions that a system will need to perform. It contains descriptions of features, security measures, user flows, user interface behaviors, and more. Thanks to this document, developers know precisely how the system should behave.
Performance requirement specification (PRS)
As the name suggests, the performance requirement specification describes requirements related to a product's performance. It covers efficiency, scalability, response time, loading time, and other areas for improvement. This specification also enables you to define all the areas for improvement.
Business requirements specification (BRS)
Business requirements include everything that is essential from the business perspective. These requirements should align with your business goals and user needs. It collects requirements regarding project scope, usability, and product goals. In other words, you can write down everything that directly influences business processes.
Preparation for creating software requirements specification
It's 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.
You should prepare detailed answers to the most common questions:
- Do you want to create a solution from scratch or develop it from 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 the service scope be related to system maintenance and development?
- What will be the main benefits for the company and future users of the system?
- What system features and modules must it have, should it have, or may have?
- What work will the commissioning party or other contractors perform, and to what extent?
- On what devices, operating systems, and in what environment will the system ultimately run?
- To what extent is it supposed 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?
- Which external systems will it be integrated into?
An exhaustive definition of the:
- Tasks that a digital product will perform
- Benefits that a product will allow you to achieve
- Means of task execution and goal accomplishment
Translate directly to the satisfaction of system owners and its users.
Software 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 their work is to answer the question, "What is to be done?". It's the responsibility of a system architect to answer the question "How is it to be done?" and determine the system structure and how to implement it.
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 system's usability and ergonomics. Business model canvas and user stories are useful tools for creating functional software requirement 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 — to/result statement.
Software requirements specification in the SMART formula
Each requirement (functional and non-functional) should be specified and expressed in a way that is:
- Simple/specific
- Measurable (through standard metrics)
- Achievable (achievable within a given time, with the commitment of available resources)
- Relevant (adequate to function and purpose)
- Traceable (possible to control).
Each requirement should be easily identifiable through the following 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's worth noting that functional requirements, as opposed to business requirements, are achieved when the work is completed.
Business goals can be measured by different metrics and achieved over various time frames.
Business rules: Non-functional requirements
A fundamental matter that must also be included in the system requirements specification is business rules.
They consist of standards (formal and informal, habitual) that are different in each industry and regulate the company's internal and external operations.
Standards of business rules have their source in:
- Statutory law (regulations on the conduct of a 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 regulate 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 an essential source for defining 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.