Common Misconceptions About Requirements Engineering

Conflation of Requirement Types

Business analysts often confuse different requirement levels and types. One challenge is understanding the classification of requirements, while another is grasping the fundamental types.

Business analysts often mistakenly use terms like “system requirements” and “user requirements” interchangeably, when in fact they refer to elements at different levels of abstraction.

System Requirements describe the properties and operations of the system being worked on.

User Requirements represent the needs of stakeholders in their role as users, without specifying the system functionality.

Similarly, non-functional requirements, also known as quality requirements, are often misunderstood. Quality requirements focus on the qualitative aspects of the system, such as usability, performance, and security, rather than project schedules or costs.

Another important type is Domain-specific requirements, which pertain to properties within a specific business domain, such as regulations and standards.

It’s necessary for Business Analysts to use precise terminology to prevent misunderstandings and expenses down the road.

Stakeholder Primacy

Many people assume that stakeholders are the sole providers of requirements. However, IREB emphasizes that requirements actually come from the system context, which is not limited to stakeholders.

Within the system context, there are various sources of requirements. These include documentation, other systems, and business processes that need to be implemented by the system. While stakeholder information can be used to derive requirements, this approach may be incomplete or inefficient.

Instead of solely relying on stakeholders, business analysts should also consult the organization’s documentation for the same information. This includes documents related to business processes, rules, tasks, procedures, and industry regulations. Failing to recognize these sources can result in a flawed system design and the omission of standards and specific business rules.

Likewise, requirements can also come from systems already in use within the customer’s organization, similar systems, or competing systems. Therefore, it is not always necessary to extract needs and expectations solely from stakeholders.

Business analysts can take the initiative by initiating the process, analyzing similar solutions, and proposing initial suggestions to stakeholders. This not only assists stakeholders in their work but also demonstrates desirable qualities such as initiative and proactivity in business analysts.

Only “technical people” can write requirements for a software project

The myth that only “technical people” can write requirements for a software project is not accurate. While technical knowledge and expertise can certainly be beneficial when writing requirements, it is not the sole determining factor.

Any reasonably sized product or application is likely to have numerous stakeholders, each with a unique perspective that can provide real value.

For example, you may find that your operations or technical folks can provide excellent business requirements, or you may find that your business stakeholders can articulate important nonfunctional requirements that could have been missed otherwise.

Here are a few reasons why this is a myth:

1. Domain Expertise: Non-technical individuals who possess in-depth knowledge of the industry, business processes, and user needs can contribute significantly to writing requirements. They understand the context and can ensure that the software aligns with the specific goals and requirements of the organization.

2. User-Centric Approach: Requirements should focus on meeting user needs effectively. Non-technical individuals, such as UX designers or product managers, can bring a user-centric perspective to the table. They can identify user pain points, define user stories, and ensure that the software addresses these requirements in a user-friendly manner.

3. Communication Skills: Writing clear and concise requirements is crucial for effective software development. Non-technical individuals often excel in communication skills, enabling them to articulate complex ideas in a manner that technical teams can understand. Their ability to bridge the gap between technical and non-technical stakeholders is invaluable.

4. Collaboration: Writing requirements is a collaborative process that involves multiple stakeholders. While technical input is essential, it is equally important to involve individuals from different backgrounds and roles. Collaborative requirement-gathering sessions can lead to more comprehensive and well-rounded specifications.

5. Validation and Verification: Once requirements are written, they need to be validated and verified by stakeholders. Non-technical individuals can play a vital role in this process by ensuring that the requirements align with the overall vision, goals, and objectives of the project.

Also, keep in mind that different types of requirements can come from unexpected sources. Avoid discounting requirements that come from unconventional sources. It might seem counterintuitive at first, but not all sources of requirements are people.

It’s important to avoid relying solely on your development team for requirements. When gathering requirements, different perspectives matter. People with expertise in a wide variety of disciplines should contribute. Cast a wide net to identify potential stakeholders in many areas of your organization, and don’t discount contributors from outside your organization.

Possible contributors could come from any or all of the following departments or groups: Business Leadership, Legal, IT, Development, Security, Analytics, Operations, End customers, End users, Research and Development, Engineering and Maintenance, Health and Safety, Audit and Regulatory Compliance, Human Resources, Independent third parties (outside experts).

In conclusion, while technical expertise is valuable when writing requirements for a software project, it is not exclusive to “technical people.” Involving individuals with domain knowledge, user-centric perspectives, strong communication skills, and a collaborative mindset can greatly enhance the quality and effectiveness of software requirements.