Wednesday, January 25, 2006

Information System Requirements still matter...

If you are familiar with newer Agile or Extreme methods for developing software, you will know that they disdain formal requirements, preferring to work directly with end-users to deliver software in small increments. I believe that these methods are a natural reaction to software developers’ long-standing frustrations with receiving poor, incorrect or no Requirements to work with. Developers should be focused on creating software, and time they spend trying to find out what they should develop, or developing the wrong software, is a waste of their valuable time.

Why do Developers get poor Requirements? There is often no common discipline or accepted practices being used when creating Requirements in a software development project; but, if Developers do get good Requirements, the resulting software is better is almost every way, primarily that it will meet the needs of the business that requested and paid for it.

As a discipline, Project Management faced similar problems in the past, but today its practitioners all recognize common approaches and techniques: Work Breakdown Structures, Gant Charts, Pert Charts, Critical Path Analysis, and more. They also have seen their work coalescing as a profession through the PMI and its PMP certification. Project Managers also started with the advantage that their job title actually describes what they do – Project Managers manage projects. Software Developers have the same advantages, although the wide variety of languages and environments mean no single certification can be had.

There is no similar structured discipline or professional recognition around Requirements today; but I submit that it will exist in the future, for two main reasons:
…1) the need has been recognized by a growing number of Requirements ‘practitioners’, who have founded an association similar in mandate and purpose to that of the PMI for PM… more on that later.
… 2) It has been demonstrated in the past the Requirements can be documented using modeling methods with enough rigor that software can be automatically generated from the Requirements. Yes, the main CASE tools of 10 to 15 years ago failed to catch on, but not because they did not work. I see this level of rigor and code generation surfacing again with Model-Driven Architecture.

Granted, I am in no position to say that model-based Requirements and code generation are going to reduce or eliminate creation of software by programmers. I could however draw on the common justification for any automation that is used so often; that it won’t eliminate people’s work or jobs, but free them up to work on more challenging tasks .

So, I think Model Driven Architecture will play an increasing role over time; in the mean-time, if it shows that methods for producing requirements can be rigorous enough (good enough) to generate code, then why not use such methods to document Requirements for developers to use for the rest of software development?

But where to begin?

An ancient Chinese saying tells us that ‘All wisdom begins with calling things by their right names.’ So, the job of gathering and documenting Requirements needs a Name… I am being somewhat disingenuous here, as there is well-known job name already, but it is not always used the same way; I am talking about the “Business Analyst”. It is not bad title, and it is one I have had off and on since 1984, and it does describe what we do --- analyze the business --- but not what we create: the Requirements.

I think this is part of the reason that, when some companies hire a Business Analyst, they believe they are also getting a Project Manager and Software Tester (the latter better known as Quality Assurance Analysts). I have also met Business Analysts who would agree with this. I would certainly agree that having multiple skills will make you more marketable, but it should be clear that these are three separate skill-sets that are not always compatible.

I myself have and will manage small to middle-sized projects, but primarily when I have first completed the Requirements myself; if you need more than one Business Analyst to get the Requirements delivered, you need a separate Project Manager. I do recognize that many Business Analysts have worked hard to acquire Project Management skills and experience to then become a certified PMP, but it is often because there has been no equivalent certification for Business Analysts; again, more on that later.

I have also had a successful career as Business Analyst without testing software; I see that as a very specific discipline for which I have great respect, but no inclination to perform. It’s possible or probable that I have no talent for it either.

Another issue I have with the misuse of the Business Analyst title are those companies who advertise for a ‘Business Analyst’ with specific software product experience, such as Oracle Financials or SAP (even a specific SAP module). I think what these companies are looking for are ‘Application Analysts’. This again is a separate skill-set, and a popular one, but these analysts still need to have the Requirements of the business provided to them, and I believe ‘real’ Business Analysts are probably doing that first.

The last question about the Business Analyst job is the importance of specific business knowledge and experience, aside from analytical and requirements-related skills. Again, companies will ask for Business Analysis with experience in Supply Chain Logistics or Life Insurance or Express Delivery or Human Resources or Commercial Credit or Finance/Accounting. Well, I have worked in all of these business ‘domains’ and more without needing to change how I do my job. In the end, the business people being served by Information Systems – executives/sponsors, managers, end-users --- are the ones who need to know their business; what I need to do is be able to quickly understand their business in order to gather and document their Information Systems Requirements.

