The Other 8 Groups in the Software Requirements Audience

Do you know who your audience is for your software requirements? Why, it’s the development organization, of course! And while that is true, development is the main audience for software requirements, there are many other audience members as well.

1. Testing Team. I am sure that most of you also thought of the testing team as another audience for software requirements. The software requirements give the test team a baseline from which to write their test plan, test cases and test scripts. The test team looks not only to see if the software works, but does it work the way the user wants it to work, according to the software requirements. You may also find that your test team is an excellent group to review your software requirements for clarity. They tend to look at software requirements from a perspective of “how would I test that requirement?” If they cannot think of a way to test the software requirement, the software requirement may not be clear and/or concise.

2. End Users. What about the end user? Those who are communicating what their needs are, of which the software requirements are intended to capture? They are also an audience for your software requirements. We need their reviews to make sure we have documented their needs clearly and accurately.

3. Technical Writing. Technical writing is another group that relies on software requirements for their work. We all hope that the Help content of the product reflects what the software does, the best place for the technical writing team to get that information starts with the software requirements. Of course they will also confirm their content with the software itself, but they can certainly get started with the software requirements.

4. Translation Teams. Translation teams also rely on software requirements to help them understand what the product is supposed to do, so they can translate not only the software but also the technical documentation appropriately for their language and culture.

5. Training. Organizations that develop training courses for the software also rely on the software requirements. Like many groups, the software requirements help the training department plan and structure their curriculum, so they can develop and deliver courses quickly and that are ready for training the end users when the software is implemented.

6. Support Organizations. Support organizations, both internal help desks and product support groups that take the front line calls from customers also use the software requirements to help trouble shoot issues reported. By looking at the software requirements, Support can help determine if the issue reported is a flaw in the software, or if it is working as intended.

7. IT. Internal IT groups are also interested in software requirements. Beyond the technical requirements for hardware, software, etc that will be required to support the software, IT groups also want to understand any interfaces to other existing software that must be built. They need to understand the support requirements of the software, what sort of administrative tasks will be required of them.

8. Consulting. If you are working in a commercial software environment, your consulting organization would also be an audience for your software requirements. They need to understand the new software that is soon to be released, so they can plan implementation or migration services for your customers.

There are lots of audiences, make sure you are including them all when you design the format/layout and include them in all the appropriate review meetings.

Creating Accurate Time Estimates

I recently joined a new project where I will be working as the person responsible for the developing and creating the requirements and documentation on a major development effort. As the person on the hook for a significant portion of work, I need to provide accurate time estimates for my portions of the project. I was concerned about providing accurate time estimates on a new project in a new environment. I am also very aware that deadlines are important and know that if I am unable to accurately estimate my deliveries, I will quickly lose credibility with the rest of the team. Underestimating my deadlines might also put other team members relying on my work at risk of missing their deadlines.

My concerns had me thinking that perhaps others might be in a similar situation. After a bit of research and analysis of my own process I compiled the following list of questions and suggestions to help when making time estimates.

1. How accurate do your time estimates need to be?
   If an estimate needs to be very accurate, it is usually a good idea to take a longer period of time to consider and analyze the answer. It is not unreasonable to ask someone who is looking for a timeline for some “think time” in order to provide an accurate answer. However, when not immediately responding, it is a good idea to communicate a reasonable target for when you will have the estimates finished, even if it’s only 15 minutes of extra think time.


2. How well do you fully understand the project/tasks that you are being asked to estimate?
   If a problem is complex, or if you do not completely understand all of the tasks you need to finish, it will be difficult to make accurate time estimates. Getting as much clarification as you can is necessary. Discussing the details of what you have been asked to accomplish with the person making the request might also provide them insight into the complexity of the request and your work process.


3. How long has a task of this type taken to accomplish in the past?
   It is a good idea to maintain a personal log of tasks and an ongoing list of recorded time spent performing a task. I simply use an excel spreadsheet to record tasks I have finished on my projects and update it when I have a few moments at the end of the day or week. Having a realistic idea of the amount of time I spend on my tasks helps me to accurately predict future projects/tasks.


4. Are there any assumptions, conditions or constraints which might affect your time estimate?
   It is impossible to predict in advance every detail of a project with certainty. It will be important to note your assumptions and constraints when you provide your time estimates to communicate your issues clearly. These could all be considered risks to the accuracy of your time estimate and should continue to be monitored as you begin the tasks/project.


5. Do you need to add any wiggle room?
   You should consider adding contingency time if there is a lot of uncertainty about the tasks or many risks associated with your estimate. By increasing time to the estimate appropriately because a project is new and unfamiliar as a way to prevent underestimating your efforts.


6. Are there any other elements to the project/tasks that should be included in your time estimate?
   One area I consistently forget when creating estimates is the amount of extra time I have to spend doing administrative tasks like organizing meetings, sending emails, or organizing documents. At times, these types of activities are not always predictable, but understanding how much of your work might be effected by other project duties is important. There is a small amount of extra administrative work in most tasks, and adding that into your work estimate will help your estimating efforts.

When I employ these methods they have lead me to more accurate time predictions that have also greatly reduced my anxiety over creating self imposed deadlines that are unrealistic. As I also have an intrinsic desire to please the person asking for my time, using some standard processes in producing my time estimates has lead me to win/win situations for both my project and myself.