TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
The programmers are right. If you are going to document software, especially
for programmers or related users, you have to use their language. Actually,
no matter what you document, you have to do it in the audience's terms.
I am creating software specifications and user documents for a product
requestedby and designed for the Architecture, Engineering, and Construction
(AEC) community. Some meeting get quite interesting, since many of the
metaphors used by software engineers come from the construction industry.
You may be surprised how many definitions "specification" or "spec" has.
We write our software requirements using the software engineers' metaphors
and the user docs using the architects' definitions. As long as we meet with
each group separately, the communication works ok.
----- Original Message -----
From: "Mark Levinson" <MarkL -at- gilian -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Sent: Thursday, September 21, 2000 1:48 PM
Subject: a vocabulary question
> I said no, the dependency is the condition or relationship.
> It's the depending. It's not the thing that's depended on.
> In fact, if it's either thing at all, it's the thing that
> depends on the other, as Guam is a dependency of the USA.
> They said, well not in our world, because when we compile a
> program we have something called a Dependencies List and it is
> a list of what the program depends on.