Agile Up Front Analysis

One of the most visible aspects of agility is making decisions when they are needed, and not making them all up-front, before any development work is done. But some decisions are needed before the rest of the project is executed.
An agile approach to software development has many advantages in most organisations. Because change is inherent, in business needs, in technology, in knowledge, in people, it makes a lot of sense to use a process that takes change as a given and embraces it, instead of trying to defend against it.
One of the tenets of agile approaches is to decide things as late as possible. At the same time, we want to make software that people will use and like and that has real value to them. And sometimes these two goals are at odds with each other.

The traditional way to achieve this, is performing extensive requirements analysis before a project starts. All involved in the systems that is going to be built (the stakeholders) should tell upfront what they expect of the system, and after carefully balancing all needs, a list of requirements is delivered which is sent to the software design and development teams.
In an agile approach, many of the requirements gathering techniques used in traditional requirements management still make sense. The upfront analysis approach does not, as it does not take into account the fact that requirements change. People change their minds or gain a better understanding of their needs, laws change, budgets change, political landscapes change.
The usual agile approach is to finalise the requirements, and their relative prioritities, for one iteration just before that iteration starts. Refinement is even possible within the iteration. The requirements should be as detailed as necessary; not more, not less. This means that a requirements engineer not only talks with business stakeholders, but also with his primary customers: the developers, who are going to use these requirements.
Many agile (and non-agile) projects however start too fast, forgetting to think about issues that do need to be addressed before the first iteration. The risks of producing the wrong software are too big if these issues are ignored.
These issues include the business purpose of the project, the list of people and systems involved (the stakeholders), the scope of the work and the most critical constraints.
Depending on your organisation, this could be written down on one or two sheets of paper, or require a more rigorous analysis and report.
If you don’t, you run this risk of:

• making something that doesn’t fulfill a business purpose, so it will be seen as a waste of money even if something is delivered [business purpose]
• leaving out stakeholders and their requirements, leaving people unhappy at best, and making the result useless because it omits important functions or interfaces at worst [stakeholders]
• including costly features that are outside of scope and could have been more economically implemented in another project or system (or leaving out important features that could have made the system more worthwhile – because of an incorrect assumption about the scope) [scope]
• getting the wrong people on board, like oracle developers to extend a java system, or not being able to run on existing infrastructure, or not working towards an important deadline [constraints]

So in any project, even in an agile project, take time for a project blast-off in which these important issues are addressed, or else the success of your project is a complete gamble, no matter how good the team is.
After the blast-off, requirements management is part of the agile process, managed by the product owner, who is a true part of the agile development team.