Tag 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


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

BA: Do you really understand the business need?

BA: Do you really understand the business need?

business-needI think this time the topic is quite rude and primitive. The aspiring BAs may feel it more hurting if someone asks them if they understand the business need, business case or some other heavy term related to business. But I believe this is very basic and fundamental question to all BAs as if they don’t understand the need of the business, they will not be in the position to analyze it.

We always talk about requirements and their management, stakeholders and their views but very few people I have seen talking about business need. For me the bigger question is “do I understand the purpose of the project to which I am involved”. If the answer to this is no, then there is certainly a gap between the team working and team manager. The business need is required as it helps to determine the use of the project. It will have a emotional attachment with the team and in turn team will perform better. Continue reading