Category Archives: Business Requirements


Understanding Nonfunctional requirements

Requirements are defined as the conditions or statements which meet the demands of the clientele and the stakeholders. Requirements are documented in order to help the different teams to understand their responsibilities and organizations’ needs and the prospects. The business requirements are broadly classified as functional requirements and non-functional requirements.

Functional Requirements: The statements or conditions which are defined to satisfy the logical aspects of the software are covered under the functional requirements. These statements explain the different aspects of the application/software to be developed. These functional requirements are elicited during the requirement elicitation process headed by business analysts. The elicitation process is carried out in order to pull out the different angles associated with the requirements and to understand the viewpoint of different stakeholders. The most commonly used elicitation techniques are Interview, Brainstorming, Prototyping, reverse engineering, document-analysis and many others which are used as per the requirement and the comfort level of the business analyst or someone wearing the hat of the business analyst.

Nonfunctional Requirements: The statements or conditions which support the usage of the application or the software and which help in aligning the functional requirements are considered under the non-functional requirements. The non-functional requirements are defined to explain the different abilities  of the software developed. The non-functional requirements are also termed as non-behavioral requirements or quality attributes defined in order to support the quality analysts to approve the software against the different constraints which must be met. They define the overall attributes of the end product.

There is no definition to identify the difference between functional and non-functional requirements and there is a very thin line of difference between two categories. It entirely depends on the experience of the business analyst, details captured during the elicitation process and the constraints or limitations defined for the resulting product to categorize a certain set of requirements into functional or non-functional requirements. This thin line of differentiation between two categories sometimes doesn’t able to limit the functionalities to get categorized into two categories and there are certain conditions where a feature is captured in both functional and non-functional requirements using different expressions or syntax.

The different abilities or the checklist supporting the non-functional requirements are mentioned as below:

  • Availability: It defines the percentage availability of the system which is expected at the time of the system operations. The hardware capacity of the system is designed referring to this availability percentage of the software or application. The details are approved by the business owners and documented by the business analysts during the business requirement documentation.
  • Usability and Reusability: This defines the convenience by which the system can be used by the intended users. This ability of the system explains the capacity of the software to be learned, installed and used by the business users. How easily the users can be trained on the system defines the usability of the software. Some softwares are designed to be used for the development other systems which have common components. This capability is known as reusability of the software. A software is considered as well designed and developed if it can be used for other softwares with some common features.
  • Reliability: A software is authentic if the user can rely on the features of the software and its usage for longer duration. This feature of the software helps the organizations in choosing the product for their sensitive data. The demand of the product is directly proportional to the reliability of the software. The product or software is reliable if it’s also stable. The business owners prefer the stable product in order to get the higher availability of the same for the users.
  • Flexibility: There should be always a scope of the extension of the functionality within the developed product. This feature is known as flexibility. The software is designed in such a way that it should provide a room for expansion even after the deployment of the end product. The flexibility of the product depends on the design and techniques used for the development of the product and thus a business analyst has to take care of certain steps while finalizing the software design and development techniques.
  • Supportability: This feature of the software or the product is massively used during the maintenance phase. The ability to deploy new releases, alter the code, customization as per the users’ locations are covered under this feature. The customization of the product should not hamper the international usage and it should target the local users only.
  • Performance: How well the software performs at different timings for different number of users is defined under this capacity of the software. There is a common agreement on the performance of the software which is signed off at the time of BRD sign-off and it helps in designing the software and hardware structure of the product accordingly.

There are no proper methods present or followed by different business analysts in order to derive the non-functional requirements. This is because the abstraction level of the non-functional requirements are not similar to the functional requirements and for different softwares or products the set of non-functional requirements changes. Some nonfunctional requirements are difficult to define or express due to certain constraints which are evolved during the design and development and thus they are not included during the documentation process. As there are no guidelines or rules comparing with, the non-functional requirements are sometimes secluded or undermined which may result in the catastrophe during extensive usage of the software.

