Information Technology Reference
In-Depth Information
Because the UAT plan is not properly drawn and becomes open
ended
Because there are issues with the data, which the software devel-
opers do not see as “their problem”
Considering that the requirements will end up being the baseline for
UAT, always plan for the UAT when preparing the requirements. As already
discussed, certain development methodologies give higher priority to
testing. However, testing and UAT are two separate processes. Both require
considerable infrastructure setup, especially when it comes to data prep-
aration. Data requirements for UAT must be an identified nonfunctional
requirement in the project requirements document.
Summary
Requirements are the cornerstone of development. Delivery requires the
management of two sets of requirements — one for the deliverable itself
and the other for the project that is the vehicle through which the delivery
is made. It is difficult to specify requirements — it has to do with the
nature of the business processes themselves, the nature of the communi-
cation processes between people, the limitations of language and tools,
and the “divide” between technology and business folks. One must solve
the right problem, and that has always been a problem in software and
other domains.
Gathering requirements is a term that captures well the process of
identifying the stakeholders and finding out what they need. Over the life
cycle of an application, the requirements are invariably delivered in phases.
Changes to them are managed through change control processes.
However imprecise the process of gathering requirements is, good
software gets built and it gets done through a combination of decent
requirements, good processes, and a degree of trust.
Requirements must be converted into actual systems that have to be
delivered. As discussed in Chapter 5, the architecture and design of such
systems form the foundation of a successful system.
