RE: BDD and Requirements Traceability – Oh No, Not Again

This is a response to Scott Bellware’s recent post on “BDD and Requirements Traceability – Oh No, Not Again”

It is true that we are inevitably doomed to repeat our past mistakes if subsequent generations are unaware of the travails of its previous generation, and requirements traceability is one form of Gen -1 travail that that I hope doesn’t get accidentally revived by this generation’s league of speculative scientists.

Seeing that I am one of the principle contributors to NBehave, I love that I can now dawn a lab coat and refer to myself as a “Speculative Scientist”. I say that tongue and cheek of course but my profoundness in my assertions of traceable requirements are in part based on my experience with (twitching in my seat) Rational Rose in the 90’s!

I am one of the idiots that were forced to use this monolithic monstrosity from hell to draft requirements (getting shortness of breath), UML documents and code that magically map to each other. Forget that it took a systems administrator 4 hours to lock on unlock requirements. Forget that when you reverse engineered the code back into the model that it broke the last 6 hours of modeling that had occurred. Forget that towards the end of the project you ended up decoupling the (coughing) traceability and said “$@&% it, let’s just code and get this darn thing done!” As you can tell I am little bitter about the whole experience.

I will say this. My entire professional career has been brought up in Government and Enterprise level development. I have had to deal with more regulatory flack over the last 14 years then I would care to talk about, yet here I am still in the hot seat. You might ask, “Why are you still there if you can’t stand it?” The short answer is

“Because I believe that despite regulatory or bureaucratic issues that arise in these arenas, I know software can be done right!”

This is why I am firmly committed to evangelizing pragmatic approaches to developing software at the enterprise level.

I don’t think just because we have failed in the past means that we shouldn’t revisit the present and learn from those mistakes.

>I never want to go back to a context where traceability is seen by my organization as a reasonable course of action.

Neither do I which I why I am creating policy to insure that this does not happen. I know that in the past organizations have been tainted by the proverbial blame game that occurs through traceability.

In dealing with Financial Enterprise systems it is imperative that business decisions are traced through code because of security and regulatory related issues of changing pricing or loan payment amount algorithms. These have serious implications if policy and procedures are not followed (take for instance the plot of Office Space.) So we have two opposing mindsets. Produce tons of documentation to track these changes? Or Find a way to make the process light weight and uninvasive.

I want to go on the record that NBehave was never intended to solve traceability issues. I simply saw this tool as well, just that, a tool that can help me the corporate AVP, deal with traceability issues in the most simplistic way possible.

Traceability in financial enterprise systems is seen as a comfort indicator from an executive board level of insuring that business requirements have been followed and nothing has been injected that falls outside the boundary of essential, needed or exposure. They can safely go to our shareholders and check off one out of the 50 oversight constraints that it takes to deliver software to production.

I want to caution people that are reading this entry that if you are not in an enterprise level arena or for that matter if you are. You should still exercise the most simplistic means of developing software. By that I mean start off with index cards if they work for you use them. If they don’t evaluate your process, see if you need greater understanding or a new tool.

>We don’t use stories as a way to talk about why some feature didn’t turn out the way a customer expected.

I agree. Why a story didn’t turn out a certain way is usually the result of not understanding the acceptance criteria. I am simply proposing, rather than creating a whole new story card, simply go back to the story and revise it with the customers till it meets their expectations. It is not a contract it is simply a reference point for communication.

I also find that RallyDev, VersionOne and Target Process have all built models around Agile Project Management where the focus is about documenting the story in an electronic medium that can be tracked. In an enterprise environment these tools are essential in communicating with distributed teams on projects.

> This aspect of confrontational team process is part of what traceability is often concerned with.

Traceability can be used in this manner but for that matter anything can. I have witnessed several times where developers, analyst etc. argued with the product owners, story card in hand over implicit behavior that wasn’t meeting their expectations. The standard argument is that the story didn’t have any of those details. I am not saying that their behavior was in line with embracing change but people are people. So no this is not what I am intending traceability to solve. That aspect is all about managing people.

> Traceability is theoretically also concerned with compliance and auditing, but in practice, traceability between user stories and code rarely serves compliance and auditing concerns to a greater extent than it hampers the primary customers of stories – the cross-functional team building the software application.

Possibly but I have not read any empirical evidence to support either side of the issue.

> Payments to the bureaucratic ferryman should be made outside of the project’s main line of operational efficiency.

