The Art of Requirements Writing

The one area where I see companies could improve and make a HUGE impact on their development is in Requirements Writing. Most companies err on the side of too little or, unfortunately, way to often, none.

The biggest problem we see as a result of insufficient requirements is almost always scope creep, meaning that because there is no baseline, features just keep getting added to a release, and the result often is that the release never gets released. The other common problem we see from non-existent or insufficient requirements is that what gets implemented is often not what was intended, and if by chance the implementation is done correctly, it has taken a lot more work, time, and interaction than it would have otherwise.

The other side of the coin is perhaps more interesting. It’s rare, but sometimes we see companies that put too much in their requirements. I think this fear is why some companies don’t do anything at all – they don’t want to spend eons writing reams of paper and analyzing every detail. Rightly so, it’s a waste of time. The kinds of things we see in this area fall into two main categories of content and formatting.

As far as content, the biggest error is trying to turn a Requirements spec into a Design spec, meaning that instead of detailing what needs to be done, the requirement details how it should be done. Now there is a place for this, but it’s not in requirements. Specifying the how in requirements really limits the options and almost always results in a sub-optimal design. If the requirements are being written by a business analyst, as good as they are, they are not usually experienced architects or developers. Even if they are being written by a developer, the benefit to separating what from how allows the developer to look at all the requirements as a whole and in a separate thought step design the how in the best way taking everything into account, not just one requirement.

As far as format, the least useful way to write requirements (and ironically, probably the most difficult way) is in paragraph or prose form. There’s just too much content, and the important points are not easily identified and digested. Additionally, it takes an additional step for every user of the requirements (development, QA, Tech writing) to get the relevant information out. Obviously Use Cases are a tried and true and very effective method, but even bullet points (as long as they contain enough information) are preferable. The information contained should include the user entries, the results, any exception or error conditions and any other affects of the feature, easily and quickly captured in a bullet point format without any extra text to wade through.

Bottom line – well written requirements are HUGELY helpful to everyone in the development process and will make a great impact on getting your product out quickly. I’m sure there are offenses I’ve missed here. What other kinds of things have people seen??

What it Takes to be a Successful Consultant

I have not written for a while on what it takes to be a successful consultant, but lately I’ve been noticing some common trends with our best people, and oddly enough it has absolutely nothing to do with their technical abilities. I’m really not sure what to call it – grace, poise, or just plain old fashioned professionalism.

In one instance, one of our clients handled an HR problem, let’s just say, in a less than optimal fashion. Our consultants there were affected by this decision, and one of them could have been justified to be hurt or angry, but to his credit, he just continued to do his job while the storm raged around him. He happened to be in our office one day while this was going on and his comment to me was “I have a job to do, and I’m going to focus on that and do my best.” Love that!!

In the second instance one of our consultants was working with an engineer at our client’s client on an integration project. I’ll spare you the gory details but this engineer was engaging in programming practices that would make any professional programmer shudder with disgust. The stories even made me shudder and I haven’t been a programmer in ages! To his credit, our guy worked thru the issues with this engineer without issue.

Although they’re all sharp, in fact some of the smartest people I know, I think I admire the restraint, respect and professionalism our consultants exhibit even more than their technical chops. We serve at the request of our clients, and being difficult or disrespectful does nothing for our relationships. I’m so proud to be a part of this team, with these amazing engineers and developers!

Girl Power! Encouraging News on Girls in Tech

I’ve written a lot on the alarming lack of interest of girls (and boys) in technology careers. This week I read some encouraging news I wanted to share.

Google’s inaugural science fair was held on Monday and the three winners were all girls! Google reviewed more than 7,500 entries to bring the 15 top applicants to Google headquarters for final judging. These 15 were interviewed by luminaries in technology, including a Nobel Laureate, National Geographic Explorers, and some of Google’s best and brightest.

As we know, there is no shortage of younger girls interested in math and science, but for some reason that drops off in middle school, yet these girls were all teenagers. Let’s hope their interest continues. We need smart people like this in technology!

Making the same mistakes

I hear it over and over again from technology execs – I know we should spend the time writing specs or working on our process or on architecture or designing a good UI or testing or documenting or - fill in the blank.

Yet, time and time again, I see companies making the same mistakes. It kills me! I asked myself “why do they do it?” After all, it’s so easy to improve your delivery time and quality a little bit at a time. I know it’s hard to find a place to start, but for some companies I see, anything would help them. When in doubt, remember that good requirements make everything else easier!

Then I remembered something I’ve heard repeatedly “The pain of the change must be less than the pain of the status quo”. I get that change is tough, but some of these changes (i.e. good requirements definition) are not that painful. I think a more accurate assessment would be “The fear of the unknown must be less than the pain of the status quo”

Do any of you have less than optimal practices in your product development? We all do, in one way or another. Things can always be better. Why do you stay where you are?

Innovation - Simple Is Best

As I recover from minor foot surgery I discovered an important fact. The use of crutches is exhausting. The only thing required of me to heal properly was not to put any weight on the foot. Sounds easy but after a few days I found the use of crutches to be limiting and exhausting. Facing six to eight weeks on crutches I began looking for alternatives.

A friend of mine recommended a Knee Walker. At first the scooter, as I prefer to call it, did seem laughable. But when I tried one I could see how such a simple device could be so helpful. After using one for the past 6 weeks I am a huge fan.

So what did I learn from this experience? Some of the most innovative products are the simplest. Entrepreneurs, inventors and engineers thinking of the next great breakthrough product need to ask themselves two simple questions.

What problem am I trying to solve?
What is the simplest way to solve it?

That is a good start for any new endeavor.

Driving Students to Tech Careers

I recently read an interesting interview with three senior executives at Google. The article was about women in technology, but one of their points intrigued me. They hypothesized that the prevalence of technology in our lives (smart phones, Facebook, etc.) will drive more young people to technology careers. They will use it and some will be curious about how you create a smart phone or an application like Facebook.

This sounds likely to me. Recently, I was speaking to a group of girls and shared that I had no idea what Engineering was when I went into college. All I knew was that it used math and science and I could get a good job when I was done. That was enough for me at the time. Fortunately, I enjoyed the intellectual challenge of solving problems and the satisfaction of creating something from scratch.

Now a days, when I describe what Advanced Decisions does, I have plenty of commonly known examples to point to. My typical “definition” of embedded systems programming is “writing software for an electronic device like your phone or your car, or your microwave, or medical equipment.” People usually understand that.

Do you think the prevalence of technology in our lives will generate interest in careers in tech? If not that, then what might? One of the points the women made in this article was that it’s not really about just women in tech. We have a shortage of programmers and engineers and need more regardless of gender.

Girls in Technology

A few weeks ago I spoke at Housatonic Community College’s Girls in Tech program. See this article in the CT Post for more.

Kudos to HCC for putting this on. It’s such an important issue. These were 7th and 8th grade girls, mostly from Bridgeport that had the opportunity to attend the expo and learn more about what kinds of careers are possible with a good solid STEM education. The possibilities excited them, and fortunately, this is the time to do something about it.

At this stage in their schooling they still have the opportunity to take advanced math and science classes and get the grades required to get into top schools and get scholarship money. This is the age where girls lose interest in math and science, but seeing what they can do with a strong STEM education, many of the girls were inspired.

Choices like nanotechnology and crime scene investigation are not obvious, but really inspired the girls. Many of them said they would devote themselves to their studies, with the goal of entering one of the intellectually stimulating and high paying careers presented at the Expo. I’d call that a success!