Create Technical DocumentationLO2
Create Technical DocumentationLO2
LO 2: Design documentation
Information Sheet 1 Technical documentation basics
Figure 1 below helps map the process of creating technical documentation, where requirements and standards
are on an equal level as starting points in the process.
Before gathering and validating requirements for any particular documentation to be created or reviewed, it
helps to understand some basic requirements as they apply in general and to all forms of technical
documents.
times documents can easily be overlooked and lost. The idea of working on documentation may have less
appeal than working on a computer desktop.
Yet any sense of dread and futility related to documentation is misplaced. Documentation is crucial in many
respects. Collectively, it is the means by which an organisation systematically understands itself and its
purpose, to then develop and grow. In the IT industry, fulsome documentation is also a basic requirement for
finished work to meet client needs.
In the information age businesses are built on platforms that process, capture and disseminate information,
and that platform is supported in all its parts by a range of technical documentation.
Understanding the policies, procedures and methods for document control that exist in an organisation is an
important part of requirements specification. This understanding is also a precondition for the later design,
review and production of documents. If requirement specifications also encompass a system of
documentation, then the specifications may include the ways and means used to manage documents and
version control.
Manual or informal systems for recording data and records can create confusion, mistakes and delays, as
technical workers waste time searching for the information they need, or recreating data that already exists.
The key point is that information in a document, regardless of its format or media, should be well managed.
Configuration management
Depending on the medium, an organisation’s policies for storage of documents will discuss where
documentation is to be kept and how it is to be accessed. That documentation may be paper-based, on a
server somewhere or backed up onto a CD. It is important the procedures for the storage are created and
adhered to, and these too may be a precondition or a part of requirements specification.
Configuration management refers to the storage and security of documents. Table 2 below is an example of
configuration management.
Draft
(destroy when master copy is available)
Master copy
Baseline digital copy
Hard copy master
Baseline control, as shown in a template in Table 3, refers to the minimum level of support and control for
documents. Again, templates help ensure that this level of information is on all documentation.
Author
Project manager
Reviewer
Gathering details of different, sometimes conflicting needs involves forming a clear understanding of
relationships between goals (the different reasons why), functions (what for) and constraints (limits of scope
and budget etc). You will need to understand system behaviour, how communications are organised, the
information technology, and definitions of acceptable service.
You can now begin to work out what technical documentation is required by an organisation by asking:
What documents does the organisation need?
Why doesn’t it have them already?
What documents exist that aren’t necessary?
What are the documents used for and by whom?
What information should they include?
What format will they have? What style will be used?
Where is the information collected, where does it go?
How are the documents stored?
What will happen if you don’t have them, or they aren’t reliable?
Table 4 outlines and comments on types of requirements for technical documentation.
e 4: Categories of requirements
Collecting requirements
Before technical documentation requirements can be analysed they must first be collected. Ideally, the
collector needs to take into account every point of view and fact. The ability to do this will depend on the
time, budget and available resources. A good start would be to interview the person who has asked you to
determine the documentation requirements, to get a clear idea of:
what result is expected or needed
the amount of time you have
a budget for the project
who will help you
What authority you will have.
Some techniques to gather requirements include:
inspecting the documents and their use
interviews, workshops and use cases
Sample documents, templates and checklists.
On the internet there are many resources where you can refer to and compare sample documentation systems.
Documentation specialists use several techniques to dig below the surface and get to the core of
requirements. Some of them are briefly described here.
Evaluating requirements
When asking clients, users and stakeholders what they believe a document system must have, you can be
silently asking yourself, is this requirement:
Necessary? Can the organisation meet its needs without the technical document? If the answer is yes,
the document may not be necessary.
Supportable? Can the requirement be supported in the documentation system? If not, the requirement
should be checked or changed.
Unambiguous? Can the requirement be interpreted in more than one way? If yes, it’s time for more
interviews or editing.
Complete? Is there anything missing? Better to have stakeholders review the specifications now, than
have problems later.
Dependable? Are there conflicts with any other requirement, or other parts of the system?
Acknowledged? Is the source of the requirement documented? Are reviews cross referred to the source for a
double check?
Identified? Can other people readily find and identify this requirement, in case of later need for
amendment?
Once you have an ordered and integrated list of needs and recommendations, you should ask the participants
to review your interpretation of their requirements. This document is really the basis for the first draft of the
requirements specifications.
Validating requirements
It is not unusual or unrealistic to expect that not every one will agree with the requirements specifications
that are proposed. There may need to be some resolution procedure in place, if negotiations don’t lead to
consensus. The final word belongs with the client, or project sponsor, to resolve issues and make final
decisions.
Submit a draft of your specifications to select users. Ask them for feedback. Can they comply with these
specifications when they create documents? Ask them to create or amend a document using these rules.
When others use documents created to these specifications, will their work benefit from them or be
constrained?
If you’ve used a reiterative process in forming your recommendations (by circulating drafts, for instance),
and kept participants informed of your reasons, then you should not have too much trouble getting
consensus.
OVERVIEW OF SCOPE OF WORK
A scope of work sets forth requirements for performance of work to achieve project objectives. The scope of
work must be clear, accurate and complete. SOWs have to be read and interpreted by persons of varied
backgrounds, including performing contractors and their suppliers, project managers representing
departments or offices, and the contracting officer. Therefore, the SOW should be worded to make more than
one interpretation virtually impossible.
Developing a scope of work presents unique problems, because each SOW is designed for a unique
procurement action. A normal procurement specification, such as a purchase or supply contract, is used to
procure standard products and repeatedly used services.
But a scope of work is mainly used to procure a variety of nonstandard services, as well as development of
software and hardware, and construction. Thus, no uniform SOW format can be applied, but guidelines can
be followed to achieve an end product that meets the specific objectives of the contract.
The difficult and sometimes controversial function of proposal evaluation and source selection is based
largely on a scope of work, which is the baseline standard for evaluating all proposals, for reconciling them
to design or other requirements, and for determining the best approach to competition. Evaluation criteria are
based on a scope of work that defines project objectives and requirements for their achievement. Challenges
to the proposal evaluation and source selection are almost always traceable to an uninformative or ambiguous
scope of work. Any scope of work must cover the following points:
What needs to be done
Who will do what
When it should be done
Where it should be done
How contract performance will be judged
The scope of work may also define how the job is to be accomplished. When objectives are not well
described and defined, misunderstandings are likely. Ambiguous SOWs can lead to unsatisfactory
performance, delays, litigation, and high costs. (Section deals with specific SOW language.)
Scope of Work Format
Although the elements of a scope of work can vary with the objective, complexity, size and nature of the
work to be performed, a flexible, seven-part format provides a practical approach to document drafting. The
suggested seven parts are:
I. Background
II. Scope
III. References
IV. Requirements include schedules
V. Progress/Compliance
VI. Transmittal/Delivery/Accessibility
VII. Notes
Summary
In this reading, while keeping in mind the attributes of good documentation, you focused on investigating the
goals and needs of an organisation to determine its requirements for technical documentation. The
importance of document control for later processes of design and production was discussed. The basics and
importance of determining document scope and having requirements specifications validated, was also
outlined.
Progress
Have a look at the next section—Activity. If you have trouble, review this reading or perhaps take a look at
some of the listed Resources.
When you feel ready, try the Self check section at the end of this topic. This will help you decide if you are
now able to complete the task and attempt assessment.