The Community Blog for Business Analysts

Heta Raval
Heta Raval

Possible types of Requirements to Discover

In a current scenario, when you are eliciting software service-based requirements then, you may be able to derive requirements in certain varieties. In the beginning, they can be just functional or non-functional requirements. But when you come across many other requirements as time goes, you can conclude requirements into several categories and will be able to take decisions...


As mentioned, requirements can be functional or non-functional. It is simple to determine both the type of requirements for an example, in a context to an e-commerce application, a user clicks on "Shopping Cart" button, they will be able to view the list of the total purchase to be done. So this can be a functional requirement, where there is a user need to 'View' their shopping cart.


Likewise, functional requirements, non-functional requirements can also be critical. They assure usability, performance, effectiveness, and security. If they fail to accomplish, then it can turn out failing the satisfaction of the business needs. For example, the payment procedure for any e-commerce site shall be secured and efficient enough to make the payment by the customer. These non-functional requirements are performance-based requirements which the stakeholder needs to establish.


There are mainly three types of requirements to elicit, which I have identified throughout my experience. As requirements can have a different type of business cases, domains, and demands, it is also essential to measure their outcomes. Therefore we need to identify which type of requirement is it.


  1. Business Requirements
    1. This type of requirements is based on assumptions as they are high-level specifications and collected from other business cases. Here the stakeholder has just an idea of his business obligations, but they are not knowledgeable of individual use cases.
    2. You need to take visualization in defining functional requirements. Imagine the workflow for the system and navigate the user functionalities with the flow. Once it has done, apply it by creating wire-frames. These wire-frames would help a lot to attract stakeholders as you are providing them the visuals.
    3. You can provide the blueprint or we can say the skeleton of the future website to ensure the stakeholder that you are visualizing the exact vision of the requirement.
    4. Visuals are more persuasive than a document which contains only written content. Visuals are more precise and easily understandable. It will give ease to keep the ball into your court because these requirements are based on assumptions which can be helpful to generate better revenue for your organization.
  2. Structural and Design Requirements
    1. A requirement which falls into this category is simple, and straightforward to extract because the structure, design, and layout of the project have already decided. So they are accurate, and the user navigation could have seen as mild. Also, they are more detailed than business requirements.
    2. The stakeholders are already fond of any other business cases, and they want the same type of outcome to get achieved. Therefore, it is easy to analyze this kind of requirement.
    3. You don’t need to worry about all the use cases for the requirement nor about layout and design. All you need is to analyze all the functionalities used within the given business case.
  3. System Integrated Requirements
    1. These are a very low level of the requirements where you will have system and integration to make into the system. It is a detailed narration of every use cases of the system.
    2. The stakeholders know the specific part of the development to get it done by you. You merely need to review their existing work and map it with the current requirement.
    3. They are having sufficient details so that developers can begin coding. But you need to be careful and aware of every functionality to make the requirements more effective.

Here, the conclusion to my thought will be that plan out requirement elicitation process and document all the functional, non-functional requirements so well with validation so that your team will be more efficient to work on it.

This entry was published on Aug 16, 2019 / Heta Raval. Posted in Requirements Analysis (BABOK KA) . Bookmark the Permalink or E-mail it to a friend.
Like this article:
  9 members liked this article


iPlace Consultancy posted on Thursday, October 22, 2020 6:23 AM
The role of business analytics is the future of your business to get new opportunity to defines your success. You can build the ultimate online community and resource portal for business analysts.
iPlace Consultancy
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