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.
Re: Trying to estimate the time it will take to write an SRS.
Subject:Re: Trying to estimate the time it will take to write an SRS. From:Tony Markos <ajmarkos -at- yahoo -dot- com> To:"Jennifer C. Bennett" <fritillary -at- gmail -dot- com>, TECHWR-L <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Wed, 18 Jan 2006 18:12:41 -0800 (PST)
Jennifer:
Then your first task in writing requirements specs is
not writing at all, but discovering what the
requirements are. After you have discovered the
requirements THEN the outline templates discussed in
the links you mentioned come into play.
Find out if your (sole) SME has a comprehensive,
integrated understanding of the requirements - or only
a partcial understanding of what he wants. What is he
going to give you to base your writing on - Structured
Analysis models? Use Cases? Some sort of written text?
Verbal statements?
If he is going to give you one of the last two, you
can pretty much bet that his understanding of
requirements is disjointed (i.e., not fully thought
through).
Whatever he gives you, you will need to walkthrough
your understanding with him (typically through at
least a couple of iterations). Use diagrams - not
text for this all important step. Depending on the
system functional, data, or state diagrams may be
necessary.
Focus first on the business requirements. Once you
have a comprehensive, integrated understanding of the
business requirements, you have an sound overall
architecture into which you can "pigeon hole" a large
amount of implementation-specific and non-functional
requirements. The tough part of doing this is the
need to postpone detail - postpone not forget - until
the appropriate time.
Especially, if your SME is an engineer, you must
really strive to keep the discussion in business terms
- not technical - until you have your overall
architectural understanding.
Once you have a sound overall architecture, the major
part of organizing your docs is pretty much straight
forward. And modifying an outline template as
necessary is easy.
Tony Markos
--- "Jennifer C. Bennett" <fritillary -at- gmail -dot- com>
wrote:
> Hi Tony,
>
> Thanks for your reply!
>
> Well, I am not designing the application, so I am
> assuming my role in this
> project will be to interview the individual who is
> designing the application
> to get the requirements information, and then
> incorporating his ideas into a
> formal SRS format. He says he knows what he wants,
> but he wants a writer to
> formally convey this information to the developers.
>
> Jennifer
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l