Author Topic: Qualities of Good requirement  (Read 1436 times)


  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: Qualities of Good requirement
« Reply #15 on: December 17, 2019, 05:46:43 pm »
Following are the Qualities of Good Requirement -
1. Correct
2. Unambiguous
3. Complete
4. Consistent
5. Importance
6. Stability
7. Verification
8. Modifiable
9. Traceable


  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: Qualities of Good requirement
« Reply #16 on: May 22, 2020, 01:49:35 pm »
The following characteristics of a good requirement are 
testable &
According to IIBA Business Analyst Body.


  • Global Moderator
  • Newbie
  • *****
  • Posts: 5
Good requirement
« Reply #17 on: May 29, 2020, 12:47:42 pm »
Complete - Requirements must be complete, because if they are not then functionality expected by the users will be missing.
This means as stated in User Requirements they must have all of the:
Functional requirements,Non-functional requirements,Design objectives,Reference material including a definition of terms used and units of measurement.

Clear - Even if the requirements are complete they must be understood with only one meaning. This means they must be unambiguous and specific.

Consistent - The key point about consistency is that no requirement contradicts what another

Control Characteristics - A set of requirements need to do more than just communicate, there are also issues of how they will be controlled through the project. The key control characteristics are that the requirements must be:

Certifiable - They can be verified and validated.

Chosen - They have been ranked as to importance.

Chaseable - They can be traced forward and backwards.

Certifiable - A requirement is not a requirement unless it can be verified and validated.

Chosen - Not all requirements are created equal, some “Must” be included, or the system will be a waste of effort, others “Could” be included as they enhance what the system could achieve.

Chaseable - It must be possible to trace a requirement both back to its business reason, and through to the design and testing documentation. Without the ability to chase them through it is impossible to compare any documentation to see if they have been implemented.

Construction Characteristics- Even with a set of requirements which communicate well and can be controlled there is still the issue of how they affect the developers. The two key characteristics are if the requirements are:

Credible - What is asked for is technically possible.
Clean - They do not have any implementation decisions.

Technical feasibility means comparing the requirements logical model, with what is currently technically possible. There are many times when what is wanted is well beyond what can be delivered at the moment. An example from the past was ambitious websites, when users had slow dial-up lines. The websites were not technically feasible as users could not access them.

Achievable feasibility means comparing the time, resources, quality and scope of the projects and assessing the risk of ever achieving it.

Clean - A clean set of requirements is one where only the logical structure has been defined, and decisions about physical design and implementation have been left out. The more physical design decisions that are taken by the users the fewer the options that are available to the developers to deliver what is needed, and the more likely that a poor quality system will result


  • Global Moderator
  • Newbie
  • *****
  • Posts: 11
Re: Qualities of Good requirement
« Reply #18 on: May 30, 2020, 11:23:10 am »
Testable (verifiable)
Clear (concise, terse, simple, precise)
Feasible (realistic, possible)
Implementation-free (abstract)


  • Global Moderator
  • Newbie
  • *****
  • Posts: 5
Re: Qualities of Good requirement
« Reply #19 on: August 18, 2020, 05:25:27 pm »
The Qualities of Requirement are

1. Clear: The requirement should be concise and simple.
2. Feasible: Whether the requirement can be accommodated in the present application or not.
3. Independent: The requirement should not have any other technical or functional dependency.
4. Testable: The requirement should be testable.
5. Time bound: The requirement should have time limits.