- 1 Introduction to Requirement Management
- 1.1 The challenges of requirement gathering
- 1.1.1 Requirements Gathering and Elaboration
- 1.1.2 Requirements clarity
- 1.1.3 Adapting to changing requirements
- 1.1.4 Large requirements
- 1.1.5 Requirements prioritization
- 1.1.6 Communication gap
- 1.1.7 Availability of business stakeholders
- 1.1.8 Incorrect Assumption
- 1.1.9 Costing schedule and team allocation
- 1.2 Share and Enjoy !
- 1.1 The challenges of requirement gathering
Introduction to Requirement Management
Requirement management is the most critical aspect of software development projects. The absence of detailed, upfront requirements is found to be the primary cause of failure for most of the software projects.
In our traditional waterfall development model, requirements are defined, detailed and the scope is approved(or frozen) before the coding phase begins. Most of these projects assume that the requirements are well understood in the beginning so they would that change.
Even if the change comes after software delivery, it will be treated as a change request (CR) to be developed later. Similarly, here the internet thinking is that the entire scope of the project is critical and hence, prioritization and delivering few requirements early in the project would be immaterial.
In contrast, Agile frameworks provide flexibility to form changes in requirements, define new requirements and shuffle priorities even within the late stage of development. The most popular Agile methods such as Serum, XP are based on the concept of completing, small but valuable requirements in short iteration.
In addition, here the requirements are defined, prioritized and sliced to ensure that valuable software is developed, tested and released in a shorter release cycle continuously.
The challenges of requirement gathering
For the success of any project, whether executed in a traditional model or Agile, defining requirements clearly plays a major role. One of the most common challenges faced is the customer’s inability to articulate clearly what they want. Requirements that are not developed properly result in expectation mismatch.
Since in the Agile framework, a complete set of requirements evolve over time, it becomes difficult to decide when to stop defining and start developing. The market pressure and feedback from end-users add to constant changes in requirements against demanding timelines.
The following are the major challenges for requirements definition in the context of agile project execution.
Requirements Gathering and Elaboration
Requirements gathering and elaboration is not a separate phase in Agile. It is a challenge to keep refining the requirements, understand and articulate value progressively on the basis of conversation between the team and business stakeholders in short cycles.
When requirements are not clear, it is a challenge for the team to commit the completion of planned user stories in short iterations (2-4 weeks).
Adapting to changing requirements
Teams find it difficult to adopt the culture of continuous change in requirements.
Often the requirements are defined as a large piece of work and efforts are not invested to create small requirements with business value that can be delivered faster.
Most of the time, it is assumed that all requirements are of some priority and need to be delivered once the scope is final, which is a significant challenge while moving from the traditional model to the Agile mindset. Prioritizing requirements is neglected most of the time. It is important to understand that developing and delivering requirements to production takes efforts. Lack of prioritization leads to the team delivering features that are of lesser/no value or not required by product users.
When requirements are defined and are handed over to the development team without a discussion, interpretation of requirements differs from each member of the team due to the wide communication gap.
Availability of business stakeholders
The availability of business stakeholders should be more frequent to answer team queries on daily bans or as and when required. Investing or budgeting time for this and also for regular product demonstration is a challenge.
Quite often, both teams and business stakeholders assume points about requirements without discussing, documenting or clarifying, which leads to change requirements (PRS) or defects when product is delivered, leading to conflicts.
Costing schedule and team allocation
As opposed to traditional models where the project cost can be estimated based on detailed scope, for the Agile project, to estimate the cost, schedule, and team allocation plan is a challenge.
In the absence of an effective mechanism to deal with requirements definition and prioritization challenge, the project, even if delivered, can fall short of satisfying the need of stakeholders.