However, in the commercial, non-DOD world, these documents are
generally not used. This can be a problem when following the CMMI because this
document is expected in several practices throughout the model. Organizations
that are not DOD-like generally rely on object-oriented techniques, use cases, or
man??“machine interface documentation to satisfy this concept.
Beta testing of requirements is mentioned here.
Things that most organizations tend to forget about this process area:
Maintenance shops also do development.
Even if you get your requirements directly from the customer, some refinement
and analysis of them is always necessary.
Developing and analyzing requirements never stops until the entire application
is either delivered to the customer for final handoff, or is dead and
buried.
There are no generic practices that directly map to this process area.
Requirements Development includes collecting and eliciting customer requirements
from all involved parties at all levels; breaking down those high-level requirements
into lower-level, more detailed requirements, and assigning them to categories
for further development; defining interfaces among the requirements and any other
areas necessary to fulfill the requirements; more adequately defining and documenting
the operational need, concept, scenario, and functionality desired; ensuring that
the requirements are complete, required, and consistent; negotiating needs versus
wants versus constraints; and validating the requirements against risk in the early
phases of the project.
Pages:
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228