Consider Figure 6.3.
For this reason it can be essential that requirements specifications are written but changeable. The
potential for requirements change can be a root cause of problems. See [Lutz] for more on this.
6.3 Architectural Definition Phase
In this phase the overall design of the system is completed. Integration testing has often been obviated
by the use of better software development environments wherein all interfaces are already checked before
units are compiled. If such checking cannot take place or if (for example) preliminary partial integrations
can take place with only stubs and drivers available, as in web system development, then this phase still
needs planning. This phase will show:
??? The subsystems into which the system features have been allocated.
??? The interfaces between the subsystems which are the basis for the integration test specifications.
Find out where these are defined and, if any aren??™t but you still have a responsibility for testing
them, write them yourself using section 8.4. From this, whoever is in charge of building the releases
can derive the
Integration tree
(see section 8.5.16) which will define the order in which the software
will be integrated and built.
During this phase:
??? Update the test plan with any integration test details. Alternatively if the system is large, write a
separate integration test plan.
??? Review the software/software integration using section B.
Pages:
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239