Melpomene - Fotolia
How to tame ever-changing requirements in software development
When one sprint ends, another begins -- but not before you receive a heaping new pile of requirements. Here's how to deal with requirements changes efficiently, every time, any time.
In Agile development paradigms, new project requirements and goals can appear unexpectedly, while established requirements can shift numerous times. Change is a frank reality of development, and successful teams must deal with the dynamic work environment.
Changing requirements in software development result from internal issues, like defects, as well as external pressures, such as a new competitor. Grasp which disruptions are most likely to occur and put processes in place to handle them. Then, consider some tactics that can ease the interruption of requirements changes.
Why software requirements change
Although there are myriad surprises waiting to derail any project, most changing requirements in software development fall into six general categories:
A requirement gets overlooked. A software build is a complex endeavor with a long list of Functional requirements; stakeholders can easily forget one. While typically minor, when a team misses a requirement it can still significantly disrupt the project through refactoring, infrastructure changes and additional testing.
A new defect. The development team generally groups a bug fix in with requirements. As the team identifies and documents defects, particularly problematic bugs can quickly become high-priority requirements.
Shifts in market demands. Software must meet its users' needs. The needs and wants of a user base can impose requirements on a project at any time, not just at the start. Features and functionality seen in competing products can filter into the project, while user feedback or change requests can add to the requirements list.
Miscommunication. Requirements result from collaboration between the stakeholders and the development team, and the communication isn't always 100% clear. When a development team misstates or misunderstands an existing requirement, it must correct the issue, essentially creating a new requirement. For example, a latency requirement erroneously stated in milliseconds instead of microseconds could seriously redirect the way the team writes and tests code.
The organization changes. Changing requirements in software development are sometimes a matter of corporate politics. Stakeholders and support within the business influence software. The priorities and preferences reflected in one stakeholder's requirements might supplant others due to a power play.
Laws and regulations change. Software serving certain industries falls under the purview of specific laws and regulations. For example, healthcare regulations drive software requirements for data encryption and backup protection in a project. Similarly, financial regulations influence the software requirements for logging and auditability in transactions through the application. Requirements must adapt to account for any new or updated regulations throughout the project and the application's complete lifecycle.
Waterfall vs. Agile requirements
In a Waterfall methodology, the development team gathers a complete set of requirements at the start of a project, often through a long and detailed planning period. Developers fix requirements early in the project's lifecycle, which makes changes difficult and disruptive to implement. A complaint about Waterfall is that fixed requirements create stakeholder dissatisfaction -- there's no way for developers to accommodate change.
With continuous development methodologies such as Agile, the project's lifecycle is a series of relatively small iterations. The project starts with a set of overarching goals, but the group can always evaluate, reevaluate and change requirements for what is being built and how it should work. It's impossible and undesirable to put a freeze on changes to the software's requirements early in the product lifecycle, as one does in a Waterfall approach. Users and stakeholders can bring up new ideas at any time.
Basics of Agile software requirements
Every iteration cycle in an Agile development methodology should start with gathering requirements and prioritizing them in a list, sometimes called a stack, from most to least important. Collaboration and communication with stakeholders ensure that changes, new features and fixes get organized according to stakeholders' values. Seek to identify requirements project members overlooked or misstated at this stage, before development work begins.
Once the team sets its requirements for an iteration, the project manager assigns the requirements as tasks to developers for implementation and testing. This process ranges from informally organized shared work to specific individual and team assignments for components such as API management, UI design and network code. The project manager might defer lower-priority tasks or ones that require more analysis to the next iteration.
With tasks in hand, software architects and developers plan how a feature or function in the requirements stack should work. Prototypes and modeling can help. Developers and architects must conceptualize the result of each task, which is based on the requirement, before actual implementation during the sprint. Good planning makes coding faster and easier. However, not every software requirement needs planning, and the right prep work varies from one requirement to another.
In the sprint, developers code and test the iteration. Agile adherents set the sprint for roughly two weeks, though the project manager can compress or extend the timeframe to accommodate the given tasks.
Once completed, the iteration goes to testing, a step that can include demonstrations or previews in which stakeholders evaluate the development work. Previews promote regular and constructive collaboration between stakeholders and the development team. The planning and development cycle then repeats, leading to the subsequent iteration.
Software requirements management
Handle changing requirements in Agile software development projects with a workflow that organizes and processes requests. Team members can submit requests to a central authority -- usually the project manager -- who sorts small, low-impact requests, such as bug reports, into the requirements list. For significant or high-impact requirements changes, which could dramatically reshape the project's budget, timeline or developer demands, the project manager should confer with leadership, such as a software portfolio manager or another senior executive.
Although changes can come up at any time in any iteration cycle, software requirements typically freeze during sprints, as the team must minimize developer disruption while they generate new code. There's always the requirements stack for the next iteration cycle. Only disrupt a sprint for the most dire and mission-critical changes to requirements.
Make changes productively
Frequent requirements changes can challenge even the most experienced development team. The shifting demands of stakeholders and users can delay iterations, complicate testing and push out project timelines. Deploy these tactics to mitigate unnecessary disruptions:
Improve collaboration. Software requirements communication should never be a one-time, one-way exercise. Complex projects demand real-time conversations so that developers and stakeholders can discuss requirements and changes. The Agile team must work with stakeholders to understand and clarify requirements and sort out the priorities of each.
Minimize planning. Prioritization and planning usually make the iteration process in a sprint easier. But requirements changes can render plans moot. For Agile software requirements, developers and architects should minimize the time they spend planning details and focus on only the most complex or critical tasks for the iteration -- fix any rough spots in the next iteration.
Follow a chain of command. Every project needs a manager to lead the effort, organize resources and coordinate changes. Stakeholders should interface with the project manager, not individual developers, to make requests and changes. Free-wheeling communication leads to duplicate work and could prevent effective developer-to-task pairings.
Evaluate the process. Changing requirements in software development is disruptive, but sometimes that's due to the way in which the Agile team handles the changes, not necessarily the nature or volume of the requests themselves. Software requirements management covers how requests are introduced, their prioritization, assignments and more. Optimize the process to resolve any bottlenecks.
If constant software requirements changes have project managers and development teams scrambling to keep up, implement centralized workflows, clear communication and disruption-reducing strategies early in the project's lifecycle. Iteration doesn't have to mean turmoil -- the goal is to meet stakeholder needs flexibly, but on schedule.
