Common Misconceptions About Requirements Engineering
Disclaimer: The views and opinions expressed in this article are those of the author and may not reflect the perspectives of IIBA.
Receive free IIBA updates and exclusive content!
Business analysis encompasses various domains, including strategic analysis, requirements elicitation, life cycle management, solution design, and evaluation. One important concept that appears in multiple areas within the domain of business analysis is requirements.
Yet despite its importance, relatively few business analysts are aware of how to effectively handle requirements. And even fewer are aware of a specialized area of knowledge for managing requirements called “requirements engineering.”
While A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) covers requirement elicitation and requirement management, it lacks comprehensive information on requirements engineering. The result is that many business analysts lack a complete understanding of proper requirement handling.
To rectify this, business analysts should gain an understanding of the essence and classification of requirements. An excellent supplement to the BABOK Guide is the Certified Professional for Requirements Engineering (CPRE) certification from the International Requirements Engineering Board (IREB).
Another is this Institute of Electrical and Electronics Engineers Standard, which enhances the requirement classification presented in the BABOK Guide. It also discusses system requirements, particularly quality requirements and constraints, in detail.
Conflation of Key Types
Knowing the classification of requirements is one challenge. Grasping the fundamental types of requirements is another.Business analysts often confuse different requirement levels and types. For instance, the IREB terms “system requirements” and “user requirements” are often used interchangeably. Yet these aren't descriptions of the same elements—they exist on entirely distinct levels of abstraction.
System requirements describe the properties of the system (solution) being worked on—forming a layer that details how the system operates. By contrast, user requirements depict the needs of stakeholders in the role of users. They do not refer to the system functionality, as the solution is not yet defined. Rather, they define the basic expectations and needs of specific users without reference to a concrete system.
This is a significant difference, as user requirements relate to the business layer, not the solution layer.
Similar misunderstandings arise with non-functional requirements, also known as quality requirements. Non-functional requirements don't detail project schedules, milestones, or costs. Instead, they pertain to the qualitative aspects of the system, such as usability, performance, or security.
Another significant type is the domain-specific requirement, which identifies properties within a specific business domain—e.g., requirements from domain regulations and standards.
Stakeholder Primacy
There is a common assumption that stakeholders are the only source of requirements. In truth, requirements emanate from the system context, a point highlighted by IREB. Stakeholders are indeed part of the system context, but not the exclusive part.Within the system context, documentation, other systems, and business processes that must be implemented by the system are all sources of requirements. Although requirements can be derived from stakeholder information, this approach can often be incomplete or inefficient.
Instead of relying solely on stakeholders for information, business analysts should consult documentation within the organization, which can yield the same information. This includes business process documentation, business rules, task descriptions, procedures, and industry regulations. Failure to recognize these sources can lead to a flawed system design and omission of standards and specific business rules.
Similarly, requirements can emanate from systems already operating in the customer’s organization, similar systems, or competing systems. So extracting needs and expectations from stakeholders isn't always necessary.
We can initiate the process, analyze similar solutions, and propose initial suggestions to stakeholders. This not only helps the work of stakeholders but also demonstrates initiative and proactivity—highly desirable traits in business analysts.
Conclusion
Ultimately, there isn't a singular technique for requirement acquisition, nor is there a sole source of requirements. Requirements engineering encompasses more than mere requirement management. It constitutes a broad field that complements business analysis practices well. Delving deeper into this topic is undoubtedly worthwhile. I recommend consulting IREB CPRE publications available here. To start, explore the Glossary and the CPRE Foundation-level syllabus or handbook.
Want to explore more on this topic? Explore Requirements Engineering and Business Analysis – a Business Analysis Live Podcast here.
About the Author:
For over a decade, Karolina Zmitrowicz worked as an independent IT consultant, trainer, and advisor in requirements engineering, business analysis, and quality management. Today, she assists clients in streamlining their operations and production processes to achieve better business outcomes. In her work, she blends business and IT, drawing from a range of experiences and knowledge spanning testing, analysis, requirements engineering, process management, and user experience. She has provided advisory services, training, and support to organizations and teams in building competencies, and assists leadership in making informed business decisions.
