No requirement is Good or Bad,every requirement has its own identity, the way we define the requirement make the difference of Good or Bad.Its all about tendency and approach towards any requirement.
Most of the people find difficult to answer qualities /characteristics of good requirement.45% of the people able to answer the question but they fail to explain/ elaborate in detailed fashion.
Any requirement must and should pass through 12 different areas to get an identity of characteristics Good requirement.
Find list of few characteristics of good requirement.
- Clear (concise, terse, simple, precise)
- Feasible (realistic, possible)
There should be only one way to interpret the requirement, no two ways to interpret it.
If your girlfriend burns all your letters, texts you that she hates you, and moves a thousand miles away, the unambiguous message is that she’s finished with you and its break up. Same logic applies to IT Application vertical.
Statement: The system shall not accept User Name longer than 15 characters.
Ambiguous: It is not clear what the system is supposed to do
- The system shall not let the user enter more than 15 characters.
- The system shall truncate the entered string to 15 characters.
- The system shall display an error message if the user enters more than 15 characters.
Unambiguous: The system shall not accept User name longer than 15 characters. If the user enters more than 15 characters while choosing the User name, system must throws Error Message.
Testers should be able to verify whether the requirement is implemented correctly or Not.So they can initiate the testing and come to an conclusion whether requirement met the objective as promised to the client/Stakeholder and test condition is pass or f ail
The main important characteristics of any requirement to initiate the testing or testable, requirements should be clear, precise, and unambiguous
Most of the time people says below terms pertains to the requirement which make no sense in IT development.
(Robust, safe, accurate, effective, efficient, expandable, flexible, maintainable, reliable, user-friendly, adequate, quickly, safely.)
Application must and should handle multiple user login at a time without hindering the performance.
What number should be considered “many”—10, 100, 1,000?
Clear (Concise, Terse, Simple, Precise)
Requirements should not contain unnecessary information. They should be stated clearly:
When you search for specific key wards to Google “The search algorithm” must and should written in such a fashion that search specific data would be displayed to the user instead of un-necessary or Junk data.
If a requirement contains facts, these facts should be true:
If you go any restaurant taxable would be applicable all the food items and unlike few item taxable and few or not.
Feasible (Realistic, Possible)
The requirement should be doable within existing constraints such as time, money, and available resources:
Example: Translation of English language to any other language with Google search engine.
The above requirement is feasible but time constraints is important to implement, its realistic because Google language translator convert English to any other language you desired for.
Requirements should be grammatically correct and it should not be written in inconsistent style. Standard conventions and practice must and should be used.
The word “shall” should be used instead of “will,” “must,” or “may.”
Each and every requirement must and should different from other, practically speaking, to understand the requirement; there should not be a need to know any other requirement (this is what the word independent defines). It’s highly impossible to say no requirement is independent on other, in real time whichever the application you take for consideration from Login to login out each and every activity has a dependency on other.
The requirement should contain a single traceable option, if any requirement has too many traceability it may leads to confusion and difficult to track.
So it’s always recommended to have requirement has a single source or end to track .
Flight Reservation System
The system shall provide the opportunity to book the flight, purchase a ticket, reserve a hotel room, reserve a car etc.
Above requirement consist of five different requirements, which make traceability very difficult.
When we come across such kind of requirement words like But, And are used to break that chain of requirement to make it simple and clear.
Importance of the requirement is necessary, and requirement must and should have a priority based on the scenario or situation ,We cannot implement the requirement for the sake of implementing, it does not make sense and it will have impact on the scope OR may be project would be part of creep .
There should not be any conflicts between the requirements. Conflicts may be direct or indirect. Direct conflicts occur when, in the same situation, different behavior is expected:
REQ1 Dates shall be displayed in the mm/dd/yyyy format.
REQ2 Dates shall be displayed in the dd/mm/yyyy format.
Sometimes it is possible to resolve the conflict by analyzing the conditions under which the requirement takes place. For example, if REQ1 was submitted by an American user and REQ2 by a French user, the preceding requirements may be rewritten as follows:
REQ1 For users in the U.S., dates shall be displayed in the mm/dd/yyyy format.
REQ2 For users in France, dates shall be displayed in the dd/mm/yyyy format.
This can eventually lead to the following requirement:
REQ3 Dates shall be displayed based on the format defined in the user’s web browser.
Another example of a direct conflict can be seen in these two requirements:
REQ1 Payment by PayPal shall be available.
REQ2 Only credit card payments shall be accepted.
In this case the conflict cannot be resolved by adding conditions, so one of the requirements should be changed or removed.
Indirect conflict occurs when requirements do not describe the same functionality, but it is not possible to fulfill both requirements at the same time:
REQ1 System should have a natural language interface.
REQ2 System shall be developed in three months.
Some requirements do not conflict, but they use inconsistent terminology:
REQ1 For outbound and inbound flights, the user shall be able to compare flight prices from other, nearby airports.
REQ2 The outbound and return flights shall be sorted by the smallest number of stops.
To describe the same concept, in the first requirement the term “inbound flights” is used, and in the second requirement the term “return flights” is used. The usage should be consistent.
A requirement should be specified for all conditions that can occur:
REQ1 A destination country does not need to be displayed for flights within the U.S.
REQ2 For overseas flights, the system shall display a destination country.
What about flights to Canada and Mexico? They are neither “within the U.S.” nor“overseas.”
All applicable requirements should be specified. This is the toughest condition to be checked. There is really no way to be sure that all the requirements are captured and that one week before the production date one of the stakeholders won’t say, “I forgot to mention that I need one more feature in the application.”
(Above sentence is collected from Google and other sources, to represent in much elaborated way)
Each requirement should be expressed only once and should not overlap with another requirement: