Monthly Archives: July 2013

15 Tips for Writing Better Requirements

Posted on by
Reply

tree2

Abidemi Stephanie Famuyide wrote a post a few days ago title
“15 Tips for Writing Better Requirements“.

I don’t agree with all of the tips. However there is a lot of good stuff in there. And I particularly like the last one that describes ways to word a requirement.

  1. Define one requirement at a time. This implies that the requirement should be atomic. Don’t be tempted to use conjunctions like and, or, also, with and the like. This is particularly important because it can prevent developers and testers from missing requirements.
  2. Avoid using let-out clauses like but, except, if necessary.
  3. Each requirement must form a complete sentence with no buzzwords or acronyms
  4. Each requirement must contain a subject (user/system) and a predicate (intended result, action or condition).
  5. Avoid describing how the system will do something. Only discuss what the system will do. Refrain from system design; Normally, if you catch yourself mentioning field names and software objects in the requirements specification document, you’re most likely in the wrong zone. 
  6. Avoid ambiguity caused by using acronyms like etc, approx. and the like
  7. Avoid the use of indefinable terms like user-friendly, versatile, robust, approximately, minimal impact. Such terms often mean different things to different people
  8. Avoid rambling, using unnecessarily long sentences or making references to unreachable documents.
  9. Do not speculate; avoid drawing up wish lists of features that are impossible to achieve. Saying you want a system to handle all unexpected failures is wishful thinking since no system will ever be a 100%
  10. Avoid duplication and contradictory statements
  11. Do not express suggestions or possibilities. You can identify these wherever you see statements like might, may, could, ought, etc
  12. Avoid creating a jigsaw puzzle where requirements are distributed across documents, causing you cross-reference documents. It can make your requirements specification document extremely difficult to read
  13. Do not forward reference or refer to a requirement that is yet to be defined. Again, your objective is to make the document as much of an easy read as you can
  14. Use active or positive statements such as “The system shall…” instead of stating “the system shall not…”
  15. “Shall“ should be used where requirements are being stated, “will” should be used to represent statements of facts;  while “should” represents a goal that needs to be achieved

Go and visit her site “Business Analyst Learnings” where she invites you to “rub minds”.
(There is oodles of great information and resources related to Business Analysis.)

How To Achieve Defensible Disposition

Posted on by
Reply

Characteristics of First Wave and Second Wave People

Posted on by
1

Ever since I first made contact with Michael Sampson I have been a fan of his work. Michael is a Collaboration Strategist and has written several books on the subject.

In his book “User Adoption Strategies (2nd Ed.)” he discusses First Wave People and Second Wave People. I wrote an earlier post on Second Wave People (see here), but now would like to republish something from Michael’s book that helps expand on the difference between “First Wave” and “Second Wave”:

cover-uas2

  • What-why reversal. A first wave person is attracted to the “what” of new collaboration technology, but may struggle to articulate the “why”-why the future oriented picture – to other people. They may “get it” implicitly, but struggle to put it into words. A second wave person gets the “why” (if it’s conveyed in terms of their work), but will need help with the “what”.
  • Different reference groups. A first wave person sees the use of the tool within a self-created reference group, usually outside of their organisation. A second wave person sees their own work, and the use of tools contextualized within an internal reference group.
  • Different rewards. Getting to use new tools is reward enough from first wavers, but second wavers have to understand where and how the new tools will improve their current work.
  • Speed of adoption. First wavers will quickly embrace new tools, and will learn how to do so through trial-and-error. Second wavers need greater external help and hand-holding to make the transition from current tools and approaches to work.
  • Nature of involvement. First wavers have a high degree of involvement in defining what could be done, what should be done, and how to do it. Second wavers are generally expected to follow along and do what they’re told.
  • Dealing with the old. First wavers will be quick to call the old stuff “denew technology_ad” and will move away from it as quickly as possible. Second wavers want to embrace new things within the context of what they know and have.
  • It is their job vs. It could be used for their job. First wave people often have an organisational responsibility to try out new things, and see what could be useful to the way work gets done. It’s part of their job to explore the new. For second wavers, they actually have a “real job” to do – that’s how they describe it – and the specific technology to enable interaction and collaboration is, at best, tolerated.
Related articles

The Silverback gorilla & the Outsiders – notes from a Project meeting

Posted on by
Reply

Silverback

The large male silverback stood with a menacing look on his face as the small group of silverbacks from a different territory marched into the confine. The large male’s stance, and posture, said it all. “This is my territory – I am here to protect my group.” The only thing separating the large male from the “outsiders” was a flat piece of wood sitting atop of 4 posts.

The outsider silverbacks started to grunt and gesture at a piece of paper that was sitting on the flat piece of wood. The look on the large male’s face grew even more menacing. Suddenly he puffed out his chest and beat it a few times. The outsider silverbacks went quiet for a moment. They exchanged nervous glances between each other. The alpha male in the outsider group stood resolute and gestured back at the paper.

The large silverback started beating his chest rapidly and made large scowling vocalizations. He was clearly challenging the outsiders. Again the alpha male from the outsiders stood firm, and picked up the piece of paper. He looked the large male directly in the eye.

All of a sudden the large male withdrew. He stopped beating his chest and became very mild. It was all bluff. The outsider group continued with their grunts and gestures while pointing at the piece of paper.

–  Observations from a Project Planning Meeting