This discussion is in the context of Software / Systems (Software + Hardware) Projects. We will essentially try to answer a question,
How RMsis is going to be used within an Agile OR Waterfall Model ?
Our view is that the Model does not make a difference at the fundamental level, though there could be questions, which are dependent on the specific context of a project. We will try to explain in the following sections.
Common and Different elements of Process Models
- Almost all Modern System Architectures are build around Non Functional Requirements with an ability to provide functional capabilities as the needs emerge.
- So essentially, a complete non-functional specification is prerequisite to implementing an Architecture. These essentially address Non Functional attributes like
- Fault Tolerance
- So a 100% complete Non Functional Requirements Specifications is essential in either of the cases.
- A deficiency here will be very expensive in later stages.
In our view, the primary difference between an Agile and Waterfall model is the extent to which Functional Specifications are complete at any given stage. A typical situation will look like the following:
- In Waterfall model, 80% of the functional Specifications may be available, when we are still within the 20% of timeline ... the rest will evolve in the later 80% of the project cycle.
- In an Agile Model, the Functional Requirements may emerge throughout the lifecycle of the project. So when a project has complete 20% of the timeline, only 20% requirements may be available.
Does it make a difference on the Requirements Tool ?
A Requirements Management tool is typically built to handle the lifecycle of an individual Requirement, like
- Requirement capture
- Requirement analysis & elaboration
- Requirement assignment to a milestone
- Requirement Implementation
- Requirement validation
- Requirement evolution
The timeline / milestone assignment to Requirements is largely a Project Management decision, based on resource availability, contract conditions and the project objectives.
Another view of what Agile is all about ...
Considering the above arguments, an Agile / Scrum methodology is all about fixing a window, where the objectives in that duration will not change. What will be different in two scenarios is the type of items addressed in a typical sprint. The following diagram demonstrates the same ...
The Validation / Testing has been ignored in this paper, since it does not impact the primary point of discussion