Quality Characteristics of Software Requirements

Characteristics of Good Requirements in Software Engineering

What makes software requirements good?

BABOK 3.0 provides nine quality characteristics of good requirements in software engineering, you can use them as a checklist when writing or testing requirements:

• Atomic
• Complete
• Consistent
• Concise
• Feasible
• Unambiguous
• Testable
• Proritized
• Understandable

For example, when a user story is written with all the criteria and designs attached, as well as other artifacts ready - it's time to test it for requirements quality.

You can use these characteristics of software requirements as a software requirement quality checklist.

Let's take a closer look at some of the characteristics of good requirements in software engineering and determine how to get closer to the ideal.

Atomic

An atomic requirement is a requirement that cannot be broken down into more detailed requirements (which do not lose their completeness - i.e. the requirement that a user can log in by entering his email and password shall not be broken down into 3 user stories: the email field, the password field and the login button).

Why is it important for software requirements to be atomic?

To make it possible to:

• prioritize them correctly (it's hard to prioritize a user story that involves creating, editing, and deleting a post. But if you break it down into 3, it becomes much easier - not everything from this set can obviously be included in the MVP);
• trace requirements (for example, putting a dependency on a very large requirement will cause confusion in the future - what part is the dependency on?);
• develop easier (less opportunities to mess up/miss something when the requirement is small and simple);
• the functionality developed will reach testing phase faster - yes, this is very important, QA will understand me.

To make requirements atomic, you need to be able to decompose them correctly.

Complete

Completeness is a very important characteristic of software requirements quality that is worthy of a separate article.

The completeness of the requirements depends on several factors, for example, on the "maturity" of the team. For example, a team of juniors may need a description of what a "special character" is and which ones can be used in a password. Or, that spaces at the end of a text input may be cut on saving. Or, for example, what to do if the user has entered nothing but a few spaces in the username field: do we accept this at all, or should we trim the spaces and consider a field with only spaces as blank?

A requirements set is complete if and only if it describes all important requirements of interest to the user, including requirements related to functionality, performance, design constraints, attributes, or external interfaces. (IEEE 830-1993, § 4.3.3, 1994).

Possible consequences of incomplete requirements:

• the system will not be coherent (e.g., a certain field, due to unnecessity, was removed throughout the system, except for a couple of pages, or, on the contrary, something was added but forgotten to add it to the data export);
• the team does not implement a specific case and the system will "crash" during its execution;
• the team implements the case not in the way the client or you wanted it to be implemented, and not in the right way for the product (will "invent" the requirement by itself);
• the team will have a lot of questions (during implementation and testing);
• some non-functional requirements will not be taken into account and, for example, the server will crash when 100 people visit the site at the same time.

What helps to achieve software requirements completeness:

• Understanding of non-functional requirements (what are non-functional reui there at all, which ones apply to your project/product/user story);
• prototyping (when you think about the interface, you can see the feature from a different angle and detect more requirements and corner cases);
• diagrams (whether it's an activity diagram (UML), BPMN, a flowchart or even ERD (UML) (the list can be continued) - they all make you think about different aspects of the requirements and fill the gaps);
• decomposition (when you break down an epic into user stories and write acceptance criteria, there is an opportunity to "fish out" something else);
• requirements tracing (or re-linking in a requirements management system - when tracing is used, you know that changes in part A will affect part B and the requirements for the system will be more complete);
• teamwork - brainstorming with the team, grooming, discussions with the UX team - all this fills in the gaps and brings up interesting thoughts;
• meeting minutes and proper chains of correspondence with customers - proper organization greatly reduces the chances of missing important details or forgetting that something has already changed;
• requirements review by other analysts;
• requirements testing (QA write case studies/checklists of testing on stories you think are ready and find gaps).
  

Good requirements are those that don't need to be refined, i.e., all the necessary details are at place (but without excessive detail).

Unambiguous

A quality requirement is an unambiguous requirement.

Unambiguity is an important and complex characteristics of good requirements in software engineering. Each person has a different experience and a different set of knowledge, which puts a certain imprint on the perception of information.

That's why you should try to write software requirements in such a way that they are as unambiguous and understandable for any person as possible (i.e. understandable not only for analysts :) ).

Any person reading the requirement should understand it as good as the one who wrote it. And the same way!

Imagine coffee. Have you imagined it?

Someone imagines espresso, someone imagines americano, someone drinks with milk and imagines latte, and someone wants a refreshing ice latte.

It works the same way for functional and non-functional requirements. If they can be interpreted differently, the team members will understand them differently. It is what it is.

The outcomes can be different:

• The team implements something in the wrong way, and it makes its way to production or is presented in a demo. This may result in time loss and damage to the reputation.
• Disputes will arise regarding how it should work, with everyone having their own opinion. It's beneficial if the Business Analyst (BA) is actively involved in the project to provide explanations, rather than solely writing user stories and moving on to another project, but situations may vary, and BA might not be available when development is in progress.
• The losses resulting from ambiguously described non-functional requirements can be significantly greater. For instance, when the requirements state "the system must be secure," it might mean that it should address the first three threats from the OWASP list, however, the client might anticipate an entirely different security approach, potentially costing an additional $100,000 or more.
• Software Engineers might implement something other than what is actually needed, but Quality Assurance (QA) team will identify the issue and prompt them to redo the work, resulting in a loss of time and money.

Acceptance criteria such as "the system performs quickly" or "the interface is user-friendly" cannot be precisely measured, making them inherently ambiguous. What one person considers "fast" or "understandable" may differ from another's perspective.

Additionally, we can classify the following aspects as potentially "ambiguous." If these elements are not adequately described, the implementation may yield unexpected results:

• Default values.
• Field format.
• Permitted characters.
• System responses to negative scenarios.

Ambiguities can be identified through various methods:

1. Self-Review: Take some time to revisit the requirements a few days after initially writing them, essentially stepping out of the immediate context. This can help uncover any unclear points.
2. Client or Product Manager Communication: Engage in discussions with the client or the product manager to ensure alignment on the requirements. This collaborative process can help clarify any potential ambiguities.
3. Team Discussions: Discuss the user story or requirements with the project team. Group discussions often lead to different perspectives that can highlight ambiguities.
4. Review Requests: Requesting a review of the requirements by peer BAs, QAs or subject matter experts can reveal ambiguities and offer different insights.
5. Demo Feedback: Ambiguities might become apparent during a demo when the client expresses surprise or dissatisfaction, exclaiming, "This is not what I asked for!" (the worst scenario, and, frankly, very stressful).

So unambiguity is a crucial characteristics of good requirements in software engineering. Unambiguous requirements are those requirements that save money.

Feasible

Not all software requirements (both non-functional and functional) can be fulfilled. Some requirements are unattainable because they are illogical. Others are so because, at the moment, there are no tools that would allow their fulfilment with a reasonable amount of resources.

Once, during a backlog refinement session, our team discussed adding a small detail that seemed important for improving usability.

"It's impossible" said my young colleague.

"Well, it's entirely possible," retorted a more experienced developer, "but it would take approximately a year."

In other words, some requirements are considered practically unattainable because the balance between value and resources is unreasonable under the given circumstances (and each situation has its own set of conditions).

Consistent

Another quality characteristics of good requirements in software engineering is consistency.

Software Requirements are considered consistent when they do not contradict other project requirements. High quality software requirements cannot be conflicting.

For instance, if the data dictionary specifies that the "Name" field is mandatory, but a user story states that it is optional, the system requirements are inconsistent (i.e., they are contradictory). Or, flowchart contradicts the written requirements.

Inconsistencies typically occur when:

• A business analyst forgets that they have already thought through or described something and repeats the process in a different place.
• Requirements change, but the business analyst doesn't update them everywhere they are documented.
• The business analyst overlooks boundary values. For example, acceptance criteria contradict each other: in one criterion, age <= 14 is considered a child, and in another, >= 14 is considered a teenager. In this case, 14 falls into both categories, which the author likely did not intend.
• A new business analyst joining the project misses or is unaware of certain implementation details, especially when they are not documented or challenging to track in the requirements management system.
• Changes are made to the requirements, but the designer is not informed.

Additionally, quality software requirements should not contradict "higher-level" requirements. For example, quality functional requirements should be consistent with user requirements, and user requirements should align with business requirements.

To verify the consistency of requirements, reviews can be conducted, either by an individual or by a team.

Conclusion

To assess the quality of software requirements, whether they are your own or those of a business analyst on your project, use the quality criteria I've described above.

And be sure to subscribe so you don't miss new articles on business analysis.

If you are a Business Analyst or a Product Manager, or are considering becoming one and contemplating obtaining a Product Owner certificate, you might find this article of interest: How to become a Certified Scrum Product Owner?