May
21

Requirements in 140 characters or less. Good idea?

19 Comments

Today I read that “unless Twitter’s growth rate slowed, by the end of the year its user base would exceed the population of Planet Earth” We are starting to love twitter at Bright Green Projects – we can keep our customers up to date, look for trends in the market and find new people who might be interested in our services.  I am not using it socially yet, but professionally I am finding it awesome.

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 poSafariBGP Shot008int quickly.

Then I realised I have been doing this for years….!

How often have we seen paragraphs of text passed off as Business Requirements? How is the business going to understand this requirement? Let alone the developers that may be working in a development house in India?

I will give a short example of a requirement from a recent project I was on;

“The system will deliver accurate and timely sales pipeline reports to team leaders to ensure that they can adequately manage their busy salesforce.  These reports will be delivered to the Team Leads each day via Email and will be in the form of an Excel spreadsheet.”

This is 267 characters – and according to twitter, 127 characters too long……let’s see if we can get this under the 140 character limit.

“The system will deliver accurate and timely sales pipeline reports to team leaders to ensure that they can adequately manage their busy workforce.  These reports will be delivered to the Team Leads each day via Email and will be in the form of an Excel spreadsheet.”

So the final high level requirement could look something like;

“Deliver Sales Pipeline Reports to Team Leads on a daily basis.  The delivery mechanism shall be email and the format Excel.”

…..and we still have 18 characters up our sleeve!

Is this a better requirement? I think so.  It is concise, gets to the point and is free of waffle.  Maybe it is not as nice, or written in a friendly manner – but I think it is clear and less open to interpretation.

I know this is a simple example and requirements are usually much more complicated. But maybe in this case instead of putting it all in one requirement you either break it into multiple requirements, or make a “really” high level requirement and decompose into the children?

I think it can work and I am going to try to enhance our requirements management capability in our next release.  Does anyone else think this is a good idea – or is it never going to work?

Tags: , , , , ,

Posted in Requirements
19 Comments Posted by Adam Feldman

