Seilevel
Seilevel Home
Back to Blog Home - Requirements Defined

Thursday, December 20, 2007

Context, Please

Imagine I told you “Go do 5125558679”. I bet you’d be a bit perplexed. On the other hand, if I told you “Please call Tom at 512-555-8679 and give him an update on the project status,” you’d have a decent idea what to do. And, if I handed you a piece of paper with just 5125558679 written on it coupled with the verbal request, that would probably be sufficient to complete the task. Of course, if you needed Tom's number in the future, you might have trouble finding it.


Unfortunately, a lot of SRSs I see look like “5125558679.” And, I’m afraid to admit, some of the SRSs I contribute to make a giant leap forward and looking like “512-555-8679.” They have the critical information people need right now. But, no real context. We’re all moving so fast, that we tend to only have time for the critical.


But, what is the cost of this? Those intimately involved with the project know what to do, but anyone coming in fresh is totally lost. Further, over time, even those intimately involved can forget the meaning. Documents in which a lot of effort was invested become at most marginally useful.


When writing documents, please remember your audience is typically not just the audience you know about now, but also unknown readers in the future. Give them a little context. In fact, I have some I’m working on right now that I realize could use a few sentences that would add a lot of context for that unknown reader…
Requirements Defined Newsletter Bookmark and Share

4 Comments:

Blogger Unknown said...

David Allen suggests the same for your everyday tasks in his Getting Things Done book. You should write tasks as actionable items. The same goes for requirements, especially since you're not the one implementing most of the time.

12/20/2007 11:00 AM  
Blogger Terry said...

When you think of requirements from a cost perspective, you cannot only consider the cost of gathering the requirements correctly. You must also consider the cost associated with reworks due to incomplete or unclear requirements.
Maybe you should rephrase your question to say which is more cost affective? Doing it right, or doing it twice?

12/27/2007 10:48 AM  
Blogger Roeland Loggen said...

Completely agree and good to see someone write about this.

How many times I have seen people come up with documents with no header, no author, no date, no subject, no intro, pffff.... Of course, during the project we all understand. But add new people on the team, or after the project someone reading - confusion everywhere. It's why I force myself to include in any document at least:
- Intro: why this document, goals, context, stakeholders
- Open issue list: what has NOT been answered or decided upon in this document (and should...)
- History list: who created this document when, who revieuwed it, who updated it
- Definitions: for some of the words and abbreviations a short explaination.

Sure, people around me during the project complain: my documents are always so big. :-). But when transfering my tasks or closing & delivery projects to support organisations, I get a lot of credit....

Regards,
Roeland Loggen
process-transformation.blogspot.com

12/29/2007 7:49 AM  
Blogger Anthony C. said...

This post is being discussed here:

http://www.seilevel.com/messageboard/showthread.php?t=822

1/02/2008 8:49 AM  

Post a Comment

<< Home