The Community Blog for Business Analysts

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.