19 Responses to "Requirements in 140 characters or less. Good idea?"

  • Rolf says:
    May 22, 2009 at 11:25 am
    Reply

    Hi Adam,

    it is a good idea to split the complex requirement into a couple of atomic ones. For instance, you discarded “accurate and timely”. While these are fuzzy terms it is IMO not a good idea to exclude them. I’d use the 140 characters idea again and provide additional requirements for each of these qualities. Brevity is a noble goal, however. I’m afraid it’s hard to express scale, meter and at least target values for scalar requirements in 140 chars or less. Have you tried it? From an aspect-oriented point of view these qualities are crosscutting concerns, and a matrix-like separation is advisable.

    For more on atomic requirements, see
    http://planetproject.wikidot.com/how-to-determine-if-a-requirement-is-atomic
    http://planetproject.wikidot.com/writing-atomic-functional-requirements

    Great idea anyway!

    Rolf

    • Adam Feldman says:
      May 22, 2009 at 11:45 am
      Reply

      Hi Rolf,

      I am not saying that we should cut out important pieces of information, as you rightly point out, this is a HUGE quality concern. The objective should be to make sure each requirement is concise and to the point. If you are trying to convey too many pieces of information in one requirement it makes much more sense to break the requirement down as you suggest.

      Adam

  • Theo Priestley says:
    May 22, 2009 at 1:50 pm
    Reply

    Adam,

    The example provided is a real eye-opener and I hope people are taking notice here. I think Rolf is getting mixed up with Business vs. Functional requirements after following his link.

    Business requirements tend to be fluffy and open to interpretation which is why development tends to go down the wrong paths, or testing against the requirement becomes difficult.

    Yes, I agree that we could break down the requirements into sub-components if there is a need to (so, for your example, a sub-tree would explain that timeously = Daily by 5pm but I see no need to go beyond this)

    You’ve then got very concise, and very testable conditions for a test analyst to trace back to. How the IT solution is implemented is of little concern to the business user requesting it, if the development meets these very specific criteria then it’s a win.

    IT can create their wonderfully expansive functional documents to their hearts content. No-one reads them anyway ;)

    It’s a choice you can give the community Adam, simple user configurable option to limit the amount of words available per requirement, and the amount of sub-branches too (in case people start using these as a means to continue their predilection for Pam Ayres style requirements….)

    • Rolf says:
      June 3, 2009 at 3:13 pm
      Reply

      Theo,

      thanks for the critique, I need to explain that further.
      I do not distinguish between business requirements on one hand and functional requirements on the other.
      I destinguish between functional vs. scalar on one hand, and business vs. system on the other.
      The first pair is in KIND OF requirement (or type, of you prefer), the second pair is in LEVEL OF requirement.
      you wite that business requirements tend to be fluffy, and I agree. I think that this is a problem, like with any requirement that is not expressed clearly. we should avoid that at all cost.
      So breaking requirements (all kinds and levels) down to short statements is a good idea, generally.

      Good discussion anyway!

      Rolf

  • Adam Feldman says:
    May 22, 2009 at 11:13 pm
    Reply

    It really is always a fine line between Business and Functional and looking back on the original requiement now – maybe focussing on the delivery method and format is too “functional” for a Business Requirement anyhow?

    I have had some private replies and some people are not happy with the thought of having this limit imposed on them!! I then started thinking…..a big part of a BA’s job is designing Validation Rules, Workflows etc. to ensure Data Quality is maintained by End Users. These rules generally don’t work 100% of the time, but in most cases they do so data quality is improved. Maybe we don’t like these rules being imposed on us….:)

    I just googled Pam Ayres – she has some pretty funny poetry out there. Best to keep her away from your requirements Theo!

    Adam

  • Declan Chellar says:
    May 25, 2009 at 8:11 am
    Reply

    Hi, Adam.

    As I said on LinkedIn, I don’t believe a competent BA would need to have a restriction, but a junior BA might need a guide. Incompetent BAs should be handled in ways other than character restrictions.

    As for the specific example you give above, I would record the business requirement as follows:

    “The system will deliver a sales pipeline report.”

    I changed it to singular because if it really were more than one report, I would have a separate requirement for each report which made it clear (concisely) what the difference is between each type of sales pipeline report.

    I would also record some background notes as follows:

    “Team leaders require accurate and timely reports to ensure that they can adequately manage their busy sales force. Reports are currently delivered in Excel format.”

    I would leave “Excel” as a requirement for the lower level, to give the BA an opportunity to establish whether the Team Leaders really need Excel or whether they are simply carrying on current behaviour because “that’s the way we have always done it”.

    “Timely” and “each day” relate to the same thing, but I would record that at the lower level of requirements detail, perhaps as a business rule or an SLA. As part of the rule, I would note the time of day the report should be generated.

    I don’t see a place for the word “Accurate” in the requirement itself. Firstly, because who in their right mind would require inaccurate reports? Secondly, because I would see the accuracy of the reports as a function of the criteria the Business provide to be able to generate the report in the first place.

    By “business requirement” here, I mean the high level requirements that establish the scope of the solution and not the low level requirements that describe the functional behaviour of the solution.

    Kind regards,

    Declan

  • Eckhard Jokisch says:
    May 28, 2009 at 10:08 am
    Reply

    Hi Adam,
    I like the idea very much. There is one thing I would suggest:
    If you restrict to any number – and 140 is just fine – add a button to “buy” extension for more 60-character-chunks. If you track that in the database related to the requirement-Id you will have an easy way to filter for these extensive requirements. As we all might know those long stories tend to be ambigous and dangerous so we could benefit from indicators that give us hints to thos lengthy requirements.

    Regard,
    Eckhard

    • Adam Feldman says:
      May 28, 2009 at 11:22 pm
      Reply

      Hi Eckhard,

      Thanks for your thoughts on this. Something I have learned from this blog is that people do not want the hard restriction all of the time – so your idea about buying an extension might be a good one! All we really want to do is get our BA’s thinking before they write too much that could quickly become unambiguous for developers.

      We are putting together a prototype for use in our tool, so I will update everyone once we have something to show!

      Adam

  • abrahamlloyd says:
    May 30, 2009 at 11:32 pm
    Reply

    Adam,

    You know, I love the idea. One of the by-products I have found with using Twitter is that the 140 character limit has made me a better writer, regardless of the audience I am writing for. This is a great idea for generating business requirements — especially for a first pass when core ideas are being worked through.

    When developing requirements, it takes discipline to not try and “think of everything” when documenting them. “Thinking of everything” typically results in bloated documents that can be difficult to follow and consume. Brevity is powerful thing; especially in the early stages of projects.

    I’m curious; have you thought about developing a loose hashtag standard that could be used to categorize requirements? You could limit the requirements to 120 characters (similar to re-tweet conventions), and allow for the remaining 20 characters for tagging.

    Again, great idea — it definitely has me thinking of how this could be leveraged for future projects. Kudos.

    • Adam Feldman says:
      May 30, 2009 at 11:52 pm
      Reply

      Abraham,

      That is a good idea with the hashtags – we had considered using tag clouds in our tool as a way to tag things, but I suppose #hashtags could work too. My concern with hashtags is that it probably makes things a little difficult from a reporting perspective and data quality is a bit of a concern.

      At Bright Green Projects we use Twitter everyday to monitor buzz about Business Analysis and general PM stuff. Just to monitor general BA activity I have to monitor the hashtags #baot, #busanalysis, #businessanalyst which is kinda annoying as they are used interchangably on twitter. It would be just as easy for someone else to create another tag called #BAS and I wouldn’t know about it.

      What are your thoughts on data quality and reporting when using hashtags – or even tags in general, such as tag clouds?

  • Laura Brandau says:
    May 31, 2009 at 2:22 pm
    Reply

    Hi Adam,

    I like the idea. But one aspect you cut, the rationale for the requirements (to ensure they can adequately manage their salesforce), is to me important. I started writing requirements as agile backlog items in my most recent project and learned about the need for a “because” for each and every backlog item. Taking time to think through the because leads to better, more focused requirements.

    But all in all, the idea of enforcing an artificial constraint to help yourself winnow down bloated requirements and poor language is a good one. It works for all types of writing, including blog posts! :-)

    Laura
    http://bridging-the-gap.com

    • Adam Feldman says:
      June 1, 2009 at 1:40 am
      Reply

      Hi Laura,

      Thanks for your comment. I agree, the “because” is really important, especially for developers as it really helps them understand why we are asking them to build such things. My reason for taking it out of the requirement is that it is not really a requirement – more an objective or benefit.

      I am interested in your experience in the product backlog on your agile project. Are you talking about defining the value for the individual story, or something different?

      Adam

      • Laura Brandau says:
        June 1, 2009 at 1:51 pm
        Reply

        Hi Adam,

        Yes we defined the value for each individual story or backlog item. And whenever possible in the perspective of the user. Quite honestly, this was probably more enlightening for me as I guided the requirements process than anyone else. It helped me ensure we stayed focused on what was really needed instead of what was simply wanted. It also helped when reviewing the backlog with the dev team as they would propose some alternative solutions or have other ideas. We could always link that story back to a problem…which has a much broader impact than a specific requirement.

        On an interesting side note, there were some stories where the requirements was used by the customer but the internal staff was the one to benefit. (for example, asking the customer to provide a specific piece of information for audit or in-office efficiency purposes) Just the fact we tied the requirement to the benefit helped me keep perspective and side-step some potential rabbit holes.

        Given this, you might consider rewriting your requirement as the following:

        “As a team lead I receive a daily sales pipeline Excel spreadsheet via email in order to manage my workforce.”

        Under 140…I checked in tweetdeck! :-)

        I’d probably try to get a bit more specific about how the report would help a team lead manage their sales force….what are they looking for and how will it help them?

        Laura
        http://bridging-the-gap.com

  • Jonathan Babcock says:
    June 3, 2009 at 5:59 am
    Reply

    Adam,

    I’m inclined to have to say I’d be against programatically enforcing an artificial limit. There may very well be good reasons for exceeding the limit on occasion. To quote Einstein, “Everything should be made as simple as possible, but not simpler.” I like to 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.

    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 or background 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.

    I’ve posted a couple sample pics from Tweetdeck in my response on Practical Analyst to illustrate if you’d like to have a look there: http://practicalanalyst.com/2009/06/03/bright-idea-on-requirement-character-limits/

    Interesting topic!

    • Adam Feldman says:
      June 3, 2009 at 6:43 am
      Reply

      Hi Jonathan – Thanks for your reply, I will be interested in what your readers have to say too! I have posted the article on LinkedIn also and it has really stimulated some quite heated discussions!

      After everyone’s feedback, I think that the best solution is to use some kind of indicator, rather than an actual limit. I like your screenshots from Tweetdeck, we will probably go for something like this as it is quiet unobtrusive, but will still stop us from rambling too much!!!!!

  • Craig Brown says:
    June 3, 2009 at 12:21 pm
    Reply

    Nice idea.

    I saw another one on Alistair Cockburn’s blog; requirements in the form of Haiku or Limerick.

    Email Excel files
    To team leaders every day
    Showing sales pipleines

    or maybe

    A team leader received a report each day
    With someting important and useful to say
    It arrived in a mail
    In the form of excel (wince)
    And showed all the sales on their way

Leave a Comment