A model of a system is a representation of that system designed to show the structure and functionality of the system. 

Diagrams are particularly useful methods of modelling because they are able to give a broad view whilst at the same time conveying necessary detail. 

Accomplishing the same task in words is difficult. 

In terms of software development, a model can be thought of as a plan which specifies the design of the software. 

The model gives direction and specifications to the builders of the product, in the same way as the plan for a house gives builders of the house direction and specification in regard to the house’s design and erection.

Different types of modelling are applicable to different aspects of the system. 

• System flowcharts are used to represent the logic and movement of data between the system’s components, including hardware, software and manual components. 
• Dataflow diagrams describe the flow of data to and from processes and storage elements. 
• Structure diagrams describe the top-down design and sequence of processing. 
• IPO diagrams explain how inputs are transformed into outputs by processing. 
• Data dictionaries describe the nature and type of the data used in a program. 
• Screen designs and concept prototypes are used to determine user requirements by simulating the final product from the user’s perspective. 

Systems Flowcharts

Systems flowcharts are used to describe the logic and flow of data through a system.  They describe the interactions that occur between input, processing, output and storage, as well as the nature of each of these components.

Data Flow Diagrams (DFDs)

Data flow diagrams describe the path data takes through a system. No attempt is made to indicate the timing of events. Think of a DFD as a railroad map: it shows where the train tracks are laid, but it does not give the timetables.

Structure Charts

Structure charts (or diagrams) are used to model the hierarchy of subroutines (processes) within a system, together with the sequence in which these subroutines take place. Data movements between subroutines are included to improve the reader’s understanding of the relationships between them. In terms of software development, structure charts describe the top-down design of the program together with the order in which subroutines are called. 

Because subroutines can be conditionally called or repeatedly called from a higher-level subroutine, decisions and repetitions are also indicated on structure charts.