Word is that the technical writing profession is changing—those of us who want to stay in it must expand our knowledge and skills. In the past year and a half, I have had the opportunity to work as a requirements writer. Writing requirements is an incredibly useful tool that can lead to great, and great paying, job opportunities.

Through on-the-job trial and error, I learned the ins-and-outs of requirements. Requirements writing tells a customer and programmer “what” a program should do. After analyzing the needs and tasks of the customer, a requirements writer sits down and writes out every detail, leaving no “what” decisions to the programmer. The writer does not tell the programmer “how” the requirements should be fulfilled, allowing the programmer to design the best implementation for the program.

Key skills for writing requirements are writing, and task, user, and needs analysis. Those skills sound familiar, don’t they? And don’t you wish that the programs you documented were just better in the first place? As technical writers, we have the skills for requirements writing and the background of understanding user needs. However, requirements writing requires patience and good relationship-building skills. You must build respect among your clients and coworkers for your ability to do your job, and you must be able to make decisions based on all kinds of feedback from the customer, development, and quality assurance, and then stand by those decisions in light of competing interests.

Some say that Karl Wiegers is the “requirements guru” but, as a beginner, I found his writing somewhat incomprehensible. The Software Productivity Centre does seminars, although these can be quite expensive. Look up “software requirements” on the Internet, or on amazon.ca, and go from there. See if your company needs any feature created or designed, and then ask if you can do it. If programmers are doing the designing, then they’ve got nothing to lose by letting you try it.