10 Boilerplates and Where to Store Them
Tweet Technical documentation and proposals have bits and pieces that can be recycled and used over-and-over again. It’s like the old saying goes, “Why reinvent the wheel.” If you have written pieces and figures that you can reuse, then do it. These recycled pieces are called “boilerplates.” However, you have to ensure that you don’t use them without ensuring that it works in the documents. Here are ten boilerplates...
Read MoreTechnical Writers, Be Part of the Solution; Not the Problem
Tweet Technical Writers are a rare breed. We are not just writers or editors; we also become knowledgeable in the areas that the documentation that comes through our hands discusses. You usually become a jack-of-all-trades in the project(s) you handle. A little back-story: In my current 9-5, I am working as a Business Analyst (BA) for a few clients. What does a BA do? A BA acts as a liaison between the client and the technology group. ...
Read MoreSix Questions to Help You Write Your Disaster Recovery Plan
Tweet Natural disasters happen. There is nothing you can do because man can’t control nature. Symantec released a report, “2011 SMB Disaster Preparedness Survey,” that showed that 50% of small businesses do not have a disaster recovery plan. The most shocking part is that 65% operate in areas that have natural disasters. Even if you think that is might never happen, you have to protect your infrastructure. Think of a...
Read MoreRequirements Gathering and Analysis: Requirements Traceability Matrix
Tweet A requirements traceability matrix (RTM) is a very important tool to have when gathering and analyzing requirements. It gives you a vital resource that will help you even when the system has been implemented: bidirectional traceability. What that means is that you can trace the requirement in the entire life of the system. This is important because after a system is up and running, the requirements process doesn’t end. ...
Read MoreRequirements Gathering and Analysis: Use Cases
Tweet When you are capturing functional requirements, you usually create use cases. There are two parts to a use case: 1. Use case diagram and 2. Writing part. Use cases are used to identify and illustrate the different parts of a process. It captures: Actors Business Rules Pre-conditions Trigger Main Flow Alternate Flow(s) Post-condition Title You can’t just come up with any random use case title. The title describes the value...
Read MoreRequirements Gathering and Analysis: Non-Functional Requirements
Tweet I discussed non-functional requirements in my previous post “15 Areas to Think About When Writing Non-Functional Requirements.” Non-functional requirements are the requirements that stakeholders and users haven’t thought of, but you have to because without them, the system will fail. If you don’t collect non-functional requirements, then you will not be creating a system that behaves in the way the users need...
Read More
