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.
At one point in my career, I lead, what was at the
time, the largest functional specification effort in
the USA - maybe the world.
The reason you are having a tough time reading
functional specs is because functional specs were
never meant to be written - especially if you want
integration.
An information system is what requirements engineers
refer to as asychronous: Many things potentially
happening at the same time and many branchings. Text
is linear: One thing happening after another.
Actually, you can write pretty comprehensive
functional specs, if you first create rigorous,
comprehensive graphical (i.e., multi-dimensional)
model of the system, and then use that model as the
framework to organize your text. This is how you will
be able to tie things together.
Designers don't create functional specs. They use
functional specs to create design documentation. A
designer can translate a properly partitioned
functional spec into a real good design (i.e., a
design that is lightly coupled and highly cohesive).
The main high-tech cultural assumption behind
functional specs: Postpone the pains of integration
until the Tech Writer gets the spec.
I'm finding that reading
> func specs is a bit
> like staring a blade of grass under a microscope.
> I'm looking for a
> more integrated approach.
>
> Could anyone help me understand better the high-tech
> cultural
> assumptions behind func specs? Would it be
> unreasonable to suggest that
> a func spec contain these elements?
>
> 1. Relate the particular functionality in one func
> spec to the business
> requirements it serves
> 2. Discuss the design philosophy as it relates to
> the particular func
> spec.
> 3. How one particular func spec fits into the
> entire functional map (I work with about 45 func
specs)
Has anyone here written func specs? What sort of
guidelines/outlines have you found most useful?
WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo: http://www.webworks.com/techwr-l
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.