Project Life Cycle
Figure 1-3. Risk profile of a conventional software project across its life cycle exactly those requirements. This approach depends on specifying requirements completely and unambiguously before other development activities begin. It naively treats all requirements as equally important, and depends on those requirements remaining constant over the software development life cycle. These conditions rarely occur in the real world. Specification of requirements is a difficult and important part of the software development process. As discussed in Appendix A, virtually every major software program suffers from severe difficulties in requirements specification. Moreover, the equal treatment of all requirements drains away substantial numbers of engineering hours from the driving requirements and wastes those efforts on paperwork associated with traceability, testability, logistics support, and so on—paperwork that is inevitably discarded later as the driving requirements and subsequent design understanding evolve.
As an example, consider a large-scale project such as CCPDS-R, presented as a case study in Appendix D, where the software requirements included 2,000 shalls. (A shall is a discrete requirement such as "the system shall tolerate all single-point hardware failures with no loss of critical capabilities.") Dealing adequately with the design drivers in such systems (typically only 20 to 50 of the shalls) is difficult when the contractual standards require that all 2,000 shalls be defined first and dealt with at every major milestone. The level of engineering effort that can be expended on the important design issues is significantly diluted by carrying around the excess baggage of more than 1,950 shalls and dealing with traceability, testability, documentation, and so on.
Another property of the conventional approach is that the requirements were typically specified in a functional manner. Built into the classic waterfall process was the fundamental assumption that the software itself was decomposed into functions; requirements were then allocated to the resulting components. This decomposition was often very different from a decomposition based on object-oriented design and the use of existing components. The functional decomposition also became anchored in contracts, subcontracts, and work breakdown structures, often precluding a more architecture-driven approach. Figure 1-4 illustrates the result of requirements-driven approaches: a software structure that is organized around the requirements specification structure.
The conventional process tended to result in adversarial stakeholder relationships, in large part because of the difficulties of requirements specification and the exchange of information solely through paper documents that captured engineering information in ad hoc formats. The lack of rigorous notation resulted mostly in subjective reviews and opinionated exchanges of information.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.