Agile Requirements Engineering

Properly identifying and implementing requirements is the key to a successful project. But what’s the best way to go about this? In classic project management, projects typically begin with a business case and a project charter. These documents serve to specify a project’s general requirements. After that, detailed planning begins. A work breakdown structure is generated which is used for planning tasks and estimating costs. This procedure is based on an array of assumptions and has many problems. In this entry, I’ll look at and explain these problems more closely.

Classic Requirements Engineering

All the way into the 2000s, software development projects were managed with classic methods. This means that projects were planned, specified, and sequentially structured in a way similar to architecture projects. Against this trend, however, a handful of forward-thinking IT experts came together in 2001 to devise the Agile Manifesto. These experts were frustrated by the inflexibility and constraints of classic project management, which proceeds from certain assumptions; for example, that software projects can be planned completely at the beginning, that requirements don’t change during the projects, and that important stakeholders and business cases can be and are correctly analyzed at the outset. In other words, classic management assumes that, when a project enters the implementation phase according to specifications and planning, everything important has already been completely determined, communicated and won’t change, and that the team will implement everything exactly as planned. In reality, this works out in very few cases, mainly for projects with low complexity.

What problems are associated with classic project management?

During specification of requirements, the following may occur:

• at the beginning of a project, not all important stakeholders are recognized
• important stakeholders or user groups change
• the business case is incorrectly prepared
• users behave against expectations
• users’ expectations change during the course of the project

While communicating requirements, the following may occur:

• important information is lost along the way from business analysts and requirements engineers to the responsible team
• requirements are misunderstood or interpreted differently by the team
• requirements cannot be technically implemented as specified

In the course of realization, the following can occur:

• Users change their minds about requirements for the system, but the development team, business analysts or requirements engineers aren’t aware of this
• More requirements creep into the project or are modified, but the team, the project manager or the requirements engineer don’t notice (Scope Creep)
• Incorrect implementations of requirements due to poor knowledge of the testers or to failed communication with testers, which are then mistakenly accepted as correct.

The other problem with classic project management is its monolithic development cycle. In other words, testing and release only happen once and always at the end of the project. This makes it impossible to get early feedback from users and changes aren’t released in a timely manner. Basically, the product is implemented as specified at the beginning.

Agile Requirements Engineering

Responsibility, Communication, and Participation

In contrast to classic project management where business analysts and requirements engineers are actively involved only at the beginning and after that are, in the best case, just there to answer questions, agile process models integrate Scrum cross-functional teams. These teams facilitate active knowledge transfer. Another role in Scrum is the product owner who manages all stakeholders and identifies all requirements for the product on a just-in-time basis. In contrast to classic project management, where the business analyst is only involved in a preliminary phase, a product owner works together with a team and is actively involved in the creation of the product.

The product owner is there to stay on top of answering one essential question: Are we, the Scrum team, building the correct product? She is completely and fully concerned with the “What?” and is constantly on the lookout for new requirements.

The product owner:

• analyses business processes
• derives visions from business strategy
• takes care of stakeholder selection
• manages communication with stakeholders
• determines the stakeholders’ requirements by utilizing various requirements engineering methods and tools
• selects key users and invites them to review meetings
• regularly updates the product backlog with newly gained knowledge and re-prioritizes existing requirements

Inspect and Adapt

Agile approaches have another major advantage: feedback.

Agile project management, Scrum most of all, requires that teams divide their work into micro-projects. These sprints are planned as small projects at the beginning, are accepted at the end, and presented and released to users. This allows active feedback from key users who are involved during sprint reviews. In case user requirements change intermediately, the Scrum team can react and incorporate the new findings in the project. Agile project management sees mistakes as learning opportunities and considers feedback to be a very positive thing. “Inspect and Adapt” is all about creating transparency and generating as much feedback as possible which immediately flows into the development process.

Requirements versus User Stories

There are also major differences in identifying requirements. In classic project management, requirements are formulated as demands:

The system must be able to keep personal data. This personal data must be editable, saved with encryption, and it must be possible to assign payment conditions. 

Requirements formulated this way are rigid and not related to specific problems. We describe what needs to be done and how something should behave, but the reason why is left out. These criteria should be fulfilled:

• complete
• testable
• consistent
• error-free
• design-free (in the water fall model the design phase occurs only after the specification phase)
• clear and unambiguous

In contrast, agile projects identify requirements through user stories:

As a user of this app, I want to record my personal data in the first step after opening the app, and then later be able to sign all transmitted documents with my signature. 

User stories are always defined according to the following pattern and serve to clarify the “Why?”:

As … I want to … in order to … .

User stories are seen as being:

• independent
• negotiable
• valuable
• assessable
• small and contained
• testable

In order to reach the goal – in other words, to achieve the purpose in the Why? – the team is not given very much specification in advance. The user story is, however, supplemented with acceptance criteria in order to ensure testability and to determine the minimal requirement.

Conclusion

The main difference between agile and classic requirements engineering is that agile engineering continually accompanies the implementation process and constantly delivers just-in-time requirements. It’s thus easier to react to changes and user feedback can flow directly into product development. As a rule, this leads to the creation of better products with higher usability.

Read more from David Theil at his blog: https://digitalisierungscoach.com/