: Re: How to create a functional document for in-house reference? I'm the only technical writer in my company with 2 years of experience. I have been assigned with a task of creating a functional

@Hamaas631

Vote Up Vote Down

In many ways you approach this the same way you would approach any other new project:

Review any available high-level descriptions (like functional specifications) and user stories: what is this thing and how are people meant to use it?
Identify your key contact (if you don't have one, ask your manager how to get one) and schedule an overview discussion. This is a "give Ashvita the lay of the land" discussion, not a "tell Ashvita all the gory details" discussion.
Sit down with your contact and the software and get some hands-on exposure. Don't try to cover everything; ask the expert to point out the most important and most common paths through the tool.
Start to compile questions (which will surely arise as you work with the product).

Now in addition, this product has been around for years and people have been using it, even without documentation. Either everything is completely obvious (in which case they probably wouldn't have asked you to document it) or there's a lot of "oral tradition", maybe even informal notes, wiki pages, and so on. You want to tap into that.

You should ask your key contact for pointers to any such artifacts and, also, who the main in-house users are. (They might be your own QA department, if you don't have people in-house relying on the product.) Gather the information you can.

That's all about the research part. To organize everything you need to have some sense of who your users are and how they'll use the product. The same techniques that you use for other technical-writing tasks apply here. A full treatment of user-needs analysis and organizing content would be too much for one Stack Exchange answer, but feel free to ask narrower followup questions.

(0)

Login to post a comment!