In the beginning was the Word… This well-known statement can also be applied to software development and testing. The work on any project always starts from writing requirements which serve as a backbone for both development and testing processes. Developers use requirements to understand what features and in which way to realize whereas QA engineers are guided by requirements to reveal the way an application should work and design corresponding test cases. But before using requirements it is crucial to test them as well. Requirement testing is considered to be indeed good practice helping to avoid a lot of problems in the future.
What are Software Requirements?
Software requirements can be defined as a set of statements describing what and in which way an application should or should not do under particular conditions. In other words, it is a scope of app capabilities and characteristics.
Why requirements are so important and why is it worth spending time on their composition, analysis, and testing? Here are some of the main reasons:
All in all, software requirements make software development and testing simpler and help avoid different misunderstandings. Requirements can be compared with a lighthouse or a guiding star as they similarly show the whole project team the way to go. Still, to be helpful, requirements should be appropriately compiled, carefully tested, and timely updated if needed.
Why Test Requirements?
As a rule, software requirements are written by various stakeholders and from different perspectives - business perspective, end-user perspective, and technical perspective. Consequently, such requirements are heavily exposed to human errors. Unfortunately, more than often software requirements contain gaps, contradictions, ambiguities, etc. This can result in the procrastination of project development and the appearance of numerous bugs in an application. Therefore, there is a need to involve a QA team in the work on a project as soon as requirements are available. QA specialists should proofread requirements in order to detect errors from the outset before a development process starts. The thing is that it is much easier and quicker to analyze and check requirements for errors than later review hundreds or even thousands of code lines to fix a bug. Moreover, it is always cheaper to detect and eliminate a bug at the phase of requirement development than at the later phases of the software development life cycle.
Types of Software Requirements
As it was said, software requirements are written considering business needs, end-users' needs, and technical needs. Consequently, corresponding types of requirements are differentiated. So, let's take a closer look at each of them.
Business requirements
Requirements of this type are compiled from the business point of view. As a rule, they involve certain measurable business objectives and goals, a general project overview, a primary use, a target audience, benefits to be brought to a business, etc. In a nutshell, business requirements give an answer to the question of why to develop.
User requirements
User requirements are generated from the point of view of end-users. They contain users' expectations and needs revealed in the process of thorough analysis. Generally, these requirements are documented in the form of use cases, user scenarios, and user stories.
System requirements
These requirements outline specific features and functions that should be incorporated in an application under development and the way they should work. Traditionally system requirements are divided into two large subtypes that are functional requirements and non-functional requirements.
Functional requirements
Functional requirements describe the behavior of an application, i.e. what it must do or not do. They usually also define restrictions and requirements to input data as well as app responses to particular inputs. As a rule, functional requirements are rather straightforward and therefore can be easily tested.
Non-functional requirements
Non-functional requirements define the way particular features and an application in the whole must perform. In other words, non-functional requirements describe the characteristics of an application and the expected user experience. So these requirements tackle issues related to:
Domain requirements
We would like also to identify a particular type of system requirements that is domain requirements. They are relevant for applications related to healthcare, military, finance, and other industry sectors. For instance, healthcare software targeting the market of the United States must be developed in compliance with HIPAA that stands for Health Insurance Portability and Accountability Act.
An application that meets all functional and non-functional requirements can be still not acceptable for production due to its failure to meet domain requirements.
Characteristics of good requirements
Now it is time to proceed finally to the main topic that is the characteristics of good requirements. The characteristics presented below will be equally useful for both those who compile requirements and those who test them. So, let's get to the details.
Atomicity
Each requirement must focus on a particular aspect of app work, i.e. there should be no opportunity to divide it into a few more detailed requirements. For example, “A user should be able to log in and log out” is not an atomic requirement as it can be subdivided into two separate requirements that are “A user should be able to log in” and “A user should be able to log out”.
Completeness
A requirement should contain comprehensive information on the aspect it describes, i.e. a developer, a QA engineer, or any other team member should have in place all data needed for the correct development or testing. For example, “A user can log in to the system by providing a name, a password, and other relevant information” is not a complete requirement. In this case, it is needed to specify what lies behind the relevant information. The right variant would be like this “A user can log in to the system by providing a name, a password, and a surname”.
Consistency
Software requirements should not go against each other and common industry standards and regulations. Unfortunately, it is a common thing when requirements are compiled by numerous stakeholders among whom there are those with a lack of domain knowledge or expertise.
Uniqueness
All requirements should be utterly clear and accurate in order to be interpreted only in one possible way. It helps to avoid ambiguity and consequently bugs during the development process. Everyone who reads a requirement should understand it perfectly. In case, a requirement is particularly sophisticated it is advised to use charts, diagrams, or tables to make information clearer.
Traceability
Each requirement should be uniquely identified in order to refer to it in testing documentation or whenever needed and trace its realization throughout the SDLC.
Feasibility
Feasibility means that it should be possible to realize a requirement within the project in question. If for some reason a customer's demands are unrealistic, senseless, or even dangerous, it is important to reveal them. Identify risks and offer appropriate actions or alternatives.
Testability
According to this characteristic, there should be always a way to test and check the correctness of the requirement realization.
How to handle poor requirements
There is an opinion that poor requirements are much worse than the absence of requirements. We totally agree with this statement. Still, most QA teams have to deal with bad requirements on an ongoing basis. So how to handle poor requirements when QA specialists join a team late in the software development life cycle when there is no time and sense to test available requirements. There can be a few options:
Explore and study an application under test
In the course of app exploration and study you learn an expected app behavior, understand workflows and applied logic. This is one of the ways to fill the gaps in requirements and mitigate ambiguities. Besides, when requirements are not clear, as a rule, it is a good practice to prioritize user convenience.
Capitalize on your experience
It is rather obvious that your background, domain expertise, testing experience, difficulties faced in past as well as personal insights can be extremely helpful to address confusing requirements.
Use wireframes
Wireframes can be used to define some details and nuances useful for identifying expected application behavior and therefore for proper testing.
Ask for clarification
A customer is a product owner and it is always wise to ask him for clarification whenever there is an ambiguity in requirements. Still, it is worth remembering, it is not recommended to bombard the customer with numerous questions. Contact customer on making sure that requirements are indeed incomplete, unclear, or not uniquely defined.
Conclusion
The main goal of software requirements is to smoothen things down for all members of a product team and ensure their being on the same page. Still, when requirements are poor, it only makes things worse and procrastinates the whole process. To avoid numerous problems and errors in the future it is strongly advised to test requirements from the outset against such characteristics as atomicity, completeness, consistency, uniqueness, traceability, testability, and feasibility.