Agile Software Development Methodology: Remedy For the Incomplete Requirements Specification Document

/

Have you ever found yourself asking if requirements can ever be complete? Here's my answer: No.

I once worked on developing a Requirements Specification Document (RSD) for approximately 3 months. I was extremely confident that the requirements were complete because of the energy, thought and time I had invested. I handed over the RSD to the developer who built the software and then invited me for testing. While testing, I discovered that new requirements would need to be added. This resulted in a back and forth situation between the developer and I, as well as all the frustration and delays that come with it.

Requirements Specification Documents are critical to any software development project and represent the “big picture” of what stakeholders want the final software solution to look like, and the desired system behaviour. If you’re a Business or Functional Analyst, you’ll find yourself preparing one at some point.

One of the characteristics of a good requirement is completeness. In reality, however, some requirements trigger associated requirements not explicitly stated by the stakeholder. While a stated requirement in itself may be regarded as complete, how can you ensure that the RSD is complete and outlines all the expected system behaviour? Is this possible to achieve or is it just an ideal?

A BA may send out an incomplete RSD due to a number of reasons: 

  • Some requirements are considered as “standard” features of a business solution and may not be explicitly stated

  • Requirements may become redundant during the project due to the length of time it takes to complete analysis, prepare the RSD and develop the solution.

  • Some stakeholder requirements may be unforeseen or unstated

  • Bounded rationality - People are constrained by the available information and are also unable to process all the information available within the limited time they have to make a decision

  • Some requirements become obvious only when the system is being tested or is in use.

These factors point to the fact that it is almost impossible to write a “complete” Requirements Specifications Document. You may attempt to cover all grounds and still come up short. 

This is where agile methodologies come into play.

Agile Methodologies are a different way of managing software development projects. Emphasis is on:

  • Individuals and their interactions

  • Developing functional software in favor of comprehensive documentation

  • Client collaboration

  • Responding to change in favor of following a planned approach

Requirements are prone to change and may become irrelevant during the course of the software development project. Their dynamic nature implies that the RSD will continually evolve and thus, may never be complete. 

Without getting into the Traditional vs Agile Software Development Methodology debate, both approaches have their merits. You just need to discover which is right for your project.

On a final note, consider this: what if developers and business analysts were to collaborate to produce the Requirements Specification Document? Wouldn't that make the document more comprehensive and reduce blame trading?

View related articles on Agile Projects