I’m not saying that we should avoid bureaucratic and regulatory pressures. I’m saying that we are called to find the right layer within which to encapsulate those kinds of processes. The team needs to be aware of regulatory issues, but they need to be supported through workflows other than those whose aims see to the satisfactory accountability to customer requirements for features and functionality – even features and functionality that directly serve compliance concerns.

I couldn’t agree with you more. In fact I feel it is absolutely impossible to practice Agile in the enterprise environment unless you do just that. I call this the Agile Project Management Façade layer. This layers acts as an anti corruption layer between traditional oversight and Agile processes. The difficult part is that concerning traceability or Software Engineering Development oversight, the façade layer sometimes leaks! I am sure I could find a way to somehow satisfy the traceability issues at this layer and have it not affect the development team but I am afraid it will come at a cost of man power or increased bureaucracy.

UPDATE: Apparently I am not the only person calling this a managment facade layer. D. P. Bullington uses this term as well.

I am not about to disturb the atmosphere in the lab or the department for that matter at the expense of an idea or tool. If the tool (NBehave) proves to be a failure I will know early on since we practice one week iterations. So the loss will be marginal at best.

It is important to point out that I have not implemented NBehave in my organization (yet). I don’t think it is there yet. It solves certain issues but it creates new ones. I have proved that it can work with certain individual but I agree with Scott that we shouldn’t expect a product owner to learn how to code. That is why I am really excited about Jeremy Millers proposal to integrate Story Teller with NBehave. I believe it we can come up with an external DSL that compliments Story cards and acceptance testing that this will be of enormous value to the community at large.

I want everyone to understand that this debate only deals with Automated Requirements and Tracebility. It does not have any bearing on BDD. Think of this issue as a distant cousin to BDD.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Joe Ocampo

My personal philosophy is simple: "Have a good strategy that sets the environment for success through the enablement of the whole. Be agile but with a mind towards pragmatism. Delegate to the best qualified individuals, but don’t be afraid to involve yourself in all parts of a job. Treat everyone with respect, humility, and with a genuine pursuit towards excellence." Respected business and technical leader with expertise in directing organization towards effective results driven outcomes. Proven ability to perform and communicate from both technical and business perspectives. Strong technical and business acumen developed through experience, education and training. Provides the ability to utilize technology, harness business intelligence and execute strategically by optimizing systems, tools and process. Passionate about building people, companies and software by containing cost, maximizing operational throughput and capitalize on revenue. Looks to leverage the strengths of individuals and grow the organization to their maximum potential by harnessing the power of their collective whole and deliver results. Co-Founder of LosTechies.com
This entry was posted in Agile Project Coaching & Management, BDD (Behavior Driven Development), Tools. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

5 Responses to RE: BDD and Requirements Traceability – Oh No, Not Again

  1. Ultimately, we’re able to prove requirements compliance through the acceptance criteria and the meaningful transformation of those criteria into artifacts that can be surfaced in specs.

    When we start believing that the user stories themselves have a role in compliance and traceability, we’re in that place where programmers-gone-wild videos start playing in the background.

    I wish I had example driven development tools on projects that had regulatory oversight. I’d have stayed away from putting stories in programmer artifacts though, since the acceptance tests aren’t concerned with the stories as much as they are concerned with the software that follows.

  2. Joe Ocampo says:

    If the user stories themselves do not play a role in compliance and tracebility then what Agile artifact does in your oppinion?

  3. Acceptance criteria and the specifications that implement them – sans story text.

  4. Colin Jack says:

    This may not be the right thread for this but I have a quick question about BDD.

    One thing I’m noticing is that BDD is being used to mean several different things, and mocking is one part of this. For example my reading on BDD has left me confused whether its best suited to interaction style or state based style testing of the domain layer. Martin Fowler indicates his understanding is:

    “An important offshoot of the mockist style is that of Behavior Driven Development (BDD). BDD was originally developed by my colleague Dan North as a technique to better help people learn Test Driven Development by focusing on how TDD operates as a design technique. This led to renaming tests as behaviors to better explore where TDD helps with thinking about what an object needs to do. BDD takes a mockist approach, but it expands on this, both with its naming styles, and with its desire to integrate analysis within its technique. I won’t go into this more here, as the only relevance to this article is that BDD is another variation on TDD that tends to use mockist testing. I’ll leave it to you to follow the link for more information.”

    So whats the answer, is this really what BDD is all about?

  5. udtltnco says:

    zKTtbR yqayieevpbcn, [url=http://rfpgksmyrasf.com/]rfpgksmyrasf[/url], [link=http://vsijxkzqoclm.com/]vsijxkzqoclm[/link], http://darkfbqfsnwg.com/