Requirements in Agile Software Development

By 16th July 2015 Agile

The Goal of Agile Methodology

To develop a functional product with all the basic requirements in place.

When working agile, you must think in terms of: working on width instead of working at depth.

The opposite of this would be to develop one, fully-functional subsystem at a time, for example, the entire product ordering module, or all of the billing functions.

But if you’re building wide before building deep, your main priority should be to get the most important features of the orders done, as well as the most important features needed for billing.

Since traditional waterfall-type methods tend to over-develop systems with more functions than you’d care to use or learn about, you’ll end up wasting more time, effort and money.

Agile, on the other hand, advocates the idea that you should work until you get it right and then stop when the resulting system delivers enough value.

Your goal is to build the most important features first, and, when it’s no longer worthwhile to continue adding more functionality, stop. Once costs exceed the value delivered to the user, there’s little point in developing the project any further.

Therefore, agile principles prevent overwork.

Agile Development and Software Requirements

Agile development is especially suitable for changing requirements, whenever there is uncertainty about what is the best solution, and when it is important to be able to change quickly.

The changes and uncertainties affecting organisations may relate to markets, technology, requirements, resources, and time.

When dealing with the requirements of an agile context it is appropriate to work with a focus in time, a business focus, user focus or systems focus. When you work in short cycles, it becomes important to get feedback quickly. For this to be possible, you’ll need to engage users and other stakeholders, as well as using different feedback techniques such as prototyping and usability tests.

Naturally, shorter iterations will need fewer requirements. However, the requirements still need to be listed in order of priority – no matter how many there are of them. In order to achieve this, many team members work with user stories to describe the requirements.

A requirements management tool facilitates the work involved in collecting feedback from multiple sources, writing user stories and prioritising them. There are many tools that provide support for different parts of the process. ReQtest is an example of a tool that helps you manage requirements more effectively, enabling you to document the requirements in a consistent manner and assign them a priority level.

With ReQtest, you have control over the entire requirements management process: from requirements gathering, to sprint planning, and monitoring.

The Agile Manifesto

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.”

(Taken from: http://agilemanifesto.org)

In other words, the Agile Manifesto describes the kind of attitude you should take to work in an agile way. To paraphrase the manifesto above:

  • Shared responsibility for the solution.
  • It should work – even though it is a tiny part/function.
  • We all sit in the same boat.
  • We assume that nothing is static, we assume that new discoveries can overturn everything we thought earlier.

The 12 Agile Principles

We follow these principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity – the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

There is much in these 12 agile principle that you could learn about: customer benefit, cooperation – from several directions, developing people and software.

Tip: I suggest you print these agile principles and stick it up on the wall. Talk about them together during your next retrospective meeting.

Join the discussion One Comment

  • While I agree with alot of agile tennants, I believe that stating that agile models need to be “just barely good enough” is not good enough.

    There is no mystry here. The essentials of functional modeling have been know for many years. I would suggest reading up on what a good essential data flow diagram is.

Leave a Reply