Join my Requirements Cloudburst!

A Cloudburst is a novel idea. It’s an online discussion focused on a word cloud. Everyone chimes in to contribute their ideas.

Take a look at this word cloud I made about Software Requirements. Add your thoughts to the discussion in the comments below! What do you think?

Let’s Hear From You

Do you work with software requirements – either suggesting and submitting them, writing and qualifying them, or putting them into code?

  • Which of the ideas in this word cloud speak to you?
  • Are there some you strongly agree with?
  • Are there concepts that are missing?
  • Anything here you think doesn’t fit?
  • Does more need to be said about some?
  • Which ones ring true?
  • Which are a surprise?
  • Which ones weren’t obvious to you at first but you’ve come to value their importance?

Check back in to learn what others are saying about software requirements.

— Jacques Murphy, Product Management Challenges

ProductManagementChallenges.com

 

4 Comments
  • Jacques Murphy
    January 15, 2018

    I like how this word cloud does a nice job of bringing in the many factors involved in requirements, from wording to priority to the many sources of ideas for new capabilities, from channel partners to customer support.

  • Jacques Murphy
    January 15, 2018

    It’s also interesting to see the importance this word cloud gives to using clear, consistent, factual wording for requirements. I’ve found that clear, factual wording – with examples where appropriate – is the way to efficiently take requirements from a jumble of wishes and complaints and turn them into workable instructions for software programmers.

  • Jacques Murphy
    January 15, 2018

    Sign up to receive any summary and analysis I do of this discussion, and to get new ideas on software product management in your inbox from time to time. There’s a signup form near the top right of the page. On a mobile phone, it appears near the bottom below all comments.

  • Jacques Murphy
    January 15, 2018

    When it comes to the idea of figuring out the ROI of requirements, my experience has been that it’s a good idea which is just too hard to execute. Instead, I have gravitated towards specifying a Benefit, a softer, less numbers-based version of ROI. Even when you can’t get specific about the dollar value of a requirement, you can express a Benefit which makes it clear to all involved why a given requirement is being requested.