Within IT projects execution, the meaning of clearly defined requirements is substantial. It is also worth knowing how great the risk is when the requirements are wrongly defined. In our company, the process of requirement analysis is treated as exceptionally important and we put a huge emphasis on it. During the many years of our work we created many requirement specifications for the applications we developed and we constantly polished our techniques.
Some of the specifications we created were 200 pages long and were the point of reference in projects running for over a year, by teamsconsisting of several dozen people. To prepare the requirement analysis we used our verified templates and prototyping techniques, which allow for effective and precise definition of the system being created.
Requirement specifications can be one of the phases of our projects or an individual service.
REQUIREMENT ANALYSIS (PRE-IMPLEMENTATION ANALYSIS)
Our analysts, on the basis of provided documents defining the Business Requirements Specifications, will develop detailed Software Requirements Specifications. As consultants they can also assist you in the earliest phase of creating the Business Requirement Specifications.During the last few years, we created many Software Requirements Specifications. Some of them were
200 pages long and described dozens of functionalities and processes required by business.
The requirements described by our company usually comprise attachments to agreements for development and implementation of software. Requirements specifications documents are usually self-contained products.
We developed SRS as self-contained projects and as parts of bigger projects (we partook in further phases: implementation, maintenance).The following diagram clearly depicts the process of SRS document development before commencement of a project.
Process of requirements tracing begins with Business Requirements Specification. This is the description of a company’s business objectives, which are to be met using the developed software. Such a document is drawn up from the perspective of business and only contains general requirements, which are to be met by the new system. It is usually created by the Client before project commencement.
If such need arises (in case of bigger projects), our analysts will prepare Vision Document on the basis of BRS document. This is a concise document which initializes the project.
- Business requirements
- project’s business context,
- business objectives,
- project success criteria,
- user needs,
- business risks,
- Solution vision
- general system description,
- list of its characteristics,
- assumptions and dependencies
- Scope and limitation
- scope of functionalities in separate versions
- description of what the system will not contain
- Business contest
- description of all stakeholders in the project
- description of project priorities
After acceptance of the document by all project participants, transition to phase of tracing user requirements occurs. This is usually done by a series of meetings- workshops/interviews, during which all subsequent system functionalities are analyzed, which are ascribed to the business process.
During these workshops, analysts develop use cases or user histories. Such documents describe in detail the process of user interaction with the application (and possible interactions between systems). Sometimes user interface models (prototypes) are drawn up as images of forms. Such image sometimes gives a better idea about system behavior. It also allows for improvement of user interface ergonomic.
While designing user interfaces, we follow our usefulness principles and principles of reasonable access to data, in orderto find the compromise between user requirements and system load. Together with user requirements, other requirements are traced, including non-functional requirements (e.g. specification of application availability level, time of data storage in the database.) All requirements are collected together in the final Software Requirements Specification document.
Its template contains, among others:
- Introduction
- document purpose
- document convention
- for whom the document is
- scope of project
- references to other documents
- general description of the project
- Product perspective
- product characteristics
- user classes and their characteristics
- operation environment in which the product will function
- requirements regarding concept and implementation
- requirements regarding user documentation
- assumptions and dependencies
- System functionalities
- detailed description of each system functionality (among others use cases application)
- requirements regarding interfaces
- user interface
- user interface requirements
- non-functional requirements
- efficiency requirements Other requirements
ICT4D 3.0 Framework how to build ICT services in low resource environments using a collaborative, adaptive, iterative approach