So each and every requirement you have should be atomic, which means it should be at a very low level of details it should not be possible to separate out into components. Here we will see the two examples for requirements, at Atomic and uniquely identified requirements levels. 

So let us continue with the example of system build for the education domain. Here, the bad requirement is "Students will be able to enroll in undergraduate and postgraduate courses". This is a bad requirement because it is not atomic because it talks about two different entities undergraduates and post-graduates courses.

So obviously it is not a good requirement but bad requirement, so correspondence good requirement would be to separate it out into two requirements. So one talks about the enrolment to undergraduate courses while the other talks about the enrolment to the post-graduate courses.

Similarly, the next requirement quality is to check for uniquely identified, here we have two separate requirements but they both have the same ID#1. So, if we are referring our requirement with reference to ID#, but it is not clear which exact requirement we are referring to document or other parts of the system as both have the same ID#1. So separating out with unique id's, so good requirement will be re-return as section 1- course enrolments, and it has two requirements 1.1 id is enrolment to undergraduate courses while 1.2 id is enrolment to postgraduate courses.

Also, each and every requirement should be complete. For example, here the bad requirement says a "professor user will log into the system by providing his username, password, and other relevant information". Here the other relevant information is not clear, so the other relevant information should be spelled out in good requirement to make the requirement complete.

Next, each and every requirement should be consistent and unambiguous, so here, for instance, we have requirements "A student will have either undergraduate courses or post-graduate courses but not both" this is one requirement there is some other requirement that says "Some courses will be open to both under-graduate and post-graduate students".

The problem in this requirement is that from the first requirement it seems that the courses are divided into two categories undergraduate courses and postgraduate courses and student can opt either of two but not both. But when you read another requirement it conflicts with the first requirement and it tells that some courses will open to both post-graduate and under-graduate. 

So it is obvious to convert this bad requirement into good requirement which is "A student will have either under-graduate courses or post-graduate courses but not both". Which means that every course will be marked either being an under-graduate course or post-graduate course.

Each and every requirement should be traceable because there are already different levels of requirement, we already saw that at the top we had business requirements, and then we have an architectural and design requirements followed by system integration requirements.

Now when we convert business requirement into architectural and design requirements or we convert architectural and design requirements to system integration requirements there has to be traceability. Which means that we should be able to take each and every business requirements and map it to the corresponding one or more software architectural and design requirement. So here is an example of a bad requirement that says "Maintain student information – mapped to BRD req ID?" the requirement id is not given over here.

So, converting it to a good requirement it says the same thing but it is mapped with the requirement id 4.1. So mapping should be there for each and every requirement. The same way we have a high level and low-level mapping requirement, the mapping is also there between system and integration requirement to the code that implements that requirement and also there is a mapping between the system and integration requirement to the test case which test that particular requirement. 

So this traceability is all across the entire project.

Then each and every requirement must be prioritized, so the team has guideline so which requirement that able to implement first and which can be done later on. Here you can see the bad priority has register student, maintain user information and each and every requirement has given priority-1. Everything cannot be at the same priority, so requirement can be prioritized. So the example of good requirement over here is the registered student and enroll courses are given the highest priority 1 while maintaining user information comes below at priority 2 and then we have view report card at priority-3.

Each and every requirement should be testable, here the bad requirement is "each page of the system will load in an acceptable time frame". Now there are two problems with this requirement first is that each page meaning that there can be many pages, which going to blow up the testing efforts. The other problem is that it says the page is going to load in an acceptable time frame, now what is the acceptable time frame? Acceptable to whom. So we have to convert the non-testable argument into a testable argument, which specifically tells about which page we are talking about "register student and enrolls courses pages" and the acceptable time frame is also given which is 5 seconds.