Communication is key to success in software development. Clear and well-communicated requirements help development teams to create the product requested.
When faced with requirements defined at a high level, agile methodologies can clarify and verify them sprint by sprint in an iterative way.
According to the IEEE (Institute of Electrical and Electronics Engineers) standard glossary of software engineering terminology, requirement is:
- A condition or capability that a user needs to solve a problem or achieve a goal.
- A condition or capability that must be achieved or possessed by a system or component of a system to satisfy a contract, standard, or other formally imposed document.
- A document representation of a condition or capability as expressed in 1 or 2.
The main advantages of having good requirements specification are:
- It helps to ensure that all stakeholders have a common understanding of the system to be developed. This avoids any misunderstandings during the later stages of development.
- It serves as a reference point for all stakeholders during the development process.
- It helps to identify any gaps in requirements at an early stage.
- Reduces overall cost and development time by avoiding rework due to changes in requirements.
From the quality and testing area, the first step in understanding what we need to test is to read the documents detailing the product requirements, which set out the System Under Test (SUT). These include:
The Business Requirement Specification or Business Requirements Specification (BRS).
It contains information about the business and details about the processes to be implemented in the software and whether new functionality is required. It is a formal document, created by a business analyst, that details the requirements provided by the customer. It defines their needs. This document is used from the beginning to the end of the project.
In general, BRS contains the maximum number of concurrent users that will use the system, the types of users, the computer skills, the problems the users are currently facing. It also provides a description of the current system and possible future expansions.
The BRS also describes the deliverables or what the customer expects and describes the level of reliability expected for the software.
The BRS should not be written using overly technical terms.
The Software Requirements Specification (SRS).
An SRS is a document that provides a complete description of the behaviour of the future software or product to be developed. It is created by a systems analyst, systems architect or business analyst. It describes how the business works when the software or application is used. In this document the specifications are described in a more technical or formal way.
The Functional Requirements Specification (FRS).
The functional requirements of a system are those that describe any activity that the system must perform, i.e. the particular behaviour or function of a system or software when certain conditions are met.
Functional requirements begin by describing the required functionality as essential to the application. Functional requirements focus on end-user functionality, not on internal logic.
All these documents mentioned above help to identify what we have to test, how we have to test it and what we need to test it.
SIPSA's quality and testing teams work to achieve the highest levels of software quality, focusing on the definition of test cases from the earliest stages of the product lifecycle.
Contact us here to request more information on how we can help you in the definition and execution of the quality plan of your IT projects.
Top comments (0)