Ensuring Quality of Requirements: Quality Characteristics defined by IIBA

The success of a change initiative depends on the quality of the requirements. 'Good requirements' (I really don't like to use this term!) or in other words requirements and designs specified and modeled in a way that helps communicate the need are critical to meet the real desires of stakeholders.

The International Institute of Business Analysis (IIBA) outlines 9 crucial quality characteristics that requirements should possess. You'll get to see these quality characteristics on page 153 of the BABOK Guide version 3.

But... there are no examples. 🙁

Not to worry! Here's an attempt to explain these attributes of good requirements and designs with examples; from the context of both IT and non IT change initiatives.

Atomic

An atomic requirement is self-contained and stands independently, without relying on other requirements or designs. We say that a requirement is atomic when it is broken down and has enough information covering all aspects of a need without needing to be broken down any further or any additional context.

For instance, when developing a CRM application: "The admin must be able to add one customer record at a time" is an example of a requirement broken to an atomic level and which can stand on its own.

Complete

A complete requirement provides all the necessary information to guide further work and is detailed enough to ensure clarity. The requirement is complete when the individual requirement is not missing necessary or relevant information and an entire set of requirements together covers all relevant requirements.The level of completeness may differ from context to context. It may also differ based on expectations of different stakeholder groups.

For example we can say that the requirement is complete when the Add customer one by one user story has information on,

• all the information about a customer record
• all the ways through which a customer record can be added to the system
• all that that can go wrong including error messages
• all the success scenarios and post condition

Consistent

Consistency ensures that requirements align with stakeholders' needs and do not conflict with each other. This includes writing requirements with consistent use of wording/terminology, and consistent use of notations and symbols.

See examples below.

• Referring to the system under investigation as 'HR system' in some places and 'Recruitment System' in other places of the same document is an inconsistent requirement.
• Drawing the activity in a process diagram as a rectangle in one place and as a round edged rectangle in another place again is an example of inconsistency.

Concise

Concise requirements are focused and devoid of unnecessary content, making them clear and easy to understand. In other words the little information added to a requirement covers what is needed and does not contain any unnecessary information.

'As a fleet manager I must be able to search for vehicles to recall for maintenance by vehicle number, vehicle category, chassis number, or last service date' is an overly constrained user story. 'As a fleet manager I must be able to search for vehicles to recall for maintenance' is a concise enough user story and the additional information can go into the acceptance criteria.

Feasible

Change initiatives operate within cost, schedule, resource, technology, architecture, design and other constraints. There are dependencies and risks involved that may further create difficulties in the project environment. Feasible requirements are realistic and can be achieved within the project's constraints. Let's look at some examples of feasible requirements.

In the construction of a bridge, a feasible requirement might be: "The bridge must withstand a minimum load capacity of 20 tons" or "The building must be constructed using materials readily available in the local market".

An example from a Software development perspective would be "The mobile application must support offline functionality for users to access basic features such as reading saved articles and accessing previously viewed content without an active internet connection".

Unambiguous

An unambiguous requirement leaves no room for interpretation, ensuring clarity and precision. A requirement is ambiguous when two or more people interpret and understand the same requirement in different ways.

Consider a requirement for a mobile banking app: "The system must be user friendly" is an ambiguous requirement as user friendliness for me may be completely different from user friendliness for someone else.

Another ambiguous requirement is "The account balance should be accurate". This requirement can be made unambiguous by adding more details around accuracy - i.e. accurate to the nearest 2nd decimal point rounded up.

Testable

Testable requirements enable verification of their fulfillment through testing processes.

We make the requirements testable as soon as we add acceptance criteria to the user stories that we write in a change initiative following an Adaptive approach.

For example in a website development project, a testable requirement could be: "The contact us form must send an email notification to the site administrator upon submission and the email should contain contact's name, email, mobile number, message body".

Prioritized

Prioritizing requirements helps in focusing efforts on the most critical aspects of a project. A requirement must be ranked, grouped, ordered and negotiated based on the relative importance when compared to other requirements. The intention is to ensure that the requirements deliver the highest possible value as soon as possible.

We prioritize requirements when we rank our user stories during our backlog grooming or sprint planning meeting so that a set of user stories that together makes sense can be taken in to a sprint. For example let's say that add customer's one by one, add customers in bulk, update customers, view customers, delete customers are prioritized in this order. This makes perfect sense as we must add customer records before we can view, update or delete.

Understandable

Requirements should be expressed in language that is understandable to all stakeholders involved. When analysts work in specific domains such as healthcare, airline, banking and finance or insurance there will be many instances where a lot of technical jargon is heard. The requirements should be elicited, modeled and specified in a language that is clear to the practitioners from that specific domain and also be understandable to the development team. This is where the Business Analyst can create a glossary of terms, draw a concept model or a mind map, or add examples to clarify the functionality.

Have a look at the example below.

Short Term Disability benefit equals 60% of weekly salary to a maximum of $500.

Monthly Premium = ((Weekly Salary x Benefit Percentage) / Rate Units) x Rate

If the employee’s weekly salary is $400 and the STD rate is $0.80 per $10, premium is calculated as follows:

Monthly Premium = (($400 x 60%) / 10) x $0.80 = $19.2

In conclusion, adhering to these quality characteristics outlined by IIBA ensures that requirements are clear, comprehensive, and aligned with stakeholders' needs. By incorporating these principles into the requirements elicitation and analysis process, you can enhance communication, mitigate risks, and increase the likelihood of project success.

Hope this helps to write requirements suitable to meet your stakeholder needs. Do let me know how it goes! 😉

And.. wan't to learn good practices of Business Analysis or implement a BA practice in your organization. Follow www.apptraholdings.com and https://www.linkedin.com/company/apptra for more details about upcoming sessions targeting IIBA certifications and for details about Business Analysis related services we offer.