Archive for Requirements

JibJab

Send your own ElfYourself eCards

Comments (1)

Busy, busy, busy

Last months I was too busy to keep up blogging, but better times are coming!

I have spent lots of time getting things organized for my mother. After a long wait we found a good place for her in a home for elderly right here at Nijmegen (Netherlands) at 10  minutes biking from my place.

So last months we did her removal to Nijmegen, emptied my mothers house, sold lots of furniture and other things on internet and finally, this week,  sold the house.

For my company, Getronics, I also participated in a trip to our offshoring partner Mindtree in India. That made another busy week with long, interesting days. I must say that I’m really excited about the things I saw at Mindtree. I’ll blog on that soon.

Tomorrow night I’ll deliver a presentation on our Indian trip (Getronics organizes an Indian Night with food and presentations). I’m having 40 sheets, 30 minutes, expect 20 questions and have 10 long answers. Not exactly the 10-20-30 rule on presenting from Guy Kawasaki.

After that, I’m going to take it easy for a couple of evenings, read some articles and books (especially Karl Wieger’s More about Software Requirements) and pick up blogging again.

See you all soon

Harry

Leave a Comment

How to present for reaching agreement (and let RUP help you)

Guy Kawasaki (from my post last year on top ten lies of engineers) has a 10/20/30  rule for any PowerPoint presentation aiming to reach agreement.

It’s quite simple: a PowerPoint presentation should have ten slides, last no more than twenty minutes, and contain no font smaller than thirty points.

An example are presentations used to convince venture specialists to invest in your product. According to Guy, the ten slides should be:

  1. Problem
  2. Your solution
  3. Business model
  4. Underlying magic/technology
  5. Marketing and sales
  6. Competition
  7. Team
  8. Projections and milestones
  9. Status and timeline
  10. Summary and call to action

As you can see, another use for the RUP problem statement (1. Problem) and product-position statement (2. Your Solution).

Comments (1)

How to be a bad/good productmanager (and let RUP help you)

How To Be A Good Product Manager is a blog written by Jeff Lash that provides regular tips on good product management practices. While it focuses more on managing technical and online products, most of the concepts are appropriate for broader product management purposes.

I especially like the format of the posts, which follow the format:

If you want to be a bad productmanager, <follow some things you should not do>

If you want to be a good productmanager, keep reading ->

I was attracted to this site by the post stating Track customer requests appropriately and gave some RUP-related advice there: use your problem statement and product-position statement as tools for deciding which customer requests to include in your next release.

Leave a Comment

Blog-tagged – truth or dare for bloggers

There is a game of Blog-tagging going on, which works like a kind of chain-letter.

The idea is that the person (owning a blog) that gets tagged, shares five little-known facts about him or herself and tagges five other persons (owners of blogs).

I got tagged by former collegues Raimond Brookman, who shared five secrets of which I new three (he’s tall, plays squash and loves meat) and Jeroen Leenarts (of which I knew about the Apple, but was surprised about the alcohol).

So here are my five little known facts:

1. At the age of 18, I was homeless for two months in Utrecht, Netherlands. In that period I slept in a shopping centre and in the weekends worked in a bar that opened at 01:00 and close at 06:00. 

2. One of the jobs I had before entering Computer Science was wedding photographer.

3. I ordered a new car, a Ford S-Max.

4. I’m married with Betty, have three daughters (Lieke 16,Ellen 14, Manon 12) and a dog (Sieta)

5. Harry is my usual name, but my original name is Harm, and I’m having my aniversary on Christmas Day.

I would like to blog-tag the following bloggers:

1. Scott Sehlhorst 

2. Marcus Ting-A-Kee

3. Micahel Hunter (The Braidy Tester)

4. Stephan Okhuijsen

5. Dilbert

Comments (1)

Security in Use Cases

Many efforts are being made to integrate security into software and software development. I lately read several interesting posts about the subject, two of them from Gunnar Peterson

Gunnar Peterson

In an IEEE Security & Privacy Journal he co-wrote an article on Misuse Cases with John Steven on Defining Misuse in the Development Process.

Here’s in short what is the core idea:

Use Cases vs Misuse Cases

I remembered having seen the idea before, as Richard Claassens, a former collegue and Architect at InfoSupport showed some examples that came from the original ideas behind Misuse Cases came from Guttorm Sindre and Andreas Opdahl.

Here’s a nice example:

Misuse Case diagram

Leave a Comment

Early overtime == later project completion

Crossing the desertJohanna Rothman wrote about avoiding the “Crossing the desert syndrome” some years ago.

“A project team focuses on an interim milestone, works like the devil to meet that milestone. They meet the milestone, look up, and realize they’re not at the end of the project–they still have to finish the darn thing. They’re living the Crossing the Desert syndrome”

Recently she gave advice on how to recover from the syndrome.

At Tyner Blain, Scott gives advice on how to prevent from hitting the syndrome: 

  • Improved estimation of tasks
  • Realistic effort allocation
  • Writing verifiable requirements
  • Managing smaller work chunks
  • Feedback into the estimation cycle
  • Better communication of release content

As I read his advice I thought: “yes I agree that’s good advice, but somehow good advice is seldomly followed”.

 BTW: Patrick van Lee, a relative from my wife,  rides the Dakar race on an Aprilia motorbike

Comments (1)

Older Posts »