What are your requirements?
What are your requirements?
Why do we as testers spend so much time with functional requirements? What about the rest of the requirements which are numerous and important as well?
26 May 2015
3086
Other articles
How to incrementally migrate the data from RDBMS to Hadoop using Sqoop Incremental Last Modified technique?
How to implement Slowly Changing Dimensions(SCD) Type 2 in Spark?
How to incrementally migrate the data from RDBMS to Hadoop using Sqoop Incremental Append technique?
Why MongoDB don't fetch all the matching documents for the query fired
How to solve the issue of full disk utilization in HDFS Namenode
Can We Use HDFS as Back-up Storage?
How to do Indexing in MongoDB with Elastic Search? Part 2
How to do Indexing in MongoDB with Elastic Search? Part 1
How to store data on browser using NoSQL IndexedDB?
How to Apply MBTI in HR: Motivation for every day. Groups of People & their Motivations
Why do we as testers spend so much time with functional requirements? What about the rest of the requirements which are numerous and important as well?
A functional requirement is 'A description of a behavior that a system will exhibit under specific conditions'.
So you have to think about the situations in which the program might be used and find solutions for getting out of those situations – is this the task of the tester?
At an abstract level all the requirements can be divided into four categories:
Of course you must have a separation between requirements and specifications – which aren’t the same thing. But what is taken into account must be written.
In alphabetical order, the most important specifications are:
Business requirement
A high-level business objective of the organization that builds a product or of a customer who procures it. This is the "Wish list", which still needs to be displayed correctly in the functional requirements (of which there may be more than one), which in turn have to become specifications.
The trouble is that this Wish list provides an answer to the question "Why should I do something?". The majority believes that the Wish list will tell why and how this product will be implemented.
Business rule
A policy, guideline, standard, or regulation that defines or constrains some aspect of the business. Not a software requirement in itself, but the origin of several types of software requirements.
Constraint
A restriction that is imposed on the choices available to the developer for the design and construction of a product.
Feature
One or more logically related system capabilities that provide value to a user and are described by a set of functional requirements.
Functional requirement
A description of a behavior that a system will exhibit under specific conditions. The keyword here is "the situation."
Nonfunctional requirement
A description of a property or characteristic that a system must exhibit or a constraint that it must respect. That is, should be considered.
Quality attribute
A kind of nonfunctional requirement that describes a service or performance characteristic of a product. Who takes this into account?
System requirement
A top-level requirement for a product that contains multiple subsystems, which could be all software or software and hardware. Who writes these requests?
User requirement
A goal or task that specific classes of users must be able to perform with a system, or a desired product attribute. No need to wait for users to come and present their claims. It will be very bad if users come to the requirements.
Alexey Lupan
A functional requirement is 'A description of a behavior that a system will exhibit under specific conditions'.
So you have to think about the situations in which the program might be used and find solutions for getting out of those situations – is this the task of the tester?
At an abstract level all the requirements can be divided into four categories:
- Business requirements
- User requirements
- Functional requirements
- Anything that falls under the concept of "non-functional requirements."
Of course you must have a separation between requirements and specifications – which aren’t the same thing. But what is taken into account must be written.
In alphabetical order, the most important specifications are:
Business requirement
A high-level business objective of the organization that builds a product or of a customer who procures it. This is the "Wish list", which still needs to be displayed correctly in the functional requirements (of which there may be more than one), which in turn have to become specifications.
The trouble is that this Wish list provides an answer to the question "Why should I do something?". The majority believes that the Wish list will tell why and how this product will be implemented.
Business rule
A policy, guideline, standard, or regulation that defines or constrains some aspect of the business. Not a software requirement in itself, but the origin of several types of software requirements.
Constraint
A restriction that is imposed on the choices available to the developer for the design and construction of a product.
Feature
One or more logically related system capabilities that provide value to a user and are described by a set of functional requirements.
Functional requirement
A description of a behavior that a system will exhibit under specific conditions. The keyword here is "the situation."
Nonfunctional requirement
A description of a property or characteristic that a system must exhibit or a constraint that it must respect. That is, should be considered.
Quality attribute
A kind of nonfunctional requirement that describes a service or performance characteristic of a product. Who takes this into account?
System requirement
A top-level requirement for a product that contains multiple subsystems, which could be all software or software and hardware. Who writes these requests?
User requirement
A goal or task that specific classes of users must be able to perform with a system, or a desired product attribute. No need to wait for users to come and present their claims. It will be very bad if users come to the requirements.
Alexey Lupan