Structured analysis and design help ensure that systems are economical to build and maintain, and that they produce correct results.  

Much of learning to program is becoming familiar with the rules of structured logic and how to develop & deploy basic algorithms for processing data as it is presented & putting out reports.  In this course most of the projects deal with 'sequential processes' of detecting and empty dataset, sorting, counting, accumulating, error-checking, subtotaling, &c classics of data processing.

Programming Languages, like Visual Basic or C++, are algorithmic, but each addresses the primary logical controls in a slightly different manner.  

So, it's best to learn the basic algorithms of data processing using an algorithmic notation other than a scripting language: I use Warnier-Orr diagrams to develop and teach algorithms.   More about that later, when we get into the details of the assignments...

OO analysis and design tools are particularly useful for showing the context in which components are deployed.  All good OO Design tools have methods for storing detailed, structured designs & documentation for the algorithms & scripts that make the OO systems work.  OO is covered under a separate topic, so back into Structure...  

n. 1) Something made up of a number of parts that are held or put together in a particular way.  2) The way in which parts are arranged or put together to form a whole.  3)  The interrelation of parts or the principle of organization in a complex entity.  4) Relatively intricate or extensive organization: an elaborate electrical structure.  5) Something constructed, esp. a building or part.  -- tr.v. To give form or arrangement to. [ ME < OFr. < Lat. structura < struere, to construct.]

1) The program is hierarchically organized; and 2) the pieces of each function are related to one another either by sequence, alternative selection, or repetition.

Practically, to a programmer this means: 1) Develop each algorithm using logical structures of Sequence, Alternative Selection, & 2) Avoid the use of the unstructured GOTO construct supported in most every programming language, Structured or otherwise, and which serves to lead the undisciplined programmer to a short career of spaghetti coding.  

The Input-Processing-Output (I-P-O) model underlies Structured Systems Design.  Before we get into details of structured programming, it will be helpful to consider 'information systems' and how they are structured.  The IPO model provides the context in which Structured Programs operate.

Any information system or component process can be considered as consisting of three basic parts: (1) Output, (2) a Black Box that produces the Output, and (3) Input used by the Black Box to produce the Output:

This is a good 'mental model' that has some advantages:  It's simple; it's as clear as many of the systems that you'll encounter in the Real World; and, it leads to bigger & better things.  

Before we can get into the bigger & better things we need to refine the model a bit. The Black box contains sets of Data and Actions that produce the Output. It's the analyst's or programmer's job to fill in the black box with algorithms that produce the output from the data at hand.

Detailing the contents of the Black Box starts by looking at what's required to be Output from the system or the program.  The output may be in the form of a printed report, a web page, words spoken over a telephone by a computer, or switches opened & closed on a machine of some sort.  Lots of options for interfaces & exist for each of the IPO model's component boxes.

The Requirements for Output, more than anything else, will determine a System's Architecture:  What's in the Black Box.  

System Architecture is is concerned with data that is entered, processed, stored, and put out as information.  And, it is concerned with the languages used to compose the 'Sets of Actions' Systems requirements are primarily concerned with outputs and the logical rules for their derivation.

When a program or a system is developed, the programmer or analyst must have some idea, or model, in their head about what will be produced (Output) from the system.  Any lack of understanding about this will result in a system that will disappoint its owners.  It doesn't matter how fast the system runs, what Input it accepts, or what the graphics look like if it doesn't produce the desired Output.

Let's make the I-P-O model even more complete.  Outputs & Inputs can be thought of as 'sets of data.'  Computers keep data in files & databases that are part of the 'Black Box,' which also includes 'set of actions', often called processes or programs.  

A first step in analysis is to identify exactly what the system needs to do.  Here's an overly simplified Payroll System:

Looking at the documents that are Output & thinking about (doing the analysis) what is required from a payroll system adds more detail to the I-P-O model.  Implicit in a Structured Approach is the process of continuous (or stepwise) refinement & redefinition of a design.  

Just writing down a list, ignoring logical structures of sequence, alternative selection, & cycles of repetition, is a first step of analysis.  Sharing it with the System's Users (who are generally the Real Experts) allows them to influence the system's development and help ensure that it will produce the desired results when it is delivered.  

The more guidance that users & other analysts, managers, or executives can provide an Analyst during these early sketching stages the better: It will never be less expensive to make corrections than it is during design & every error delivered to the users is potentially very expensive to fix.

