Agile Development with Musato Technologies – Musato Technologies
loader image

We enable business and digital transformation decisions through the delivery of cutting-edge ICT solutions and products...

Get inspired…

Agile Development — Why requirements matter

The clear benefits of agile development — better collaboration, incremental delivery, early error detection, and the elimination of unnecessary work—have made it the default approach for many teams. Agile methods are also being adopted by systems engineering teams to deliver the same benefits.

Some developers have questioned whether requirements fall into the category of unnecessary work, and can be cut down or even completely eliminated. Meanwhile, teams developing complex products, systems, and regulated IT continue to have requirements-driven legacy processes.

So how does requirements management fit in an agile world? This paper argues that requirements management can bring significant value to agile development in regulated IT and complex product development projects, and sets out the characteristics of an effective requirements management approach in an agile environment.

This paper explores the ways requirements management brings value to agile development.
But why stop there? To get a full, accurate picture of your data without blind spots, you should deploy predictive models that score your data against intended outcomes. And, use decision optimization that tells you, at the point of impact, just what to do.

Agile software development and its benefits

The 2001 Agile Manifesto proposes four basic tenets:

  1. Individuals and interactions are preferred over tools and processes
  2. Working software (or system components) are preferred over comprehensive documentation
  3. Customer collaboration is preferred over contract negotiation
  4. Responding to change is preferred over following a plan
    Agile approaches have a number of characteristics that make them attractive to both software development teams and systems engineering teams:
    • Ongoing collaboration with customers and openness to change: project outcomes can be more closely aligned to customer needs.
    • Incremental delivery of working parts of the system: greater certainty of delivery.
    • Early detection of errors and defects, and rapid customer feedback on delivered functionality: lower late-stage risk to projects and lower chance of needing to dedicate time and money to unscheduled rework.
    • Elimination of unnecessary work: agile projects can achieve sustainably high productivity.
    At a business level, agile can help improve stakeholder satisfaction by delivering higher quality products faster, at a reduced cost. At a project management level, agile can improve the predictability of delivery and responsiveness to necessary change. And at a technical level, agile can help developers and engineers focus on innovation and product development instead of rework and late-phase bug-fixing.

Learn why agile development appeals to both engineering and software development teams.

Why are requirements important?

Developers looking to eliminate unnecessary work may be tempted to eliminate or heavily reduce requirements management. First, it is vital to determine the value—and therefore necessity—of requirements in agile development. A key function of requirements management is to establish a common understanding between the customer and the project team. This understanding forms the basis for planning and managing both the project and the final product.

Low standard requirements management is a leading cause of project failure, and there is little evidence to suggest that things are different in an agile world. Agile emphasizes improving collaboration and understanding between the project team and the customer, which implies that requirements are actually more, not less, important in an agile world.

In general terms, requirements can be defined as any information relating to the business requirements for a new system or application, including textual requirements, use cases, diagrams, and feature descriptions. In the agile context, requirements will include user stories and epics. All these entities can be managed as requirements and will offer greater value and usability if they can be traced to related project artifacts.

Critically, requirements can be used to capture detailed information that may otherwise be overlooked in agile development. Agile processes such as Scrum typically use “backlogs” to manage the outstanding work, both within the project as a whole and within individual increments of work or “sprints”.
The agile backlog does not normally contain enough information to specify a complete solution. Information such as non-functional requirements, feature descriptions, stakeholder meeting notes, and architectural decisions, which are usually absent in the backlog, can be captured as requirements.

Characteristics of agile requirements management

The benefits of implementing agile requirements management must outweigh the costs. The key benefits come from the way in which the structure of the requirements and traceability information facilitates reasoning about the design when changes need to be made. All projects generate some level of requirements and traceability information, so the costs are really those incrementally arising from structuring and managing the information for maximum benefit to the project.

Agile methods stress better collaboration as a way to give engineers and developers the confidence that they are building what the customer needs, customers the confidence that they are seeing regular incremental progress, and project managers the confidence that the project is less likely to be derailed by unforeseen problems. As requirements are the basis of understanding and communicating customer needs, the requirements management approach must itself be collaborative. That means making up-to-date requirements available to all stakeholders, and setting up processes to ensure that stakeholder inputs are captured.

