Friday, October 25, 2013

Software Requirements 3, by Karl E Wiegers, Joy Beatty, Microsoft Press


One of the areas often overlooked when writing software systems is thoroughly understanding what needs to be developed. Specifically who are the users that are going to interact with the system, what are they trying to accomplish with the software, and how is the system expected to behave under normal and error conditions. In short, developing software requirements and specifications before the software is written.

"Software Requirements 3" addresses these questions, with clear answers and advice in a rather longish format of roughly 673 pages.

The book starts with a story about the importance of software requirements: a case of an employee who changed her last name without getting married, and the accounting software's inability to handle the change, with the repercussions that the employee will not get paid until the the "bug" is fixed. The book mentions that this is not an atypical situation, and that 
... errors introduced during requirements activities account for 40 to 50 percent of all defects found in a software product
The book proceeds to explain how to prevent problems like these from happening in the future, through explaining the mechanics of requirements gathering starting with defining who the customer is, and who the decision makers are, followed by a tour of the requirement gathering process, including requirements elicitations, and appropriate documentation.  The book advocates readable, concise, and precise requirements documentation, and ample use of imagery to explain difficult concepts.

The book offers advice on how to reduce development risk, through frequent customer checkpoints as things are developed, to minimize the mismatch between customer expectations, and what developers build. The book also advocates building prototypes to illustrate concepts, and drive conversations to minimize the gap between what's being build, and what customers expect.

The book addresses the often ignored fact that requirements frequently change during the development process, and offers a full chapter on handling these changes, and tools for managing the changes.

The book is geared toward the business analyst, but software engineers would benefit greatly from reading it. And despite the book's length, the authors' writing style is approachable, and it was a pleasure to read.

Sunday, October 6, 2013

Sign language

One of the frustrating things for new parents is that their baby's communication is usually 1-bit: the baby is either crying (on), or not crying (off). When the baby is crying it is for different reasons. They could be:

  • Hungry
  • Sleepy
  • In need of change
  • Hot
  • Cold
  • Over-stimulated
  • Bored
It is hard to decode these competing and sometimes conflicting needs, although some people claim they can from the tone of the cry, and its duration. Lucky them.

Most parents look forward to their babies' talking so that they can communicate their needs. What they don't realize is that when the talking stage arrives, so does the arguing stage. I am looking forward to that.

It turns out we don't have to wait that long. We can teach babies sign language early on, and it will help them communicate their needs through signing as early as 6 months, which sounds like a blessing. There are a ton of videos on youtube that teach baby sign language but nothing beats attending a class, especially one that gives you the history behind the sign, and why it was chosen to mean what it represents.

The class was short and sweet, an hour and a half, and covered about 60 signs that you can teach your baby that are relevant to their needs as they grow. The most important ones to remember are of course milk, hunger, thirst, sleep, hot, change, cold, bored, over-stimulated, toilet and poo, but there were others such as walk, run, jump, stop, go, and colors. The signs are relatively simple to perform especially before the baby's finer motor skills develop. I can't wait to use these.

More water please

At work I always enjoy chatting with our lead designer, who is also a strongman, and competes in strongman competitions. In addition to talking about design, I love to pick his brain about how to become more healthy and fit, and he is very generous with his advice and the lessons learned during his training. One day I noticed that he is filling a huge one gallon bottle of water, and I could not resist to ask why.

He explained that he needs to drink more than a gallon of water everyday, and that without measuring how much water he consumed, at the end of the day he's not sure if he hit his goal or not. I was intrigued, and decided to see how much water I drank everyday, even though I had no intention of matching his consumption.

I bought a 1 liter bottle of water, and set to drink 3 liters of water a day, as the Mayo Clinic recommends. To my surprise I discovered that I am no where near the recommended quantity, even after factoring in the incidental drinks I consume everyday--coffee and soda.

It was an eye opener for me, and as the management adage says: "you can't manage what you don't measure", you can't improve what you don't measure. Armed with a simple and easy tool to see the amount of water I drink everyday, it became a game to improve on it, and you could not beat the simple feedback.

There is something to be said about simple tools.