At a quick glance, this rough sketch may appear complete.  But, from the point of view of the Payroll Manager or the CFO this list will need lots of refinement.  Each line in the above diagram probably needs at least a dozen or more lines of detail added to it.  Some of the Actions will require hundreds of lines of code, and a complete document completely describing the requirements for each of the I-P-O Boxes would be more like fifty pages than fifty lines. 

More about making these lists into a Structured notation in a bit.  Meanwhile lets consider how Output Requirements drive the cost of development of these Black Boxes, Is, & Os...

Any changes in Output Requirements require changes in what's in the Black Box.  It is extremely important to define the scope of a system or things can get out of control quickly.  

What if the Operations Manager, finding out that a new system is being put together for the Payroll department and realizing that Payroll expense is the largest factor in the Jobs the company sells, makes what appears to be a reasonable request for the system to provide 'Job Cost' reports that would be very valuable for the operations?

Now, in addition to Employee, Employment Agreements, Time Sheets & other Payroll data, the system needs to keep data about Customers, Suppliers, Crews, Equipment, Materials, Schedules, Jobs, &c, &c.  

For each of these sets of data, there needs to be (increasingly complex) sets of actions to process them.  I can see how a system that provides Job Cost information would be at least ten times larger and more complex than one that does nothing but process Payroll.  (And, I add the example since it's a request I had to field some years back.)  

To design a system or a program, start with the Output and work backward through the system until you finally arrive at the processing steps that are required, the data base that is needed, and finally the inputs that the system has to collect.

Starting with the Inputs doesn't work very well.  It's like starting on a trip without first deciding where you're going.  How do you know what to pack?  If you don't know where you're going you need to pack everything just to handle the weather wherever you end up.  The next problem encountered would be when you reach the end of the driveway & at each intersection -- Which way do you turn?

The importance of having goals & objectives is clear in everything we do.  One reason that so many systems are botched is because the analysis was not output-oriented.

Just as an Architect strives to produce safe, esthetically pleasing buildings & bridges with minimum materials and complexity, Systems Analysts and Designers aim to produce systems that do the absolute minimum to produce the desired Outputs.  The Output Requirements are the Independent Variables of the systems process.  

The need for structure and simplicity in systems is amplified as Output Requirements are expanded to handle a complete Enterprise.  It is not uncommon for these ERP (Enterprise Resource Planning) systems to have Thousands (3,000 - 10,000) of tables in their 'sets of data' and Thousands of processes in their 'sets of actions.'  So, the components must be chosen and fitted into the system in the simplest & most logical way.

Each of the lines in the simple Payroll Database in the Black Box above implies one or more tables in a database.  Each of the Processes implies a program with perhaps hundreds or thousands of lines of code.  Stepwise refinement in a system design will result in each table or processing step being 'exploded' into progressively more detail until databases and programs are clearly and completely described.

An Architect begins a project with sketches that are be progressively refined into exquisitely detailed building plans that are easily understood by all involved in a building project.  Where details are lacking, some contractor or worker may make mistakes in judgment that result in expensive, or fatal, errors in the building's structure.

A Systems Analyst needs a notation that can be progressively refined to a level of detail that is easily understood by all involved in the Systems Project so that they system will reliably deliver correct Output when it is put to use.  

In a beginning programming class like this one, where simple programs are used to learn basic algorithms and processes, our programs are seldom more than 100 lines of code.  In Real Systems, programs may be 1,000s of lines of code.  It's important to form good programming habits early so that you aren't overwhelmed when complex logic and the sheer length of programs make it difficult to make a correct program.

A Correct System, or Program, is one in which the Right Sets of Actions are executed on the Right Sets of Data at the Right times.  It's a Systems Analyst's job, in most cases, to determine what is right for the data and actions in a computer system.  

Users can be quite specific about what their Output Requirements are.  It is the Systems Analyst's job to help the System's Owners & Users think through the particular problems & requirements of their enterprise and come up with a System that helps everybody do their job better. 

Then, it becomes the Programmer's job to make sure that the System's scripts are Correct.  

With today's powerful 4GL languages and RAD tools (Rapid Application Development) the best situation is to have Programmers who also have Analyst's skills.  They can both sketch the algorithms for a solution & make a program for it.  They can work with Owners & Users to make the program Correct.