The requirement is a very broad term for any project. It involves its own engineering process: Elicitation, Analysis, Modeling, Specifications, and Validation & Management to deliver a solution that meets all the business needs. Therefore, identifying the correct requirements & ensuring requirements quality is very crucial

So, how do we do that? Thought about putting your requirements under a quality check? For example, going through the standards to identify missed, irrelevant or incomplete requirements

Here are 2 ways to ensure quality requirements that translate into a viable solution

#1. Validate requirement characteristics

The identification and articulation of the requirements heavily impact the success or failure of a project. They must be complete and consistent for all the stakeholders’ needs in a clear way to be effective.

Stated below are few characteristics of a ‘good requirement’ and a few working tips!

Complete

The individual requirement should not be missing any detail or necessary information. A complete requirement leaves no room for assumption on what to do and how to do it

Break larger requirement sets/rules into more manageable and abstract statements to not miss anything important. Use short sentences and paragraphs

Consistent

One requirement should not contradict other requirements

Requirements Traceability Matrix (RTM) is a good approach to keep a check for redundant and conflict-free requirements

Valuable

A requirement must add something to the solution to take it a step closer to meeting the business needs. If it isn’t adding any value, it’s not worth putting effort into it

Requirements Prioritization is one good technique to identify critical requirements

Concise

A requirement should be easy to read and understand by everyone in the team

Know your team members first. Tailor the words that can be understood by the person who is supposed to work on that requirement. For example, technical jargon for developers. Define the terms in a glossary

Unambiguous

A requirement should have one interpretation only

Make sure to expand the acronyms. Also, be careful while using words such as “only” and “should/shall” as they might give a different meaning. Prefer written communication over verbal one

Verifiable

A requirement must be testable either as pass or fail while validating the final solution

Words such as “etc.”, “If necessary”, “few”, “more” makes requirement not testable when implemented in the solution. If related test cases can be identified, it is a well written requirement

Atomic

A requirement should satisfy a feature independently. There should not be any need to understand other requirements first, which makes traceability easy

Requirement statements should never be defined including words such as “and”, “or”, etc

Correct

Each requirement must align with the business objectives. It should be factually correct and should describe the user’s expectations clearly

Get rid of assumptions to make your requirements correct

To read more about this in detail, here is a good article by Scott Sehlhorst

#2 Analyze requirement against core components

Each stakeholder has a unique role to perform in building the solution. For instance, a developer is concerned about daily tasks, a team lead is concerned about the technical solution, a client or a product owner is concerned about the business rules and needs, etc. Carefully examining the requirements from different perspectives according to the core components would help us find gaps, inconsistencies, and avoid any chance of missing requirements

Let’s understand these core components and the ways to present the requirements from these perspectives

Requirement components

There are 4 core components namely,

#1. Data

Data is the information used by the business to do the work and a core component of any system. Regardless of the size of data the requirements analysis is based on points such as what the data is for, how it will be represented, and what relationship it has with other data. They are often stored using Database Management Systems in physical design

Data has 3 components:

#1.1. Entities: A unique business concept that business wants to store information for. Represented as Tables in Database

#1.2. Attributes: They define the characteristics of the entity. They must be specified for uniqueness (one and only one) and cardinality (mandatory or optional). Represented as Columns of the Table in Database

#1.3. Relationship: It connects entities with each other. Represented as Keys in Database

It is equivalently important to define the data in logical representation as well (ER Diagrams) from the business perspective. They often uncover more complex business rules and dependencies

#2. Process

A process is a collection of individual steps, actions or other processes to achieve an end goal (say, “search nearby restaurants”). It also provides details about who all will be using the system, what are the individual roles in the system, what data to access, what steps to take

Use Cases, User Stories, Process Flow Diagrams, Activity Diagrams, or Flowcharts are ways to represent a process. They help identify actors, features, and data flow

#3. External Agents

These are the people, organizations, or other systems that interact with the business areas. All the involved stakeholders identify them at a very early stage of the project scoping itself. External agents become significantly more important when we draft solution requirements because these are the actors for whom we are defining the detailed functional and non-functional requirements

This perspective helps to identify and build the specific user interface as per the interactions required by these actors. Prototypes along with the validation rules, business rules are a good representational technique

#4. Business Rules

These are the guidelines and constraints under which the business works. They provide a model for how the business runs and manages the enterprise. Business rules involve data, processes, and external agents. They must be specified for cardinality (mandatory- error messages or optional — “are you sure…?”). It is a real challenge to identify and define business rules. Even stakeholders aren’t aware of all the rules and dependencies implemented in their organization such as rules defined before his/her joining, or rules that are not used/changed frequently

This perspective helps to define user interaction with the system based on authorization, business constraints, and validation rules

Read more about these components in detail in the chapter “Understanding what requirements truly entail” of the book “Business Analysis for Dummies”

After identifying clear, complete, and quality requirements, the next step is to draft them in a way that can be understood by each stakeholder easily. For example, FRS, SRS, workflow diagrams, prototypes, UML diagrams, use cases, and user stories

I hope the article provides some help with your quest with quality requirements!

Know something else? Tell me more that you do to make requirements excellent

This article was originally published by me on LinkedIn

Surbhi Mahnot

Surbhi Mahnot

Surbhi Mahnot is the owner of this blog. She works as a Management Consultant with businesses to set up processes, and coordinate as Project Manager to help develop IT solutions. Travelling, reading, and shopping are her core interest besides work. Surbhi is available for consultant projects full-time, part-time, or remote work

Leave a Reply

Your email address will not be published. Required fields are marked *

Close