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.

Elicitation one of the knowledge areas defined for business analysts is a key task as it serves as the foundation in documenting the requirements. Requirements are identified during the elicitation but it’s analysed, documented and verified throughout the life-cycle. No requirement is complete at the time it’s documented and the option of changing or deviation is always open till it’s implemented. Please note that sometimes the implemented solution gets changed due to change in requirement. Thus the elicitation is not an isolated or categorized activity and there are several techniques which can be used to suffice the process depending on the skills of the business analyst, different environmental factors and domains. Some of these elicitation techniques can be listed below:

  • brainstormingInterviews – Conducting face-to-face or calls to understand the requirements with the business owners. Business analysts have to do detailed home-work before conducting interview sessions to avoid any gaps in the requirements.
  • Brainstorming – It is the group session conducted to list the ideas contributed by different stakeholders to lock the final requirements. It is more useful in enhancements of the existing functionalities.
  • Prototype – It’s the idea of preparing some mock-ups to set as an example to elaborate the requirements. The mock-ups are prepared by business analysts after having discussions with different business owners and other stakeholders. Once the prototypes are prepared, it can be sent to SMEs for proof-reading and later presented before business owners to avoid any ambiguity. Believe me it requires skill to prepare mock-ups and there are different tools available which can be used to prepare these prototypes
  • Document Analysis – It is about reviewing the existing documents related to the functionality.
  • Observation or Shadowing – It’s about learning the details by observing the people doing tasks, more like On Job Training (OJT).

There are many other elicitation techniques followed by different business analysts depending on the nature of the work and domain.

How to classify credibility of elicited requirements?

Once the requirements are elicited and documented its become very important to qualify those requirements as unambiguous and accurate so that there would be minimum deviation and in turn minimum re-work. The quality of elicited requirements by a business analyst is inversely proportional to the amount of work against them and also defines the skills of an amateur or professional business analyst. The role of business analyst in this phase is very critical and he should not get bemused and bewildered with equivocal statements or business needs instead he should sit back and understand the meaning of the requirements and get it cleared from the stakeholders, if required. Business Analyst elicits requirements but he has no control on the deviations, thus to avoid ambiguity there are certain characteristics of the requirements, some of them are listed below:

  • Complete: Each requirement should be complete before the actual development starts. It’s recommended to divide the project requirements into smaller chunks or modules to have clear understanding. Scrum or iterative or incremental mode is beneficial for development and more productive as it has the scope to cater the requirement deviations.
  • Accurate: There should be no conflict in the set of requirements. It’s like maintaining proper relations between parent and child requirements. e.g: Parent: Customer can open account in bank. Child: Customer can open savings, current etc. type of accounts including FDs and ULIPS etc. In this case all the possibilities which can come under parent requirement should be properly defined and unambiguously.
  • Executable: The limitations and capabilities of the requirements should be defined at the time requirements were frozen so that the feasibility of their implementation is known to the responsible teams.
  • Authorized: The requirements approval is the accountability of the business owners and thus all the documented requirements should be authorized from the relevant team or individual. This is quite necessary to avoid any unrealistic or unnecessary deviations during or after the development. This is also necessary because the different stakeholders have different viewpoints thus the frozen requirements should be authorized before bringing it before the development and implementation teams.
  • Prioritized:  Each requirement is defined with the remark of urgency and criticality against it which defines the priority of the implementation. It also helps the team involved in developing the chunks of the requirements. They will pick the high priority requirements first and in turn it develops the trust with other stakeholders.

There are certain other characteristics which make requirements unmistakable and more apparent including the unambiguous requirements, the requirements which can easily be verified i.e. the test cases against these requirements can be designed easily, the non-repetitive requirements and many more….

Happy Learning!!!!

2 thoughts on “Requirement – Techniques and Characteristics”

Leave a Reply