Story Analytics

Blogathon Workspace, 10 AM

“The system may be working according to design, but the design isn’t according to the requirements,” read the email from a business stakeholder in a project that I was working on a few years ago. It was my first foray into what would be “business analysis”. I had some Visual Basic programming experience in my belt at that time, and was moving to Java and Smalltalk programming.

There was no concept of a business analyst then. We were programmers and we worked with the “business”. Those were the good old days. Business stakeholders would say what they want. Programmers would then start coding furiously. Product delivered. Occasionally there was the project manager, usually a hindrance, but kept us programmers in check.

And then the business analysts and business systems analysts had to come and ruin everything. A friend recently remarked, “They do everything, and yet, do nothing”.

Anyway, given that most projects fail due to bad or poorly captured requirements, clearly understanding and writing requirements now assumes paramount importance. So does adherence to processes.

The importance of writing good requirements has been recognized and standards set by none other than NASA. They’ve had a few share of their failures, but I hope it wasn’t due to bad requirements! Anyway, NASA has now come up with the ARM (Automated Requirements Measurement) tool that checks the correctness and validity of requirements.

However, while it does check that the requirements are written right (for semantics, proper use of unambiguous keywords etc), it doesn’t, and cannot check that the right requirements are written. That onus is solely the responsibility of the requirements analyst.

As I dwell into my CBAP preparation in the third series, I’ll go over the types of requirements as per IIBA standards.