Different stakeholders have their own understanding and in turn requirements. This is also true in the case of the non-functional requirements. The stakeholders’ requirements thus should be catered separately and their needs should not be treated as a landmark while testing the non-functional requirements.

Nonfunctional requirements thus are treated as an important aspect while designing the software and these requirements should be analyzed, precisely measured and developed accordingly for the successful implementation of the software and usage of the end product.


Happy Reading!!!

Requirements Prioritization

Requirements once elicited and approved from the authentic sources are further put for analysis and the first step in the process of requirement analysis is to prioritize the requirements in the order of their implementation. It is mandate for business analysts to prioritize the requirements as it’s a process to add value to the deliverables. The business analyst (or the one seated on the business analyst’s chair) has to consider certain factors while prioritizing the requirements so that the smooth process can be implemented. These factors or aspects which are considered at the time of prioritizing the requirements are: importance, risk, cost, benefit, time, strategy etc. The software development is a set process and the requirements are said to be changing till the final version is deployed in the production environment for the end-users and thus its a challenge for a business analyst to keep track of the requirements and alter the priority with the progress in the development but the decision on prioritizing the requirements depends on the decisions made by the stakeholders involve in the project and business analysts being a liaison between different stakeholders have to co-ordinate the activity.

Why to prioritize the requirements?

Eliciting the requirements and fit them into the releases to develop the functionality is a major step towards the success of the development of the software/project and it’s very important to understand the risk of not prioritizing the requirements. In the words of Frederick P. Brooks, “The highest single part of building a software system is deciding precisely what to build… No other part of the work cripples the resulting system if done wrong. No other part is more difficult to rectify later” Thus to mitigate the risk of re-work in the later part of the development, it’s advisable to define the requirements and prioritize them before starting the implementation. In simple words, “No matter prioritization technique is considered simple, medium or difficult it’s a fundamental activity for successful implementation.”

Continue reading

Requirement Management

Requirements Management

Requirement ManagementThe gap between “what we know” and “what we think we know” is filled by the knowledge and the experience. What we know is about the facts and what we think we know succinct the assumptions. This is marked as the baseline for the business analysts (or the one seated on the chair of BA) during the requirements management and thus the BAs have to strive always to maintain the credibility of the requirements throughout the project life-cycle. The most appropriate way to mitigate the chances of bogus requirements getting developed or documented is to frame questions and avoid muddiness. The BAs are advised to focus on the different aspects of the requirements and then frame questions to nullify the chances of any ambiguity during the requirement elicitation and documentation.

What is Requirement?

Referring to the world of dictionary, the requirement is described as, “Something which is necessary and must be fulfilled to achieve the result”. Requirement word itself is self-explanatory and sometimes begets a cringing feeling (especially with the phrase “change in requirement”). But this should not happen with the BAs as they have the primary tasks to manage and maintain the requirements’ credibility throughout the life-cycle of the project.

Continue reading

communication techniques

Requirement Communication

Requirements are the spine to any project. The more precisely requirements are gathered and analyzed; the more effective becomes the implementation. Thus it is important for a Business analyst to understand all the details of the requirements shared by business owners and subject matter experts and more importantly communicate the same to different stakeholders on time to avoid any delays in the implementation. Communication is one of the pillars of the project and it helps in explaining the tasks and responsibilities to different stakeholders. Business analyst being a bridge between different stakeholders is responsible for managing the requirements throughout the project life cycle. Proper and on-time communication of the requirements helps the stakeholders to reach the common understanding and which results in on-time and hassle-free implementation.

Requirements once elicited, analyzed and documented should be communicated to different stakeholders to maintain the authenticity of the same. Business analyst manages the requirements throughout the project life-cycle, thus it becomes his core responsibility that everyone involved in the project implementation should know the details of the requirements. The documents prepared with the requirements (functional and non-functional) details should be validated from the business sponsors. Solution design and assessment is done on the basis of the requirements elicited and thus it’s very critical that the designers and architects should know about the requirements and variations as the design is completely influenced by the nature of the requirements. There are certain methods followed by different business analysts to communicate the requirements including presentation and workshops but the end result is to convey the meaning and the stakeholders should be able to understand all the details.

