TDD and Meaningful Requirements

Both Craig Brown and Richard Puttick were kind enough to comment on my previous post about meaningful requirements. The post is an extension of a conversation I was a part of with Robert Martin several years ago about Test-Driven Development. The group quickly concluded that unit tests were essentially executable specifications, provided that things like boundary conditions, known negatives, etc. were also fully tested. By extension, user acceptance testing (UAT) were effectively executable requirements, provided that they were tested with the same comprehensiveness as unit tests should be conducted.

Going just one step further, it should be pretty clear that in UAT, not only can the functional expectations be specified in terms of tests and measured against the results, the operational expectations can also be specified in terms of tests and measured against results. These functional and operational expectations are nothing more than functional and technical requirements, both of which can be tested at the same time. This also leads to practice of combining functional and technical requirements into the same statement, which also aids traceability.

We have needlessly complicated our lives and increased opportunities for defect injection by separating functional and technical requirements. A demonstrated good practice, TDD, clearly illustrates how the separation of functional and technical requirements are not only a worst practice, it's not necessary at all.

Enterprise Architecture Maturity Models

There must be some kind of thread about maturity models crossing the LCD panels of enterprise architects this week. I was again asked for an EA maturity model. I reflexively reached for a couple of the already published maturity models, stopped myself, and asked the question, "EA the noun or EA the verb?"

Apparently, the customer would like an assessment of the maturity of their enterprise architecture, the noun.

This is actually more of a challenge since almost all of the maturity models out there are process-oriented, not product oriented. CMMi is a perfect example. CMMi is product and quality agnostic. GIGO. It's completely possible to build CMMi Level 5 compliant lead-lined lifejackets. The same goes for just about any other process-based maturity model. Not very helpful when the only thing that really counts is the quality of the results, a fact most process weenies seem to forget (or overlook because that's really hard work). Of course, almost all of the EA maturity models (NASICO, Open Group, EAMMF, etc.) are either direct adaptations of CMMi or embed a lot of CMMi in them.

I was pleasantly surprised to find the E2AMM. It didn't surprise me that it's out of Europe at all. The Europeans are so far ahead of the Americas (both continents) in terms of EA it's almost embarassing. No, it is embarassing. Anyhow, I'm going to take a close look at this model to see if it is applicable to this particular customer's needs. I'll post my observations here, later.

SOA Governance and Vendors

We have seen a bit more consolidation in the SOA components arena again, with Iona and BEA getting swallowed up. I didn't use the term "products" because as we all know, it's not possible to go out and buy a SOA, in spite of all the vendors would have you believe and many corporations and agencies hope for so they can spend year-end cash.

Of course, the same goes for SOA governance, which can't be bought, which Michael Stamback reminds us of. Well, he reminds us of that in his first tip. As for the other 4, let's just see ...

Tip #2: Look for a vendor that can explain how their technology is applied

Ah, and I had such high hopes. At least he could have waited until the 4th or 5th tip to steamroll his own advice. He must be pretty new at this schtick.

Tip #3: Beware of the kitchen sink!

This is great advice from a vendor who just loves to sell the kitchen sink. They re-sell Systinet's (wait, Mercury's .. wait, HP's) product last time I looked. You will probably be better off talking to HP directly and get the story from the horse's mouth. Then again, in terms of SOA components, they now have 2 kitchen sinks to sell, though the home-grown one really never worked and BEA never had any SOA components related to governance.

Tip #4: Start small and expand

Can't argue with that one. Governance tools beyond a whiteboard, post-its and a spreadsheet aren't necessary until you have about a dozen services and at least one is composite. Until then, there's really no SOA; barely a collection of services, really. Then again, who's to argue with someone willing to throw money away?

Tip #5: Look for an integrated solution

Ah, I just love this one. Even back when I participated in an evaluation of all the various governance "solutions" out there, only 2 vendors had an integrated stack (Amberpoint and SOA Software) and only one had a comprehensive run-time offering (SOA Software). I don't see how the landscape has changed, at all. The others may claim to have an "integrated" offering. Well, if a colloid is considered integrated, that's fine.

Of course, none of these folks go down deeper into the stack and deal with how to create, manage and enforce governance policies for the rest of the SOA stack outside of the service, like the service container itself! Then again, that's a really hard problem to solve and of course, you can't sell what you don't have a solution for, right?

Meaningful Requirements

I simply have to comment on James McGovern's latest post on requirements where he says:

When will we acknowledge that implementation are little decisions made all over and that requirements documentation only decide certain aspects?

This is the result of failing to realize that "technical requirements" cannot be made separate from functional requirements since a function includes the notion of acceptable/predictable behavior. This is where the analysts can borrow a technique from developers: Test-Driven Development (TDD). For lack of a better term, let's call it Test-Driven Analysis.

What would TDA include? It would include a description of the function plus sample inputs, outputs and expected results, including expected failures (samples of say, SQL injection attack code that must be rejected). Moreover, this wouldn't just be data-focused. Other properties such as the range of acceptable response times, expected feedback, etc. need to be determined. Now we have embedded those "technical requirements" directly into the functional requirements plus have added measurable quality attributes that further serve as acceptance tests/criteria.

It's not like this can't be done, it's just a lot of hard work.