System objectives provide direction for the project, but they are high-level and do not actually specify what has to be done or made, a necessity for in-depth project plan- ning and system design. Specifications are needed that tell the project team what it has to do, which is accomplished through system specifications. These define in-depth the requirements of the end-item, system, or product, and the involved subsystems, components, and processes.
System specifications reflect and support the system objectives. They are the criteria or procedures that will guide actual project work and are written by and for project specialists—systems analysts, programmers, engineers, product and process designers, consultants, and so on—in their particular technical lingo. System specifi- cations address all areas of the project—system design, fabrication, installation, opera- tion, and maintenance. To retain user involvement, a list of baseline specifications also is prepared. These are system specifications defined at a high level design basic enough for the user to understand. The user refers to this list to learn about the details of the system.
In defining technical system specifications, the contractor also refers to the list of baseline specifications. Technical system specifications should be set so as to meet, but not exceed, the baseline specifications. This is one way to control against “creeping scope;” which is burdensome growth or enhancements of project requirements that increase project budgets and schedules.
Often, definition of user requirements, system objectives, and system specifica- tions happens iteratively, particularly when the project end-time is complex. The re- quirements cannot be completely defined without some amount of prior design work, and the design work cannot be completed without some amount of prior fabrication and testing. In such cases, high-level (basic) design of the system must begin soon af- ter the specification definition is started, and be completed before the specifications are approved. The overall process looks like Figure 5-2. Often a prototype, which is an early running model of a system or component built for purposes of demonstrating performance, functionality, or proving feasibility, is used to assess and modify speci- fications. The prototype is built according to the initial specifications and design, and then tested. The test results are used to modify the specifications and the prototype, and the prototype is then retested. This ensures that the basic system design supports the system specifications. The application for software development, called rapid proto- typing, is discussed in Example 2.
Example 2: Rapid Prototyping for Software Development3
When no physical system exists that is similar to the one to be developed, con- ceptualizing the system may be difficult and confusing. The system the customer “sees” might be very different than the one the developer envisions, yet without a physical or working model, the difference will not be readily apparent. In such instances, the final, delivered system matches the mental picture or conceptuali- zation of the developer, but might not closely correspond to the system concep- tualized by the user. The usual approach of requiring the customer to specify and sign-off on requirements early in the project intensifies this problem. It forces the customer and developer to commit to actions before they have reached a mutual understanding about the requirements.
A rapid prototype (RP) is a rudimentary, intentionally incomplete model of the product, and, initially, it is somewhat simple and inexpensive to produce. It rep- resents key parts of the system, not the complete system, and therefore should be easy to create and modify. The customer experiments with the prototype to assess a system’s functionality and determine necessary modifications or addi-
A. Conception: User needs B. Definition: User requirements C. Execution: High-level design System objectives System specifications Low-level design Build/Fabricate/Produce Test Installation Figure 5-2
Iterative development cycle for complex systems.
tions. Changes are made to the RP, and the customer performs experiments again. After a few iterations, the final requirements and design concept are firmed up. Architects use physical scale models of buildings for the same purpose: To convey to the customer the look, feel, and functionality of the design. For that purpose, a functioning, physical model is always better than drawings, schemat- ics, or lists or requirements. Of course, drawings, schematics, and requirements are necessary to inform the development team of what is expected. In rapid pro- totyping, however, drawings and requirements are not committed to until the sys- tem, as represented by the RP model, has been accepted by the customer. In software development, the RP might be a series of screens or windows with queries to allow the user to “feel” what the system would be like. An RP model should be used wherever there is danger of the project producing a system that fails to meet user requirements or system objectives. Ordinarily, the rapid proto- typing process will not speed up definition; instead, it might lengthen the phase. The RP model will likely be incorrect at first, though through experimentation, the customer and developer will learn from it and settle on optimum requirements.
Rapid prototyping is commonly used for requirements definition; however, it also can be employed throughout the full systems development process, in which case the end-item system evolves stepwise, from a simple, incomplete RP model to a full-functioning, operational system. The process progresses through a series of milestones and phases similar to that in the traditional systems development cycle. The first milestone, definition of preliminary requirements, represents cus- tomer acceptance of a preliminary project plan and user requirements/system objectives document. A high-level (basic) design and functioning RP model are created. Trials and experiments are performed with the model and the results used to modify the requirements, signifying the next milestone, definition of final re-
quirements. At this point, two things exist: (1) the approved functioning RP model
and (2) its supporting documentation (requirements and objectives, drawings, and schematics). Now the analysis of detailed system specifications can begin. The RP model is tested to reveal further necessary revisions; that is, revisions to de- tails, not the overall concept or system architecture. The final approval by the cus- tomer and developer of the detailed design and system specifications signifies the
as-prototyped design milestone. Next, the expanded RP system is exposed to rig-
orous testing, and portions of it are replaced, modified, and fine-tuned until it meets user performance requirements. The documentation that emerges during this stage will be used to maintain the system (for a one-of-a-kind system) or to reproduce it (for mass-produced systems). Customer acceptance of the system and its documentation signals the end of this phase and the as-refined design mile- stone. The two remaining milestones are test acceptance and system acceptance. The former represents approval of the system after the user has put it through a series of exercises that represent the actual working environment; the latter, ap- proval of the system after it has been fully integrated and tested for operation in the customer environment. Passing these milestones is usually somewhat pain- less, given careful attention to definition of correct requirements and correct ba- sic design in the earliest phases of the process.