Adam Feldman, blogging from Bright Green Projects’ “Bright Ideas” blog poses a fun and interesting question. Twitter limits entries to 140 characters. Should we do the same for requirements? Per Feldman,
One of the things that first annoyed me about twitter was that the messages are restricted to 140 characters. It is hard at the start, as you don’t want to lose the point of your message, but after a while it becomes much easier, you stop using flowery words, are careful not to repeat yourself and make sure you get to the point quickly.
I know that I and many other BA’s are guilty from time to time of writing requirements that are longer than they need to be. Good requirements are concise. I’m reminded of one of my favorite quotes (of debatable origin), “I’m sorry this letter is so long, I didn’t have time to make it shorter.” It seems to take some real mental conditioning to drop extraneous words and phrases. It’s definitely something I’ve struggled to get better at.
So, about the 140 character limit. I’m going to have to say I’d be against programatically enforcing an artificial limit. There may very well be good reasons for exceeding that limit on occasion. To quote Einstein, “Everything should be made as simple as possible, but not simpler.” I like the incentive to be as simple and concise as possible, but I’m not overly keen on having an analyst have to oversimplify to fit a requirement into a character limit.
So, Adam, what would I do if I had a nifty new web-based requirements management tool (which he does, by the way)? I think I’d let the analyst type away, but much like Tweetdeck and probably other Twitter applications, I’d give the user a visual indication (change text color, or something not overly intrusive) that they’d exceeded 140 characters, only I wouldn’t truncate the requirement if they decided to keep it a little longer.
This way, you’ve got the analyst thinking about keeping it short to make the “suggested” character length, but not forcing split or incomplete requirements with a hard and fast rule.
Anyway, there is some good discussion in the comments section for the original post. Go check it out and chime in, I know Adam will appreciate the feedback.
Oh – One last thing – if you do go with the limit, please, please don’t call them “tweequirements”!
I love the idea! The character limit really makes you think about what is important. A number of years ago United Technologies ran a series of ads in the Wall Street Journal. One was "Keep It Simple" that reads in part "David Belasco, the great American theatrical producer, once said: “If you can’t write your idea on the back of my calling card, you don’t have a clear idea.” Well put. The entire ad is at http://mikeschaffner.typepad.com/michael_schaffne…
Thanks for that reference, Mike. I like the calling card bit.
While I was over there, I paged through some your other "effective communication" posts as well. I always learn a few things or at least come away with a new idea or two when I poke around on your blog. Great stuff!
Of course my reluctance to jump on the 140 character wagon for requirements probably has something to do with the fact that I still have a hard enough time dealing with the limitation on Twitter!
Hey Jonathan – I promise that we won't call them tweequirements, I think that would be taking the concept a little too far and I am not so sure our stakeholders would take us too seriously!
We have decided that in our next release we are going to implement a solution very similar to the example you have given above. What we are going to do is have a small count next to the field that is green up to 140 characters, is amber between 140 and 175 and anything over 175, is red.
I think that having the indicator will be enough to remind people to try and be concise, without just being a hinderance on their work.
The idea is good. The requirements should convey what the customer needs and that needs has to be delivered to the customer following the SDLC cycle. Having req in 140 char means to put the expected context of requirements in simpler way.
Thanks for the comment, Ambika, and welcome to Practical Analyst. Agree that simple is good – as simple as possible, but no simpler!
Good stuff, Adam. Great idea on the initial article. It's been fun following the conversation here and over on your blog. I'll look forward to the new feature in Bright Green Projects!