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.
On 5/10/05, ramesh k raju <rameshraju -dot- k -at- gmail -dot- com>
wrote:
Hi all
Please any could tell me how to go about requirement
specs. How to write it? What all the aspects to see
and cover? How should I plan it?
Please give me your valuable suggestions.
Thanx in advance
Ramesh
AJ Markos responds:
1.) Demystify the process. Realize that many authors
of requirements specification books - including the
popular - come from accademia and, apparently, have
little real-world experience. They often lack an
understanding of what needs to be done. I have
personaly corresponded with some who did not even know
the major thing that needs to be done - God help us
all!
Often, to hide their lack of knowledge, requirements
specification authors will be pompous. When you read
a statement like "The requirements specialist needs to
create an ontology of the conceptual schema.", run -
don't walk - in the other direction! Such writings
are real initiative killers.
Good books on requirements specification do not have
to be real hard to read. I suggest the works of James
and Suzanne Robertson. Also try the works Tom DeMarco
and Ed Yourdon.
2.) Avoid the natural tendancy to want to put your
hands on the keyboard asap. Writing comes late in
requirements specification - not upfront.
3.) Sorry, you have to model - many TW's gringe at
the "M" word. Why do you have to model? A system is
a multidimensional entity: There are potentially many
things happening at the same time, and there is often
alot of branching. Modeling techniques attempt to
capture the multidimensional aspects of systems.
In comparision, text is one-dimensional (i.e.,
linear): It is used to document one thing happening
after another.
4.) Always lead with functional modeling (task
modeling to us TWs): Only functional modeling will
prod you through a rigorous analysis. Later, create
data and system state models, if necessary.
5.) Models need to be verified: Multiple iterations of
walkthroughs with end-users are the norm.
6.) Because of Step 5, you need to become a
politican. Tom DeMarco once wrote that successful
requirements specification [for larger scale efforts]
required the political skills of Henry Kissenger.
Reason: When you are leading the way in requirements
specification, you have influence on who will be doing
what and how they will be doing it. And people are
often very resistive to loss of turf or change in
daily routine.
7.) Don't expect any real user verification if you
don't do model walkthroughs. If you only ask the
users to verify text-based requirements documentation,
you will only get some superfical changes. You can
not realistically expect rigorous end-user
verification of requirements for a multidimensional
system by only giving users single-dimensional text.
New from Quadralay Corporation: WebWorks ePublisher Pro!
Completely XML-based online publishing. Easily create 14 online formats, including 6 Help systems, in a streamlined project-based workflow. Word version ships in June, FrameMaker version ships in July. Sign up for a 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.
