Independently of its scope and the methodology used, each software development project is made of the same blocks/phases arranged eventually differently. It starts with Requirements Managements (RM) subprocesses in which the functional and non-functional requirements are gathered, consolidated, prioritized and brought to a form which facilitates their understanding and estimation. It’s an iterative process as there can be overlapping in functionality, requirements that don’t bring any significant benefit when compared with the investment, respectively new aspects are discovered during the internal discussions or with the implementer.
As output of this phase, it’s important having a list of requirements
that reflect customer’s needs in respect to the product(s) to be implemented. Once
frozen, the list defines project’s scope and is used for estimating the costs, sketching
a draft of the final solution, respectively of reaching a contractual agreement
with the implementer. Ideally the set of requirements should be completed and be
coherent while reflecting customer’s needs. It allows thus in theory to agree upon
costs as well about an architecture and other important aspects (responsibilities/accountability).
Typically, each new requirement considered after this stage needs
to go through a Change Management (CM) process in which it gets formulated to the
needed level of detail, a cost, effort and impact analysis is performed, respectively
the budget for it is approved or the change gets rejected. Ideally small changes
can be considered as part of a buffer budget upfront, however in the end each change
comes with a cost and project delays.
Some changes can come late in the project and can have an important
impact on the whole architecture when important aspects were missed upfront. Moreover,
when the number of changes goes beyond a certain limit it can lead to what is known
as scope creep, with important consequences on project’s costs, timeline and quality.
Therefore, to minimize the impact on the project, the number of changes needs to
be kept to a minimum, typically considering only the critical changes, while the
others can be still implemented after project’s end.
The agile manifesto’s principles impose an important constraint
on the requirements - changing requirements is a good practice even late in the
process – an assumption - best requirements emerge from self-organizing teams, and
probably one implication – the requirements need to be defined together with the
implementer.
The way changing requirements are handled seem to provide more
flexibility though it’s actually a constraint imposed on the CM process which interfaces
with the RM processes. Without a proper CM in place, any requirement might arrive
to be implemented, independently on whether is feasible or not. This can easily
make project’s costs explode, sometimes unnecessarily, while accommodating extreme
behavior like changing the same functionality frequently, handling exceptions extensively,
etc.
It’s usually helpful to define the requirements together with the implementer, as this can bring more quality in the process, even if more time needs to be invested. However, starting from a solid set of requirements is a critical factor for project’s success. The manifesto makes no direct statement about this. Just iterates that good requirements emerge from self-organizing teams which is not necessarily the case.
The users who in theory can define the requirements best
are the ones who have the deepest knowledge about an organization’s processes and
IT architecture, typically the key users and/or IT experts. Self-organization revolves
around how a team organizes itself and handles the various activities, though there’s
no guarantee that it will address the important aspects, no matter how motivated
the team is, how constant the pace, how excellent the technical details were handled
or how good the final product works.
Previous Post <<||>>Next Post
