All writing, especially expository writing, is about using a system design. In a pattern familiar to any systems engineer, the writing project begins with high level requirements that will decompose to lower level requirements, a functional map for meeting those requirements and a particular physical implementation.
The effective author begins by stating the purpose (sometimes called the thesis statement) and proceeds to create a logical argument that satisfies it. This argument is the logical architecture of the paper. The purpose statement norms the logical architecture and directs the design of the writing in the same way requirements norm and direct the design of a systems solution.
The logical architecture of the document is constructed using the statement of assumptions and the ensuing propositions that will lead the reader from a commonly understood position in the problem space to the conclusion that satisfies the purpose statement.
The writer then uses the components (words, sentences, paragraphs) to build a document that implements the logical argument. Finally the paper is tested against the requirement(s) to see that the purpose is met.
That seems overly simplistic but it is surprising how much of our writing fails to follow that process. Too often the result is writing that fails to fulfill its purpose in one way or another.
Suppose, for example, that we are asked whether or not we can complete a project on time if we make a given set of changes to the design. We would begin with what we know:
- Today is March 15
- The project due date is June 15.
- Our current schedule will take 75 days to complete
To that we would add the key assertion (argument):
- The proposed change will take 45 days to complete
This would lead to the conclusion:
There is not enough time to complete the change by the original project due date.
We have a high level requirement (deliver an opinion on the potential for delay if a given change is made). Now we have a high level logical architecture (We have 90 days to complete the project. The current work will take 75 days. The change will take an additional 45 days. The total time to complete the changed project is 120 days. Therefore we cannot complete the project with the proposed change by the 90 day deadline.)
This allows us to begin to flesh out a physical design for writing. It is helpful to begin with a statement of the conclusion we will reach. “If we make the proposed change we will have to extend the project deadline by at least 30 days.” Then we can construct an outline beginning with the assumptions and/or facts (Today is March 15. The project is due to be completed by June 15. That gives us 90 days to work assuming we do not add shifts or workforce.). From there the paper continues with the argument (the proposed change will take an additional 45 days).
We allocate each of these sentence statements (assumption, fact, and proposition) to a unit of the document. Sometimes these can be paragraphs with each statement becoming the lead sentence of a new paragraph. Each item of evidence that supports each proposition then becomes a sentence in the paragraph. In our case this would create something like the following outline:
Introduction- If we make the proposed change we will have to extend the project deadline by at least 30 days.
P2- We have 90 days to complete the project by the current deadline.
S2- Today is March 15.
S3- The project is due to be completed by June 15.
S4- That gives us 90 days to work
A1- assuming we do not add shifts and
A2- assuming we do not add workforce.
P3- The proposed change will take an additional 45 days
Conclusion- If we make the proposed change we will have to extend the project deadline by at least 30 days.
This process produces a high-level design of the writing project. The next step is to drill down into the logical and physical architectures to refine the design and make it even more effective.
