More from Karl Weigers

Karl Weigers, the author several books and articles on software requirements, has written another article found via a link on Dr. Dobbs.

It's more good advice, but as one of the commenters noted, it's advice that Weigers and others have been espousing for years, and I don't know about the dedicated software shops, but I know most IT shops are still missing the mark.

It's also interesting to note that Weigers talks about getting as much as you can right from the start, and of course it didn't take long for an agilist or two to point a finger and yell, "Waterfall!". Weigers tries to tell those posters that he didn't say "all the requirements have to be up front" but that there needs to be a solid foundation before people start hacking out code. But I don't think he needs to apologize for anything he said. Even Joel Spolsky has said he's been successful with BDUF.

Of course both sides have a point; it is also not wrong to prototype quickly (although in impatient organizations there is the danger developers will be told, "Oh, that looks good, put that prototype into production.") But how much of the requirements should be done up front? I think the severity of the cost of failure should have a play in how much needs to be done up front; if you're building the Saturn V rocket program for the Apollo space mission, or the F-15E Strike Eagle program, or medical systems software, damn it, you'd better have your ducks in a row up front or it's going to mean lost lives.

If you're a one-person team making a fairly simple card game as freeware on your own time, well, by all means, start hacking.

Somewhere in between those extreme examples are these silly things called multi-billion dollar companies that use software for everything from accounting to operations to customer service. I could be a real joker and say that perhaps it's good for the economy that so many corporate systems are broken and need lots of people to support them. But if you're one of the people stuck supporting broken systems, you might not find it funny as you spin your wheels trying to read arcane and undocumented hieroglyphics and wishing that you could be working instead on a new feature that would open up new options for the sales department.

Bad software is usually a result of poor requirements and it does cost companies more than they realize. But for a lot of them, the cost of failure is more payroll in maintenance and customer service...they're loath to pay it but some consider it just another cost of doing business. And if they're willing to pay it, then accept it, keep plugging, and refactor where you can.

Break Time

I just finished Susan Sontag's The Volcano Lover. It's an interesting book based on the lives of Sir William Hamilton, his wife Emma, and British naval hero Horatio Nelson. Sontag deftly blends the fictional with historical and does it with sumptuous prose. Sontag's life has been marked with some controversy and I don't agree with all her comments, especially those regarding 911, but I find her to be a brilliant writer and thinker. The book is peppered with interesting observations about life, and in taking a little break from work I'll capture some quotes here.

"...the news is always a little unreal, which is why we can stand to bear so much of it."

"A man who has to admire in order to desire is likely to have led a modest sexual life."

"You can look at the most apalling things in art. Whatever art shows, it is not going to get any worse. The knives are out...but his tormentors haven't started yet...to cut. Not even one tiny morsel of flesh. His monstrous punishment is forever only seconds away."

I'd read Sontag said "True art has the capacity to make us nervous." In the book, there is a passage that says the same thing in different words. I don't know if the quote is actually from the book and paraphrased, or if this is just Sontag saying it later in a different way, but it's a concept I've always found fascinating:

"We admire, in the name of truthfulness, an art that exhibits the maximum amount of trauma, violence, physical indignity. (The question is: Do we feel it?) For us, the significant moment is the one that disturbs us most."

"Acting is one thing, being civilized (which includes acting) is another."

"Nothing is more admirable than mercy."

Two More Examples of Business Analysis

I have two new Business Analysis stories to share. The first is a common pattern in recognizing that your business analysis approach is lacking. The second is a success story where I applied a lesson I learned from a previous BA class. Both are based on true stories though the names have been withheld to protect the author from frivolous lawsuits.

How did we miss that?
After a feature in a software application goes live, a support issue comes up and the development team lead and one of the developers are discussing it. The issue is one of functional deficiency; the feature works but is not accounting for some lower percentage edge cases. This deficiency is now costing the company more money than it realizes:

• The user raising the issue is unable to depend on the system to complete work
• The development team lead and the developer are both expensive resources now having to spend time fixing something rather than moving on to a newer and perhaps more strategically valuable enhancement.
• The infrastructure team has to add this to the list of items in the next scheduled release.
• The costs of having dealt with this in the software development phase would have been less expensive than it is now. Now, it incurs the additional costs of regression testing, additional documentation, redundant testing and more.

The team lead mutters out loud, "That's a missed gap. How did we miss that?" If this is happening regularly in your shop, it's a good bet your BAs could use a little more training and need to understand the value an analyst's effort provides. Even if you did not have time to develop for all the feature's edge cases, by paying some attention to them, you could have at least had a contingency plan in place (manual work around, system work around, alternative business process) to deal with the issue. Instead you now have to throw it over the wall to IT, where enough of these types of issues will cost you more than you spent on that project manager who got it done on time and on budget, but not necessarily on target.

Challenge the User (and the importance of understanding the domain)
Here's a more positive story. In my BA class in 2008, I noted that I loved one key line in particular: "BAs are not order takers." That statement proved valuable in a development effort I witnessed.

The request being addressed is to automate a process that users must manually perform. Ok, sounds good, that's always something IT is good for. But the analyst on the case originally performed as an order taker. Word for word, the user's request was put into a requirements specification. Now, that's already a far sight better than situations when the developers are given a single verbal sentence for a requirements document.

But the original request in this case says the automated process should not run on weekends, and should a scheduled day fall on a weekend, the process should know to run on the next business day instead. That's a request that is a perfect example of something that seems obvious to humans but can be tricky for computers: understanding when to delay the scheduled process adds complexity. The routine must now take into account what defines a business day, what defines a weekend, and whose calendar is defining holidays. Moreover, you cannot simply ask the routine to run on Monday if the regularly scheduled time lands on a Saturday because what if Monday is a holiday? The logic has to know how to handle various date collisions.

Our story has a happy ending, however, because the analyst involved in the requirements definition looked more closely at the user's needs and realised that the date concerns would have no effect on the routine. The requirement that the process run only on business days was not a meaningful business requirement at all, but a process quirk of the way humans did things. In actuality, there was no new business data being generated on the weekends or holidays, so asking the computer to run the process on the set day versus the next business day would not make a difference; you would get the same data regardless.

The analyst conferred with the user and was able to eliminate the date logic, which simplified the routine and the requirements. Cost savings: fewer database tables, simpler logic and fewer lines of code to read and maintain.

Question everything!