Continue reading


Requirement – Techniques and Characteristics

Requirement is defined as the most important attribute of any business which must be delivered to provide the value. As per BABOK, a requirement is a condition or capability that must be met or possessed by a solution to satisfy the contract, standard, specification or other formally imposed documents and hence it becomes one of the key objectives of a business analyst to elicit and document correct and unambiguous requirements.

Requirements are broadly classified into different sections and this classification defines the criticality of the requirements. The higher level goals, objectives and needs of an organization are classified under business requirements. The business requirements define the reasons of project initiation and these requirements should hold the validity throughout the project life-cycle. Business runs with the stakeholders and the requirements of these stakeholders should not be ignored. These stakeholder requirements describe the need of the stakeholders and how they interact with the solution. Later comes the functional and non-functional requirements which describe the behaviour and information that the solution should posses including the different environmental conditions in which these solutions should retain its validity.

The term requirement generates a lot of discussion and many debates happen to qualify the list of those requirements that should be added to the final version of the requirement document or not. It’s important for business analysts and owners to work closely to classify the requirements and to avoid the ambiguity. The business analysts and developers can’t accurately judge the completeness or correctness of the requirements whereas the normal users can’t assess technical feasibility and hence it becomes very important to verify the requirements during elicitation.

Continue reading

BRD: Really a Need or Time-Crusher?

BRD: Really a Need or time-crusher?

BRD-timecrush1BRD-timecrush2As a BA the one thing which strikes in our mind is to design a high a quality BRD (Business Requirement Document). In my last post I have written an overview of BRD which includes the features of a good quality BRD. Few days back I was attending a webinar on the same topic in which the presenter was discussing all the details. It was really interesting to know that BAs devote most of their times in designing an easy to understand document which contains business requirements. A BA first discusses the details with different stakeholders do the brain storming and then designs a document using all his writing skills to make it as simple as possible so that the others can understand the requirement and the project can run smoothly…. Oh God how much intelligence required in that!

But this all gave me a thought that after designing a document of 100+ pages with all the efforts to include the business requirements will the document find the intended audience? Will that document find space in the INBOX, which is usually flooded with other mails (in a survey it was found that the business decision makers usually get 85+ mails per day), of the stakeholders and will all of them spare their time in reading those 100+ pages? I think NO. So if the answer to this is no, then why BAs are devoting their time in designing BRDs. Documenting a requirement sheet will require tremendous efforts in organizing, double-checking, typing, copying, pasting etc which will turn out as 85% of clerical job and in turn it will reduce the strategic competence of a BA. Thus it can be accepted that a BA who is sparing 85% of his energy in doing clerical job can’t make impact on the organization with his strategic skills. Continue reading

Business Requirements Document: An Overview

Business Requirements Document (BRD)

BRD-documentBRD, an acronym of Business Requirements Document is widely accepted structured document for project requirements which defines what should be delivered in order to gain value in the project. This document is designed to assist with the project management and the implementation during the entire life cycle of the project. Business requirements are consist of both functional and non-functional requirements which lead to creation or update of product, system or a software. BRD mainly emphasize on what should be the end result and it doesn’t bother how the objective is achieved.

There are many variants of BRD known to people like SRS (System Requirement Specification) or SRD (System Requirement Document) and FSD (Functional Specification Document). BRD can be described as a mode of communication in completion of a project. The main objectives of a BRD are as below:


  1. It should be simple and all the involved stakeholders should agree to it.
  2. It should contain more business requirements rather than technical requirements, as the main motto of a BRD is what to achieve and not how to achieve.
  3. It should describe the business needs in clear and concise manner.
  4. It should have a logical flow and can be used as an input for next phase of the project.

Continue reading