how to categorise requirements in business analysis

How to Classify Requirements in Business Analysis

Product development always gets off the ground by addressing an unfulfilled need identified among customers or by filling a gap within the peer products in the market. Those unfulfiled needs as well as market opportunities can be converted into a  myriad of requirements, both functional and non-functional. As requirements pile up, business analysts and project managers will need to adopt the requirements classification schema to identify levels or types of requirements in order to categorise the requirements.

According to BABOK Guide, published by IIBA, Requirements Classification Schema is part of the business analysis key concepts. Business analysts identify different information types for the requirements and their attributes as part of elicitation requirements. Categorising requirements ensures that each requirement is fully understood, atomic, unambiguous, complete, consistent, and easy to trace between different requirements group. In the light of Requirements Classification Schema, I will talk about a framework I always use to categorise the requirements in product development.

How to Classify Requirements in Business Analysis

Requirements categorisation in Business Analysis

1. Business requirements

Business requirements are the statements of business goals, objectives, and the desired outcome generated by a series of initiatives. These business requirements range from the short-term targets and objectives established within a business group and long-term goals to be achieved in an organisation as a whole. They are usually described as high-level requirements to guide the development of the change strategy, identify potential value, and meet business needs ultimately. A good business requirement should relay the four key elements:

  • A summary of statement: The executive summary to outline the overall business needs and the action required to fulfil the needs.
  • An introduction of current state: This section describes the problem, opportunities, and constraints(budget, scheduling, and resources) based on an understanding of the current state in an organisation.
  • Business needs statement: The statement explains what business needs should be addressed and what goals the project sponsors expect to achieve. Business goals are long term, ongoing and qualitative statements of initiatives. For instance, to increase customer satisfaction and improve revenue by boosting sales. These high-level goals can be further decomposed into objectives and strategies, which are more specific, granular, and measurable.
  • SMART: Albeit the nature of business goals, it is necessary to ensure that these business requirements are specific, measurable, achievable, relevant, and time-bounded.

Techniques to elicit and collect business requirements include interviews, workshops, benchmarking and market analysis (SWOT, PESTEL, Five Forces), business capability analysis, BMC, business case, and organisational modelling.

2. Stakeholder requirements

Stakeholder requirements work as a bridge between business requirements and solution requirements and describe the needs of stakeholders that must be satisfied in order to achieve the business requirements. They can be captured in stakeholder analysis and stakeholder engagement process, which provides a starting point to the design definition of solution. Typical stakeholder roles include business analyst, project manager, domain subject matter expert, implementation subject matter expert, operational support, customer, end user, supplier, regulators, testers, and project sponsor. Stakeholder requirements are identified after performing stakeholder analysis, which may include the stakeholders’ decision making authority, level of influence and attitudes in response to a change solution, readiness for change and interest in the outcome of a solution. Different stakeholders can provide different objectives and requirements even for the same solution. As a result, these stakeholder requirements may conflict with each other. Business analysts, with a neutral attitude, will need to address the conflicts during the requirements elicitation and definition process by understanding the overall business objectives, evaluating trade-off and set up risk registrar so stakeholders reach a consensus on the requirements.

Techniques to elicit and collect stakeholder requirements include interviews, workshop, observe the operation process, brainstorm, concept modelling, document analysis, business rules analysis, mind mapping, risk analysis and management and process modelling.

Source:  A Guide to the Business Analysis Body of Knowledge ISBN 9781927584026.

3. Solution requirements

Solution requirements describe the capabilities and qualities of a solution that meets the stakeholder requirements. They also describe the implementation of a solution in detail. Solution requirements can be divided into functional and non-functional requirements.

  • Functional requirements: They are a collection of requirements outlining the capabilities of a solution to manage system and behaviour. The capabilities may involve technical details, algorithm, calculation, data processing and manipulation.
  • Non-functional requirements: They are more of the description of the service quality and conditions that a solution must have, also known as quality attributes. Common aspects of non-functional requirements to look into include accessibility, usability, security, scalability, availability and reliability.

Techniques to collect and analyse function requirements include WBS, user stories, use cases, software requirements document analysis, design prototyping, acceptance and evaluation criteria, data dictionary and interface analysis.

Techniques to collect and analyse non-functional requirements include use stories, use case and scenarios, design prototyping, workshop, KPIs, non-functional requirements analysis.

4. Transition requirements 

Transition requirements depict the capabilities that a solution must have to facilitate the transition process into a future state or the desired outcome. They mainly address topics such as infrastructure transition, data conversion and migration, user access and acceptance, stakeholders’ preparation and transition, changes to policies and business rules, training and business continuity.

Techniques to collate and analyse transition requirements include data modelling, data flow diagrams, interface analysis, user acceptance testing, process modelling and analysis, functional decomposition, business rules and risk analysis and management.

Please follow and like us: