Tag Archives: Requirements analysis

Conference 1: DREAM15

Posted on by
Reply

I recently attended three conferences here in the Netherlands. In this, and the following two posts, I’m going to describe my experiences at them.

This is post #1

DREAM15 Event

Location: Hotel Vianen, Utrecht, Netherlands

BA

In my earlier post “22 reasons why I’m Attending the DREAM15 event“ I described a conference that DREAM (Dutch Requirements Engineering And Management) were holding.

In it I had mentioned that one session didn’t have a speaker yet. I was ecstatic when the organisers asked me to fill that spot. While you can read my slidedeck from that session here, today I’d like to describe the conference itself.

Arrival

“Buzzing” is the word I would use to describe the atmosphere at the conference when I arrived. I was taken aback  at the number of people that were attending. The place was packed. And this became even more evident during the opening keynote.

Opening Keynote

The opening keynote speaker was Paul Turner. As I’ve mentioned (in the above-mentioned post), Paul Turner is one of the co-authors of the excellent book “Business Analysis Techniques (99 Essentials Tools for Success)“. Paul was entertaining while being informative, and while Paul presented in English, and the audience was Dutch, everyone enjoyed his presentation. In fact, what he had spoken about was repeated at several times during the day by other speakers. (However, Arjen Uittenbogaard, one of the speakers, commented in his (dutch) blog that Paul had given a bit of a mixed message at one stage.)

Sessions

This was where it was difficult. And the organisers, in the introduction in the morning, acknowledged that it would be . There were just so many great sessions running in parallel. It really meant that you had to make a choice.

I had intended to write a little bit about them all. I even tried this, in the morning, by watching a little bit of each presentation, running from one conference room to another, Unfortunately this was not very effective.

Brainwriting

In the afternoon, there was one session that I wanted to attend: “Brainwriting“.

Like brainstorming this technique also allows for the generation of ideas. However, unlike brainstorming that relies on the quick, and “public” shouting out of ideas, brainwriting involves lists. Blank ones. The main problem, or goal, is written at the top of the lists. Participants are divided into groups of 6, and then each person is given a list. They write their idea down on the list and, after a given time, each participant hands their list to the person to the right of them. A new idea is written down. And so on. At the end there are a large number of ideas, and these can be discussed.

As mentioned, the aim of this technique is similar to brainstorming, but let’s everyone come up with an idea, rather than just the loudest people in the room.

This was a practical session and very effective. As well as being a lot of fun. I recommenced searching for more on this.

My Session

It was a honour (and a surprise) when the organiser’s asked me to present. (You can read my presentation here).

There were more people in the audience than I had expected, and my presentation was well received. (Even considering that I presented in English – just goes to show how easily the Dutch can speak a language that isn’t their own.)

Closing Keynote

The closing keynote, by Theo Severein, took the opposite angle from the opening keynote, and looked at organizational improvement from a holistic viewpoint. This was also a crowd-pleaser.

Socialising

This is one of the big draw-cards for me. A chance to mix and mingle with other like-minded people. It also was a chance to meet, in person, people that I have been interacting with online.

During one of the breaks I was doing the rounds of the vendor standsand had a chance to meet Jan Willem Knop, one of the committee members of the IIBA NL chapter. it was really great to finally meet him in person, and learn more about the IINA in the Netherlands.

Carrying on around, I also got to meet Stefan Sturm, the Managing Director of IREB (International Requirements Engineering Board). Through some of my blog posts, and posts on LinkedIn, I been “conversing” with Stefan for awhile. Also a really great chance to meet him in person.

Just before the end of the break, I was able to introduce myself to Paul Turner (the keynote speaker). This was an honour, and I have an very, very interesting chat with him.

In fact, it was a great chance to learn more from Jan Willem, Stefan, and Paul, how the IIBA, IREB and BCS will be playing together in the new alliance/partnership that the IIBA had announced.

Conclusion

All-in-all, a great day. Great sessions combined with an excellent chance to meet, and talk with, others in the industry.

Related Links

  • DREAM site: http://www.dreamevent.nl/
  • My presentation: here
  • Zingeving voor RE’er, by Arjen Uite
  • Tweets from the conference: here

 

 

 

 

 

 

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.)