Technical Systems Design

Technical solutions designed to meet your organization's needs…

There are an infinite number of potential ways to design a solution. Darby’s Technical Design Services helps determines the best solution possible, given the requirements, architecture and standards established in previous phases of work. For instance, there are a multitude of ways to build the solution screens and reports. The Technical System Design is where we describe exactly how your application will look and function.

Technical System Design Services

• Program/application flow design
• Database architecture
• Screens, reports and interface design
• Security and system administration design
• User acceptance testing scripts

System Design Philosophy

We utilize the following high-level philosophy when designing your solution.

• Strive for simplicity. If you have a simple design that meets your needs and a very complex design that meets your needs, we should opt for the more simplistic approach. A simpler approach makes the solution easier to understand, easier to test, and easier to modify.

• Be flexible. A solution that is flexible is better than one that is rigid. “Flexible” means that the solution can be modified, enhanced and extended with a minimal amount of work to the current design. (New functions might need new design, but the prior design will not require many changes.)  It is hard to anticipate every future contingency, and there may be some future considerations that require the design to be reworked. However, when making individual design solutions, try to choose the options that will give us later flexibility over those that will lock you in.

• Work topdown. Generally we want to start your design at a high level and work our way down to the details. This ensures that the overall design is coherent and consistent. A bad practice, for instance, would be to have multiple people work on portions of the solution independently and then try to fit all the pieces together at the end.
• Visualize.  As we design the solution, it is valuable to create a visual diagram that includes all of the programs, interfaces, datastores, screens, reports, etc. This can help to visualize where all the pieces fit and how some portions of the solution interact with other portions.

Elements of Technical Systems Design

The design of the program components does not necessarily depend on the characteristics or the language of the final program, although different tools may be employed to write design specification for programs in different languages. In general, we utilize some or all of the following elements in the technical design of application components:

• Purpose. Includes a short description of the purpose of the program, why the program would be used and what the main outcome is.
• Program name. The naming convention may be dictated by organization standards. The design program name should be the same as the actual element when it is constructed.
• Overall Program Flow Diagram.  There is value in visually showing how all the programs relate to one another. This relationship typically is not random, but is based on supporting some business transaction that the user is attempting to complete. There may be many exceptions, but showing how the programs flow from one to another is valuable in understanding how the entire process typically works.
• Program number. For traceability and identification. This should fit into your overall number scheme that includes requirements, construction elements, test cases, etc.
• Comes from / goes to. If your logic follows a certain path or set of options, list the programs that can lead to this program and the programs that can come directly after. If your program contains numerous possible entry and exit points, you can describe the main transaction logic. If the combinations are too numerous, this section can be skipped. There is a design section that visually shows the overall program logic flow, and that diagram can be used instead of this section.
• Language or tool. List the tools / software used to create the program. The technology used may be dictated by the organization architecture.
• Online or batch. Indicate whether the program will execute online or in a batch mode.
• Scheduled /on request /event driven. Indicate how the program gets executed. Is it scheduled or does it run on request? If it runs on request, specify the event that triggers the program to run.
• Input and output datastores. List the databases, tables and files that this program needs. For each one, specify whether the program reads data, writes data or both.
• Parameters input. Specify whether any parameters are sent into the program, and if so, describe the variables.
• Programs called / parameters passed. Specify any programs that are called by this program, as well as any parameters that are passed to each one.
• Screens and reports. Specify whether the program interacts with a screen or report that is defined separately.
• Frequency. Estimate how often the program will run and when it will run. Some programs run on request, others run at a certain scheduled time.
• Security. The security of the program could be specified here; however, security is handled as a separate design characteristic.
• Program specifications.  This is where the program logic gets described. There are a couple ways this is done.
• Narrative specification. In this approach, the overall program specifications are described in narrative text – basically in paragraph style. The logic is typically written sequentially, as the designer describes what the program will do and in what order. Variable names may need to be mentioned to clarify the flow and to keep the logic organized; however, they are not necessarily meant to represent the exact variable names that the program will use in the construction process.
• Element edits / error message / error response. Describe any possible program errors, as well as the error message and the program response. Try to consider as many possibilities as possible so that the program does not end abruptly if an error is encountered. Your organization may have a standard set of error routines that all programs utilize.