Systems Design

views updated

Systems Design

Systems design is a component of the systems engineering process. Typically, it follows systems analysis, precedes implementation, and is driven by the requirements generated during the earlier phases of the project. Within the context of computer sciences, systems design includes the specification of hardware and software architecture granulated to the necessary components, modules, and interfaces.

The systems design process may include such subcategories as network design, software design, and data design. The scope of the project is a primary determinant of the degree to which any of these and potentially other sub-processes factor into the overall system design effort. Organizational standards and budgetary constraints may also limit design activity.

The sequence of design events relative to other processes in a system's life cycle is largely determined by the systems methodology chosen for the project. This is often based upon the nature of the system being considered. The traditional systems engineering methodology, often referred to as the waterfall paradigm , assumes that all planning, business analysis, risk assessment, and requirements definition occur before any of the design activity begins. All systems design activity must then be completed and verified against requirements before any implementation can begin. Implementation may include constructing a network, developing software, or a combination of such activities, depending on the scope of the system. When implementation is complete, the system is evaluated and ultimately introduced to the operational environment.

Often, such a strict serial methodology is impractical. Increasingly, and especially for the development of software, an iterative approach is chosen. The most evolutionary of the iterative models, often preferred for object-oriented software construction, is the spiral methodology. Under this paradigm, a prototype is rapidly constructed through much shorter phases of analysis, design, development, and testing. The cycle is then repeated many times until the original prototype is adequately refined and ready for operation.

While the waterfall paradigm is structurally confining, the spiral approach has the potential for lack of structure and initial planning. For this reason, a compromise is often chosen between the two models. For instance, project managers may choose an approach that is predominately sequential, but with review and refinement iterations planned between each phase. Or they may choose an incremental model, which is closer to the spiral methodology but defines a limited number of structured iterations.

Regardless of the scope or chosen methodology, systems engineering activities occur in the same functional sequence: Analysis is followed by design, which is followed by implementation. The scope of design activities changes on a per-project basis, but effective design practices apply to all engineering projects regardless of scope or chosen methodology.

The design phase deals with decisions regarding the specific architecture of the system so that it meets all of the stated requirements when constructed. During the first round of an iterative project, requirements may be few and vague. A large-scale waterfall-based project, by contrast, may present many specific requirements. Regardless of scope or methodology, stated requirements must be addressed and verified before the design can be considered complete.

A well-designed system will operate efficiently, providing maximum value given its use of resources. Surplus resources sometimes permit the designer to incorporate features or performance in excess of basic requirements. Such decisions must be carefully evaluated because improving one aspect generally diminishes another. Most systems design decisions involve some degree of compromise, so effective evaluation methods are an important part of the design process.

Decision models, often constructed as tables or trees, may be incorporated to assist designers in quantifying alternatives. Decision tables assist in translating actions and conditions into a tabular format, while tree models generally break a high-level decision into alternatives, each of which is further aggregated into individual consequences and further alternatives. Decision models may extend into several layers of conditions and actions. If systems and their associated decisions are complex enough to justify it, decision support systems may be implemented to assist the decision process. Decision support systems are often computer-based and built specifically to help evaluate both objective and subjective considerations of much larger independent systems. Decision models may be used to help the designer evaluate high-level decisions about the system's construct as well as to demonstrate the internal decision processes that occur within a system.

Other models that assist designers in visualizing system processes include flowcharts and data flow diagrams (DFDs). Both models graphically depict process flows through a system using shapes to represent processes or entities. The shapes are connected by arrows that direct flow.

Flowcharts primarily depict the sequence of decisions internal to a system, based on logical conditions. By convention, boxes indicate processing steps and diamonds depict conditions. This simple set of constructs was originally proposed in the late 1960s and is most effective for designing procedural programs. Object-oriented software development projects may benefit from a program design language such as the Unified Modeling Language (UML), which defines a robust set of notational conventions.

Data flow diagrams provide a means to depict the movement of data through a system or organization. They were introduced in 1979 in the book Structured Analysis and System Specification by Tom DeMarco. The DFD depicts data flow between processes, external agents, and data stores. DFD convention defines an oval to be a process, a rectangle to be an external agent, and two horizontal lines to represent a data store. Other tools for modeling data include entity-relationship diagrams and state-transition diagrams.

Systems design that is complete, based upon solid decisions, and well-documented produces a valuable blueprint for the remaining phases of the engineering project. This is especially important under the waterfall approach, since all subsequent activity is reliant on the product of the design effort, and previous project phases are not easily revisited. An effective design product provides measurable deliverables and verifies that, in concept, the finished system will satisfy all requirements.

see also Design Tools; Office Automation Systems; System Analysis.

Jeffrey C. Wingard