Why should we do Requirements Engineering?

Some people seem to have the option that agile projects don’t need requirements engineering. Or “they” don’t need it. Like some people think that speed limits are for those who can’t drive, this definitely enhanced your chances to crash - your car or your project.

Despite its time-tested significance, requirements engineering sometimes gets overshadowed by newer project management methodologies. But whether you’re managing a traditional project or adopting agile practices, the importance of a well-fitting(!) requirements engineering cannot be overstated. Of course, you don’t want to create a six-figure requirements engineering process for an internal project that will be six weeks of effort to build, but you don’t want to run into a 500 million disaster (Read: https://www.henricodolfing.com/2020/05/case-study-lidl-sap-debacle.html).

The Essence of Requirements Engineering

The official definition would be: Requirements engineering (RE) is the process of defining, documenting, and maintaining the requirements for a system or project. It involves understanding the needs of stakeholders and translating those needs into clear, actionable specifications. By engaging stakeholders early and continuously, RE ensures that the final product meets their expectations.

So far, this reads a bit academic. Why does it really make sense to talk to those stakeholders to not put your projects on stakes (sorry)?

Critical Role in Project Success

RE is essential because it lays the foundation for all subsequent project activities. It helps in:

• Clarifying Objectives: Ensures all stakeholders have a unified understanding of the project goals.
  • Consider a software development project aimed at building a new e-commerce platform. During initial discussions, a stakeholder might mention the need for “secure payment processing.” While this phrase seems straightforward, different stakeholders might interpret it differently based on their implicit knowledge and personal expertise. For instance, a business executive could envision secure processing as complying with industry regulations, while an IT manager might focus on robust encryption methods, while the programmer might say “hey, we are using anyway, we don’t care about this at all”. Here, RE plays a critical role in bridging these gaps by starting detailed discussions before the initiation, extracting implicit assumptions, and documenting explicit specifications. This process ensures that all parties have a cohesive understanding, minimizing the risk of conflicting interpretations that could derail the project.
• Minimizing Miscommunication: Reduces the risk of misunderstandings by providing a clear, structured set of requirements.
  • For example, a requirement like “create a new cart” might implicitly suggest that multiple carts can be created and used simultaneously, which could significantly increase the project’s complexity and timeline. Without explicit confirmation of this implication, developers might unknowingly invest time into developing features that were not intended. Here, RE helps by identifying such subtle assumptions early, allowing teams to agree on the exact functionality required and avoid unnecessary work.
• Facilitating Better Planning: Helps in resource allocation, timeline estimation, and risk management.
  • It is quite nice to know beforehand how many engineers you will most probably need, isn’t it? Maybe you’d even like to know after 6 months if you are halfway there, or just hit a quarter of the goals - how are you going to tell your superiors how far you are, if you never planned?
• Important: This does not say you can plan everything in advance. But you definitely can get a rough overview. And: Plans are made to be changed.

The Pitfalls of Ignoring Requirements Engineering

Neglecting proper RE practices can lead to significant risks and costs:

• Scope Creep: Inadequate requirements often result in unplanned changes mid-project, leading to scope creep. Adding Features is nice. Adding Features while core functionality is missing, is not. How do you know, if you didn’t plan your core?
• Increased Costs: Fixing issues later in the project lifecycle is far more expensive than addressing them early on. You need redundancy? High availability? Infinite Scalability? Or, kind of worse, you built them in, but you don’t need them at all? Now everything takes three times as long, although nobody needs this.
• Project Delays: Undefined requirements can cause delays as teams struggle to understand and implement vague instructions. The more intact your project team is - the more your team is allowed to question everything, the less impact this has. Still, every good developer plans his new functionality according to the interfaces it will (or not will) have - to all the other functionality.
• Stakeholder Dissatisfaction: If the final product doesn’t meet stakeholder expectations, it can lead to dissatisfaction and potential project failure. No use in a really fast system that can be started with one click if the result will be viewed a day later.

Requirements Engineering in Agile Environments

There’s a common myth that agile methodologies eliminate the need for requirements engineering. This couldn’t be further from the truth. Agile practices, such as Scrum or Kanban, still require well-defined requirements—they’re just handled differently.

How RE Fits into Agile

• User Stories: Agile uses user stories to capture requirements from the end-user perspective. These stories are concise and written in a simple format that includes the user role, action, and goal. At storywise, we also like to use them for upfront planning - if you are going agile or don’t move away from the plan, we don’t care too much. We think they are a good way to structure your requirements.
• Continuous Refinement: In agile, requirements are continuously refined through regular feedback loops, ensuring they remain relevant and accurate throughout the project lifecycle. Nobody stops you from refining well thought user stories in the mid of a project - to talk to the stakeholders and clarify if we still need that specific functionality, or if it should be built another way. The nice thing is, now you maybe already have an effort coupled with that specific feature, you only need to negotiate the difference. Maybe you can even tell your customer: Feature Y is not needed anymore, you now got 5 days more for additional features, like X and Z that you wanted to have additionally.
• Prioritization: Agile frameworks prioritize requirements based on their value to the user and business, focusing on delivering the most critical features first. It definitely helps to know which stories you really have to develop to make this work. You can always reprioritize - after talking to your devs, because sometimes changing the prioritization in the mid of a project can lead to severe effort.

Debunking the Myth

The myth that agile means no requirements stems from a misunderstanding of agile principles. Agile methodologies advocate for flexible and iterative development, but this flexibility relies on having a solid foundation of well-understood requirements that can adapt as the project evolves.

Think of a house: You should know beforehand, if you want to add a garage. You also need to know if you want to add a swimming pool on top - you just have to structure your support beams correctly before. If you want to lose a lot of money, let them build a normal house first and then add beams strong enough to hold that pool.

The Human Factor

Effective requirements engineering isn’t just about processes and documentation—it’s about people. Clear communication and collaboration between project teams and stakeholders are crucial.

Importance of Communication

• Stakeholder Engagement: Regular communication ensures that stakeholders are continuously involved, providing feedback and clarifying requirements as needed. This should happen in agile and in non-agile projects. If you create your requirements before, its easier to know what to discuss.
• Team Collaboration: Encourages cross-functional teams to work together, understanding different perspectives and expertise to shape well-rounded requirements. It is easier if it is clear what things have to be discussed, because there is a plan.
• Conflict Resolution: Open communication helps resolve conflicts early, preventing issues from escalating and disrupting the project. It also helps to know before where you are going to - because it allows you to plan before, and you don’t have to add time-pressure to the boiling conflict.

Sidenote: Nothing kills developer morale more than ever-changing requirements.

A Call to Action

For organizations to truly reap the benefits of requirements engineering, there needs to be a shift in mindset and culture. Prioritize RE as a fundamental part of project planning and execution. Here’s how you can start:

• Invest in Training: Equip your team with the skills and knowledge to perform effective requirements engineering. Create the time for it - allow it to take some time, before the project (or sub-project) starts.
• Foster a Collaborative Environment: Encourage open communication and collaboration among all stakeholders. Ask the customers if you got it right. Ask your developers if they’ve got questions. Discuss upcoming questions, don’t decide it for your customers.
• Adopt RE Tools: Utilize tools like storywise to streamline the requirements process and ensure consistency and traceability without worrying about stuff like formatting.
• Use Mockups: Using tools like Figma, you can show your customers what they are going to get. “I know it when I see it” still works best with the real app, but you can clarify a lot by showing your Idea of how the app will look like.

Conclusion

Requirements engineering remains an indispensable component of successful project management, regardless of the methodology used. Its principles help ensure that projects are delivered on time, within budget, and meet stakeholder expectations. By prioritizing RE, organizations can mitigate risks, reduce costs, and drive project success.

In an era of rapid technological advancements, AI coding helpers and evolving project management approaches, one thing remains clear—requirements engineering is, and always will be, the backbone of successful projects.

Written by Simon Jiménez, 2024