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 www.iiba.com . 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 http://businessanalysis56.blogspot.com/2005/07/welcome-to-business-analysis.html and then work your way forward. I have recently learned about a website/service called squarepusher.com that may be useful in turning these blog entries into a standard website, so I will keep you all informed on my progress there...)