The Community Blog for Business Analysts

Surbhi Mahnot
Surbhi Mahnot

Identifying requirements, the right way

Requirements define the needs of the project to provide best of its utility and benefits. If they aren’t clear or analysis is not done properly, it might lead to failure of the project no matter how good the concept and design is.

Just as a system is composed of various functionalities, requirements too are identified in various forms. This categorization of requirements makes analysis process much simpler and clear for all the involved stakeholders. As per BABOK, the requirements are primarily categorized as:

  • Business Requirements
  • Stakeholder Requirements
  • Solution Requirements - Functional and Non-Functional Requirements
  • Transition Requirements

With so many requirements to identify it is very easy to get confused with how to identify these requirements?

A simple approach is to visualize the complete process and start step by step

To do that, let’s look at cooking for an example:

When you plan to cook a meal, you first take in account for whom you are cooking. Is it for yourself or for your family or the kids? These define your Business Requirements. Once you decide this, you figured that you will sip wine along with the food and the kids won’t eat spicy food (stakeholder’s requirements). Next, you get all your ingredients for the meal (functional requirements) and you might also take in consideration the time you require to prepare the meal and preparation required for serving the food (Non-functional requirements). Finally, you prepare a delicious penne arrabbiata pasta topped with oregano and basil leaves (technical requirements).

Now, let’s understand each of these requirements with a technical example, Implement Log-in functionality.

Business Requirements: These are high-level business objectives or goals or needs of an organization. The business requirements document (BRD) usually includes what features would be there in the product, what market the business will expand or enter, risk assessment, success measures from the business point of view, etc.

Example: There shall be a Login screen through which Users will log into the system.

Tip to identify:

Words or phrases that describes what, such as “we need to be able to”, “we need to solve this” and “we need a way to”.

Stakeholder (User) Requirements: These are what every stakeholder needs/expects from the solution and how they will interact with the solution. Often the stakeholders can explain the entire system in detail from their perspective only. Each stakeholder sees the problem from unique perspective. Therefore, you must understand all the needs to understand the complete system. All these requirements must be analyzed in such a manner that it doesn’t conflict with each other.

Example:

As a customer, the user shall be redirected to Dashboard on successful login. (Stakeholder - Customer).

As an admin, the user shall be redirected to the Administrator’s landing page on successful login. (Stakeholder -  Administrator).

Tip to identify:

Similar to business requirements, but from user's perspective. Words or phrases that describes what, such as “we need to be able to”, “we need to solve this” and “we need a way to”.

Solution Requirements: These specify the detailed conditions and the capabilities that the solution must have to meet the business and stakeholder requirements. Software Requirements Specification (SRS) is created to capture both functional and non-functional requirements. These are categorized into two:

a.      Functional Requirements: These define specific behaviors, responses, information, rules for the solution primarily addressing the following:

  • The features the system will support (Functional capabilities)
  • Data validation rules and how they will be managed (Business Rules)
  • Interaction between different stakeholders (users) within the system (Use cases)

These include a complete description of ‘how’ the system will be built.

Example:

  • Registered users shall be able to login with valid username and password
  • On successful login, user shall be redirected to a landing page in the system
  • On failure, for not registered username prompt "Username not registered" message and for invalid credentials prompt "Invalid credentials"
  • New users shall be able to register with the system by clicking on the "Sign-Up" link
  • Users shall be able to recover password by clicking on "Forgot Password" link

b.     Non-functional Requirements (Quality-of-service): These define the environment in which the solution will operate. The qualities a solution must have or constraints within which it must operate smoothly. They define standards for Usability, Reliability, Security, Accessibility, Performance, Information Architecture, Portability, Extensibility, Internationalization, Integrity or anything that would help the success of the system in real-world.

Example:

  • Performance: On successful login, user shall be redirected to the landing page within 10 seconds (max)
  • Maintainability: Proper logs stating the operation result with timestamp shall be added on every login/signup/forgot password click
  • Platform: The login functionality shall behave same on different platforms (Windows/Linux)

Tip to identify:

To easily identify between these, functional requirements can be considered as “verbs” and non-functional requirements as “adjectives” on these “verbs”.

Transition (Implementation) Requirements: These define conditions or capabilities only required to enable transition of the solution from development to real-word business use. It describes what must be done with the process, technology, education, training, enhancements before getting from the as-is into the to-be.

Example: Not valid in this example but for explanatory purpose: The login system shall behave same once "Single Sign-On" functionality is implemented

Tip to identify:

Look for temporary requirements such as “migrate from old system to new system”.

There are many other types of requirements that are used across diverse types of systems based on the scope such as:

Technical Requirements: Once the solution requirements are clear, the best way to start with the development frequently involves technology. It is a way to communicate between analyst and engineers (programmers, architects, designers) and is often written by the technical engineers. These requirements specify design and architecture for the solution components to be developed and implemented. They define how the solution will be programmed, store data and display data.

Example:

  • Browser support: Current and recent versions of Firefox, Edge, Chrome, Internet Explorer, Safari, Opera
  • Requires browser to have JavaScript enabled

Tip to identify:

Technical jargon's are used such as “password encryption algorithm” and “database schema” etc.

User Interface Requirements: These define the user interface design for the functionalities (derived from solution requirements). The placement of user input controls, buttons, links etc. on screen to allow the working of the functionality. Generally represented with wireframes.

Example:

  • Textboxes for username and password shall be placed below the respective labels for Username and Password
  • Login and Cancel buttons shall be present in center of the screen
  • Sign-Up link shall be present below the Login button
  • Forgot password link shall be present above the Login button

Requirement analysis is all about understanding, identifying and categorizing these requirements. With categorized requirements, it becomes much simpler for the team to understand and follow the system details.

#requirements

This entry was published on Apr 10, 2017 / Surbhi Mahnot. Posted in Requirements Analysis (BABOK KA) , Requirements Management and Communication (BABOK KA). Bookmark the Permalink or E-mail it to a friend.
Like this article:
  40 members liked this article

COMMENTS

Dan Tasker posted on Tuesday, May 7, 2019 6:40 PM
Surbhi

Sorry I've come to your blog so long after it was posted to provide my comment. I would suggest you revisit the example of a Business Requirement you have given in relation to the definition of what a Business Requirement is that precedes the example. I believe your example is not at the 'organization' level.

Also, the term BRD is an older term, still used as a title for requirements. But the "Business Requirement" part of that title pre-dates the IIBA BABOK definition of the term. Such documents are more about Stakeholder and/or Solution Requirements. Business Requirements are more likely to be documented in a Business Case, prior to a project being initiated.
Dan Tasker
Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN

 



Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.

 




Copyright 2006-2024 by Modern Analyst Media LLC