How to Distinguish Between Input Processing and Output Requirements in Program Design
- 1). Read any business requirements documents. If there are written documents available documenting the business requirements, this is a good place to start identifying potential inputs and outputs for your program. If no such documentation exists, it might be a good idea to write out the requirements of the program in English and what it is intended to achieve. This can be done in simple bullet points.
- 2). Design the program using a design technique. Program design is an "old school" programming theory, but it is one that comes in handy when trying to identify items in your programs which process input and output. The design needs to reflect the inputs and outputs in a business, or in a generic sense. For example, a typical business requirement stated as follows -- "Run down the list in the transaction file, and update the master file before producing a report" -- translates to the following inputs, outputs and processing:
Inputs -- Transaction file
Processing -- Update master file
Outputs -- Report.
The design technique chosen may be down to personal preference, but data flow diagrams, entity relationship modeling (databases) and Unified Modeling Language (UML) are all useful techniques to draw out a plan of the system, including identified inputs and outputs, before the program is written.
For less sophisticated programs, a simple list like the one produced above directly from the requirements will usually suffice without an additional design stage. - 3). Write the program and test the inputs and outputs. Once the program has been completed, test the inputs and outputs against the original requirements and any design you have drawn up. If the inputs and outputs all achieve the original stated intentions, you have successfully identified and implemented input/output processing as required.