To Be a Good Writer, You Need to Practice

Everyone knows that with anything in life that the only way to get better at something is practice. It’s something that I am trying to teach my 14-year old cousin who is having problems in Language Arts. He asked my help with this because his reading and writing are not up to par. I had a brilliant idea. Kids nowadays are all about Facebook and the Internet, so why not use that to help him? I created a blog for him and asked him to write in it every day. Also, he needs to read a chapter a day in a book and tell me about it. I know that it helped me.

When I was in college, I was studying for Computer Science and was working as a System Administrator for several years. Technology was something that I was obsessed with since I was a little girl. However, I felt like something was missing. I didn’t know what, but I soon found out after I had my son. Even though I wasn’t the best Writer, I loved it. I soon found out that a career in the computer field wasn’t for me; I needed writing as well. Therefore, I changed my concentration to English where I could be a Technical Writer. At first, I didn’t know what I was thinking. Writing wasn’t one of my strong points, and I remember having to work harder than everyone else to do my college assignments. However, I kept at it. I remember going to sleep around 3:00 a.m. to write and edit my writings. Then, I was introduced to the world of blogging.

I read some of my entries when I first started blogging, and I must say that I was an awful Writer. I cringe reading some of the things that I wrote. Horrible grammar, spelling mistakes, and my blog posts didn’t flow. But, one thing was noticeable — my writing improved the more I kept reading on. Also, I got an internship as a think tank where I had to heavily edit many reports, and that helped tremendously. A major part of writing is being a good Editor. The more I edited; the better Writer I became. By being a Technology lover, technical writing came easy because I had a passion for it that made me want to get better at it. I could understand the Developers and write about it.

I hope that by blogging and reading, my cousin will improve his reading and writing. If he continues to do it, then I know that he will. It’s rare to be a natural in something. More than likely, the way a person becomes an expert is by practicing. As the saying goes, practice makes perfect.

Photo Credit: Learning how to write …, originally uploaded by Daphne Ouwersloot.

How Technical Writers Can Help on Earth Day

Today is the 40th anniversary of Earth Day, and this is a great time to think about how you can contribute in making the earth a better place for everyone to live. As a Technical Writer, I have seen my share of wastefulness when it comes to the amounts of paper people use in the office. Usually, the documents that were printed out could have been viewed on the person’s computer, or one could have been shared by all by using a projector.

If your clients are pushing for hardcopy user manuals, try to get them to see that they can put a link on their site and have an online, searchable user manual. If the user wants to, he/she can export it. Yes, I know. Users will print it out, so that defeats the purpose. Not really. Instead of printing out a user manual for each user, and then having the majority of them just have it collecting dust on their desk. Why not give them the option of searching for the answer online? This will usually reduce the amounts of people who print an actual hard copy.

After you write a document, you might also run into people who want to print it out to do their editing. I’m not going to lie, I used to be one of those people. However, I have started using track changes on my documents, and I am encouraging others to do the same. You can also push for online collaboration tools, such as Google Docs and Evernote. It’s actually worked! More and more people are doing the editing without printing out paper.

If I do have to print something out because it’s easier to edit it on actual paper, I try to print on both sides. This is especially useful if I am printing out a 100-page or more document (yes, I have written some of those). What do I do when I am done with the document? I recycle it. If there is sensitive data on it, then shred it before recycling it.

There are many ways that we can reduce our carbon footprint. The great thing about a Technical Writer is that we can also encourage others to do the same.

HAPPY EARTH DAY, Earthlings!

What is a Technical Writer?

I made this video to let people know what Technical Writers do. Wherever I go, I usually get a puzzled look come over the person’s face I am talking to when I tell him/her what I do. The great thing about being one is that it’s just not writing and editing the entire time. You actually get to test, analyze systems, and work alongside Developers to create a new system or enhance an old one. I’m lucky that I love to do what I do. When I tell someone that I love writing proposals, he/she is shocked. What’s not to like? Researching to see what the client’s problem is, and what you can do to come up with a solution that will help alleviate it. Honestly, I can’t complain about what I do.

15 Areas to Think About When Writing Non-Functional Requirements

Non-functional requirements should be defined when you are also creating and writing functional requirements. These are requirements that detail the constraints and quality standards that the system you are building should adhere to. You can find out what these non-functional requirements should be by your experience, interviews, and industry standards. Also, you can use functional use cases to try and discover what non-functional requirements should be.

Here are some areas that you should have in your non-functional requirements document:

1. Reliability - Reliability is the chance that the system processes work correctly without being aborted. Some of the potential resulting losses that you should consider are:
   • Complete or partial loss of the ability to perform a mission-critical function
   • Loss or corruption of data Loss of user productivity
   • Time between failures
2. Recoverability - Recoverability is the ability to restore function and data in the event of a disaster, either natural or man-made. Recoverability ensures that if any kind of system failure occurs, regardless of the reason, the system will operate with minimal interruption. You should think about:
   • Where backup copies of the system and data held within it will be stored
   • Discuss plans to have a Continuity of Operations Plan (COOP) and procedures for the system
   • How soon after a failure is detected must function be restored
   • How soon after corruption is detected must function be restored
3. Data Backup/Restore – Data Backup/Restore is a measure of how frequently data is backed up and the speed of data restore from backup. You should think about:
   • If the hardware, data, and onsite backup are destroyed, how soon must the application be restored
   • Do you have another site that has a full backup of the data?
   • How many backups do you have?
   • If one server goes down, how many backup servers do you have?
4. Availability – System availability is the time when the application must be available for use. Required system availability is used in determining when maintenance may be performed. Definitely think about time zones, schedules, and user location.
5. System Maintenance – There should always be regular system maintenance.  You should think about how much time you need to do maintenance, and how and when you will notify users.
6. Performance – Performance details the way the system will perform for users. Think about:
   • What is the response time for reports, queries, and updates?
   • What is the total number of user sessions open for the entire application?
   • What is the total number of concurrent sessions that can be opened by a single user?
   • What is the total amount of idle time before the user session is forced to terminate?
7. Usability – Usability is the system support of the execution of user tasks (i.e., presentation of information and management of user interaction). Think about:
   • How easy it is for user to learn the system
   • How easy it is for user to memorize steps
   • How efficient is the system
8. Visibility – Visibility discusses how the system looks to user.  Is it easy for them to see the font, screens, reports, etc.
9. Data Retention - Data Retention details the length of time that various data will be retained in the system.
10. Fault Tolerance – Fault Tolerance is a measure of how well the system can maintain normal operations when defects are encountered. Think about:
    • How every threat will be identified
    • How will you warn the user
    • Will you disable the feature
    • Will you remove the feature
11. Maintainability – Maintainability is a measure of how easy it is to correct defects in the software.
12. Interoperability – Interoperability is a measure of how easy it is to integrate the software with other systems.
13. Error Handling – Error Handling will be in place to respond to reports of security flaws in the system. Reported vulnerabilities must be tracked throughout the process to ensure they are triaged, corrected, and tested. When a security flaw is discovered in an application deployed in a production environment, notification to users must take place as quickly as possible.
14. Threat Modeling – Threat Modeling is the process of identifying potential threats to the application, risk ranking these threats, and selecting appropriate countermeasures or mitigations for the threats. Threat modeling is a critical step in securing an application from attack. The threat model will be reviewed for each application release and updated as required to reflect the changes in application design and functionality. As potential threats are discovered and the implementation details of the application become known, the threat model will be updated.
15. Reusability – You should think about having a system that parts of it can be easily reused in other systems.  This will save the company them and money in future projects.

What are some of the non-functional requirements you think about when designing a system?