Asking a business what it wants out of a software development project has always been a challenging endeavour. Requirements invariably change along the way, and traditional software development processes have not been able to accommodate these changes well.
The common response has always been to regard changing requirements as a failure of some sorts and apportion blame - the business analysts blame business for not knowing what they want, and business in turn blames the business analysts for doing poor requirements gathering.
To deal with this problem, business tends to be as elaborate about its requirements as possible and the business analysts in turn try to be as complete in their requirements gathering as possible, both to avoid missing out something.
Off the mark
The typical result is an overly elaborate requirements specification that includes every conceivable requirement that both parties could come up with. Bearing in mind that at least 45% of features and functions built into the average software product are never used, something is definitely wrong with the way companies currently elicit and prioritise the business requirements.
To ensure that a project is destined for success, software development needs to be approached using a process that properly elicits and prioritises the business requirements, while at the same time being adaptable to the inevitable changes in requirements that will arise.
On most software development projects, the business analyst is required to document all the requirements in detail, up-front and get business to sign off on this specification. This is often done without an understanding of the priority or affordability of the requirements provided by business. This specification is then used as the basis for the software development project.
In agile software development, the business analyst initially only develops a high-level understanding of the business requirements.
These requirements are then prioritised, and as the project commences, in small building blocks or iterations, the business analyst will analyse the requirements related to each iteration in detail. At any point new requirements can be added to the list and the order of the list reshuffled to accommodate changing business priorities.
Mission accomplished
For this approach to succeed, the business analyst must be skilled at working with management to come up with a prioritised list of business requirements for a software project. The responsibility to prioritise is with business and that of the business analyst to facilitate the process. The point is to obtain a proper response from the business; a response that has been evaluated and constructed into a prioritised list of business requirements that aims to deliver high value-add components early on in the project.
The common response has always been to regard changing requirements as a failure of some sorts and apportion blame.
Ziaan Hattingh is MD of IndigoCube.
Just writing down what a business wants in a lengthy and detailed up-front specification is not proper requirements elicitation and very bad practice. What is needed is an understanding of what the business needs and what the priorities are, but the detailed analysis happens later.
In an agile software development project, business requirements are prioritised. A useful way to prioritise requirements is through the use of an axis of effort versus value:
* High-effort/low-value requirements are to be avoided;
* Low-effort /high-value iterations are considered to be quick wins;
* High-effort /high-value iterations are strategic requirements; and
* Low-effort/low-value iterations are the "nice to haves" in any project.
Business analysts must have the ability and expertise to assess user requests so they do not end up with a list of nice-to-have features in the software or business system, and do not deliver low-value, high-effort requirements before others. This scenario results in additional development costs, project time overruns and features that are not used.
* In the next Industry Insight, I will look at the seven deadly sins of an agile project.
* Ziaan Hattingh is MD of IndigoCube.
Share