17.1: Top-Down Design

Last updated
Save as PDF

Page ID: 84356

Carey Smith
Oxnard College

\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

Creating a medium to large software project requires good planning, especially when working in a team. The standard approach is called "Top-Down Design". This can also be applied to projects using a combinations of hardware and software. The approach has the following steps.

Concept of Operation. This is the basic concept of what the final software or device should do.

Requirements and Architecture (a.k.a. Requirements Analysis) This refines the concept of operation to specific requirements, to what could be contract requirements.
- Example 1: A navigation system for a commercial airline. The requirements would specify the power available, the inputs from other devices (e.g. altimeter), the outputs (roll, pitch heading, speed, rotation rates, latitude, longitude, altitude), the rates of the inputs and outputs, and the connections. I would not specify the insides of the navigation box.
- Example 2: Process for a census. The requirements would specify the data desired from each household, such as names, ages, address, employment or retirement or looking for work, or disability status etc. It would specify what the user interface would look like for processing the data after it has been collected.
- Example 3: Software for an ATM machine. This would specify the user interface and required functions, such has handling withdrawals and deposits, allowing for checking and savings accounts, ability to check balances, and an option for a receipt.
System design.
- Example 1: Navigation system. The System Design would specify what type of gyros, accelerometers, and other sensors to be used, the number of circuit boards, the microprocessors, and the high-level algorithms.
- Example 2: Census. The System Design would specify whether the data will be collected electronically and/or by paper. It would specify how the data will be stored (database or spreadsheet software), what the categories are, what the data summaries should look like. It could specify the need to check for duplicate entries or for missing data from known apartments or zip codes.
- - Example 3: ATM Software. This would specify the software interfaces with the card reader and the cash dispenser and the check scanner. It would include access to the user's account and the related ID verification and security software. It could include interfaces with partner banks or credit unions.
Software detailed design. This specifies the software algorithms, precision needed, interfaces with the hardware, etc.
- Example 1: Navigation system. The Detailed design would specify the software functions needed and the algorithms for them. If there are multiple processors, it would specify which functions are implemented on which processor. It would include estimates of the time for each function and and timeline so that the outputs can be computed at the required rates.
- Example 2: Census. This would specify how the data will be processed and what subroutines are needed. Routines might be designed for common interfaces with different data sets. It might include how to merge electronic and paper data.
- Example 3: Software for an ATM machine. This would specify the algorithms for each of the functions.

Once the software is written it needs to be tested. This is called verification. First, each function is checked for correct operations with both valid and invalid inputs. When errors are found, then they are corrected or the design and/or requirements are reviewed for problems and possibly updated.

Also, functions with hardware interfaces are tested with their hardware.

Then groups of relation functions are tested together to verify that their interfaces work as designed and the results are correct. Again, corrections are typically needed. These may be corrections in the software or the design or sometimes the requirements need to be adjusted/clarified.