Traditional waterfall development is often not strictly linear. Rather, it may jump between requirements, design, architecture, and test definition. In fact, it can look a lot like agile. The key difference is that the output artifacts are presented as if they were developed in order. So for both agile and waterfall projects, a mechanism is needed for managing the relationships between artifacts regardless of their sequence of creation; for both development approaches, requirements management and traceability play a key role.

Agile methods can improve productivity by focusing on delivering working increments of functionality. For complex products and systems, and regulated IT, increments must generally include deliverables beyond the working system itself, such as evidence of compliance with standards, user documentation and support documentation. Much of the information for these deliverables is derived from project artifacts and must be reliably maintained as changes occur.

Requirements management and traceability tools are key capabilities for managing this information and, in conjunction with reporting tools, enable the supplementary deliverables to be automatically generated—eliminating a significant overhead.

It is important to document (and connect with traceability) the reasoning that underlies design decisions. This information is critical in evaluating the feasibility of changes. It also benefits later development and maintenance activities by ensuring that engineers can understand why the system was built the way it is. In an agile project, where change may be actively encouraged, this documentation stage becomes even more important.

Discovering errors early in agile development depends on adopting test-driven approaches. This means that test cases must be defined early, as each feature is developed. Here, it is vital to enable traceability between requirements, design elements and test cases, in order to ensure that the right tests are executed, test coverage is known, and the impact of test failures on delivered functionality is understood.

Improved responsiveness to change is a key driver for moving to agile processes. Agile shifts the focus from up-front planning to the delivery of working parts of the system and gaining rapid feedback on those deliverables. This shift of focus enables change to be more easily accommodated, as developers are not focused on a single, monolithic development activity. Also, because the customer feedback loop is shorter, less effort is expended on implementing change before the value of that work is known. However, accommodating change is still difficult, as there are many dependencies to consider.

Build confidence among engineers, developers and customers with traceability and insight to incremental progress.
Requirements management plays a vital role in change management, enabling changed requirements to be captured and compared to previous requirements, thereby providing an unambiguous definition of what has changed. Traceability provides the information structure to analyze the impact of change both in terms of system design and work impacts across the development lifecycle. Agile’s focus on responding to change means that requirements management and traceability are more—not less—important.

When should you write requirements and create traceability?

Agile focuses on eliminating waste. A key element of waste in product development is work that is done and then thrown away because changes occur. Creating detailed requirements too early in a project—for example, with the “big requirements upfront” approach typical of conventional waterfall development—invites this kind of waste. Instead, requirements in an agile project should be just enough to specify a high-level outline of the project at the outset, with the details being added along the way.

There is still a need for initial requirements capture and analysis to define the project vision and scope. Beyond this, detailed requirements and traceability can be created to help understand and decompose items on the backlog, and to capture decisions as they are made.

Agile sees change as an opportunity to better align projects with customer needs rather than an impediment to delivery. Requirements are the means of formally capturing customer needs and communicating them unambiguously to the project team. Therefore, updates to requirements and traceability should be a fundamental part of agreeing and implementing changes.

It is critical that requirement and traceability information can be captured at the same time as design artifacts are created. The essence of agile is to do the right thing at the right time; attempting to create traceability after the fact is not only inefficient but also error-prone.

Eliminate waste by capturing requirement and traceability information as design artifacts are created.

The engineering activities in agile development are not linear; to deliver working increments of a system or software requires constant iteration across all lifecycle processes. Agile requirements management must therefore be tightly integrated with other engineering activities and their associated tools, including architecture, design, testing, change and configuration management, and workflow planning and management.

Streamlining requirements management

To develop a clinical information application for its parent company, Montefiore Medical Center, Emerging Health IT implemented agile development methods with a focus on managing requirements using the latest software development tools. Contact Musato Technologies to learn more about our software development solutions.

Gideon E. M
Author: Gideon E. M

Gideon Ebonde M. is the CEO and Chief Software Architect at Musato Technologies. He is experienced Software developer with a demonstrated history of working in the information technology and services industry. He has a strong engineering professional skilled in Mobile Application Development, Enterprise Software, AI, Robotics, IoT, Servers, Cloud and business application. He is an accomplished DevOps software engineer and a visionary computer scientist and engineer.

Leave a Reply