2 Ways to Ensure Quality Requirements

It is very important to know that ‘requirement’ is a very broad term for every project. It involves its own engineering process (Elicitation, Analysis, Modeling, Specifications, Validation & Management) to come to a point to be able to deliver the exact solution that meets all the business needs. Therefore, identifying correct requirements is very crucial.

So, how do we do that? Thought about putting your requirements under a quality check? Like, going through the standards to ensure that there aren’t any requirements that got missed, are irrelevant or bad (in the given time context only!).

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

#1 Validate Requirement Characteristics

Project’s success or failure depends on the way the requirements are identified and articulated. The requirements must be complete and consistent for all the stakeholders’ needs in an unambiguous 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 needs to be done and how it needs to be done.

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. It is more important on a set of requirements.

Requirements Traceability Matrix (RTM) is a good approach, if managed properly, 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 a requirement isn’t adding any value, it’s not worth putting efforts.

Requirements Prioritization is one good technique to quantitatively know which requirements are critical.

• 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 such as technical jargon for developers! Define the terms in a glossary. Use proper grammar, punctuation and spelling.

• Unambiguous: A requirement should have one interpretation only

Take care to expand the acronyms, be careful while using words such as “Only”, “Should/Shall”, 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 you think of related test cases for the requirement, then the requirement is written well.

• 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”.

• Correct: Each requirement must be aligned with the business objectives. It should be factually correct and describes the user’s expectations clearly.

Get rid of assumptions to make your requirements correct.

Quality of these characteristics would vary depending on the type of project and the methodology chosen (Agile or Waterfall).

Here is a good article by Scott Sehlhorst to read more about this in detail and of course the chapter “Understanding what requirements truly entail” in the book “Business Analysis for Dummies” is also an informative read.

#2 Analyze Requirement Against Core Components

Each stakeholder has a unique role to perform in the building of the solution. Say, a developer is concerned about “What tasks to do?”, a team lead is concerned about “How to build the solution technically?”, client/product owner is concerned about “Business rules and needs”, etc. Carefully examining the requirements from different perspectives according to the core components would help us find gap, inconsistencies and avoid any chance of missing requirements.

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

There are 4 core components namely,

#1. Data: It is the information used by the business to do the work. The core component of any system. Be it big data or small data, we analyze the requirements 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.

It has 3 components:

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

b. 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.

c. 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 the work done by the business. It is a collection of individual steps, actions or other processes to achieve an end goal (say, “search nearby restaurants”). It provides details about who all will be using the system, what are individual roles in the system, what data to access, what steps to take.

They are generally represented as Use Cases, User Stories, Process Flow Diagrams, Activity Diagrams, Flowcharts. 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. They are identified at very early stage of the project scoping itself. They 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, process 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 the business rules as even stakeholders aren’t aware about all the rules and dependencies implemented in their organization (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 chapter “Understanding what requirements truly entail” of the book “Business Analysis for Dummies”.

Once your requirements are clear and complete enough to get started, you need 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 the requirements!

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

The article was originally published by surbhimahnot on LinkedIn.