Finally, you may ask how technical a Business Analyst needs to be. My basic recommendation is you need to understand what technology can do in order to deliver the solutions that meet the Requirements, but you don’t need to know how the technology will do it. I started as a PL1 and IMS programmer before moving to Business Analysis; since then, I have done Requirements for systems implemented on mainframes, minis and PCs, using environments from TSO to OS2 to Windows to Browsers; again, the technology to be used to did not really change how I did my job; in fact, the best Requirements are those that can be implemented in multiple technical environments.

And about certification for Business Analysts, we can now look to the International Institute of Business Analysis, at . It is being created and developed following the appropriate ISO standard for professional certification organizations and, much like the PMI, is developing a Body of Knowledge for Business Analysis and certification/testing based on that BOK. If you consider yourself a Business Analyst, it is imperative you seek out the IIBA, and highly recommended that you join.

So, Business Analysts deliver Information Systems Requirements; if you navigate back through this blog, you will see how it is done. (It is the accepted Blog format for entries to be LIFO, so I would recommendyou can make your way back to my first entry and then work your way forward. I have recently learned about a website/service called that may be useful in turning these blog entries into a standard website, so I will keep you all informed on my progress there...)


Anonymous said...

Just hit upon this blog, and the first impression I get is that this will be of immense use to me and other "aspiring" BAs -:).

Thanks a lot for starting this blog, and I am looking forward for lots and lots of learning from this blog.

Fidel Khan

Mike Wilson said...

Good thoughts.
Perhaps with your permission I might share an excerpt or two with a users group in the Jacksonville area during a group discussion?
Mike Wilson

David Wright said...

To Mike Wilson:

I suppose that would be fine... what is the User Group you referred t?

Mike Wilson said...

it's a forming group or chapter of the IIBA in Jax. Our discussion groups are just starting off too.

David Wright said...

Mike, yes, the IIBA. I am a member but not a spokesman, of course. I know there are fellow members who would disagree with me about project managing and testing, who say it is part of the job and why wouldn't it be. I just agree to disagree....
By the by, I was at the Business Rules Conference in Orlando back in November, and met up with another attendee or two who mentioned the Jax chapter was starting up; were you at that conference?

Mike Wilson said...

no sir I missed the conf. I am brand new to the group and this month was the first meeting I attended. I'm excited about the possibilities and trying to get plugged in as best I can. The folks leading the group seem to be very knowledgable and interested in the greater good of the group. So refreshing to see that. I come from a company that is riddled with corporatitis and me-firstism.

Corporate Finance said...

Are you a financial ratios analysis enthusiast? If so here is a fantastic resource for everything related to things about financial ratios analysis with information, products, articles and more..Check it out

H.M. Winning said...

Good blog - I've been fumbling around with systems - business analyst definition myself. I joined the IIBA and while I think it's a great thing I'm still seeing a need for more business centric approaches and language in requirements gathering and production. More so than that - helping other BAs understand how to apply all of the wonderful tools and methodologies on their specific project.

David Wright said...


There is a book I am just about to start that speaks specifically to business analysis and language:

Business Systems Analysis with Ontologies by Peter Green and Michael Rosemann (eds) Idea Group Publishing © 2005

It looks somewhat academic, and the whole concept of 'ontologies' is, well, pretty conceptual even for me.

I am also working my way through another book which speaks to analysis and modelling:

Business Process Implementation for IT Professionals by Robert B. Walford Artech House © 1999

The title is a little misleading, it's not about BPM, but worth checking out.

David Wright said...

The two books I mentioned in my previous comment turned out to be a disappointment, especially given my hope that Ontology as a discipline might provide a framework for Business Language... but that was hoping for too much.

About Me

Ontario, Canada
I have been an IT Business Analyst for 25 years, so I must have learned something. Also been on a lot of projects, which I have distilled into the book "Cascade": follow the link to the right to see more.