Requirements

Martin Fowler has recently blogged on what he called observed requirement emphasizing the idea of web sites' users behavior observation as a powerful but yet not widely used driver of identifying and testing requirements. This post triggered two parallel thoughts in my head that I figured might be worth writing about.

#1: WebTrends and alike
#2: Different engagements warrant different approaches

#1. WebTrends and alike

The testing and observing part is not really new. "WebTrends and alike" is usually my first thought when I hear my customers want to analyze how their users behave on their web sites. The tool seems to be out there for about 15 years and for a good 2/3 of its lifetime we've been doing WebTrends-ready applications. What the companies then usually did with this was often limited to reporting. They would report on how did users behave, where did they drop off of the site, and what content was the most often requested/viewed. Sometimes they were even interested to see the most common user paths thru the site as they thought it might help building the right advertisement strategy. I recall one company did in fact want to include WebTrends(-like) support in order to test their original set of features and see if they could figure the best way to enhance their product thru their customers' footprints on their website. I can't tell if the "enhance" part ever happened (and my guess is it did not), but they had been working on content that they thought was "good" but apparently not proven to be so by the actual visits statistic.

I don't think there's an Approach to how to convert users' behavior into the site's feature-driver. It's just you can't see what's not there so you can't build a step-by-step guideline. The advice may be easier to give: leverage the instrument, especially if you are a company running your business on the web and competing in the SaaS market. Approach should be tangible, Advice may not be :)

#2. Different engagements warrant different approaches

Another thought that Martin Fowler's post triggered is not related to analytics. It's related to the intro quote Martin used to open his post. Martin quoted a "waterfalish" approach to requirements management and challenged it with the agile approach that is "...intending to discover the 'requirements' during construction and after delivery".

During last few years we as a company get more and more exposed to agile methods, agile projects, and customers who want to go agile (sounds close to the "go green" buzz). This whole concept of doing things agile and following agile principles in software engineering and software projects management is Great but is also often misinterpreted and misunderstood. The concept of "working software over comprehensive documentation" often gets translated into "agile means zero documentation". Does it? working software comes first. Yes! but who said zero documentation? The concept of "responding to change over following a plan" often gets translated to "we don't need requirements and we don't need to plan". Do we not? isn't sprint backlog a plan?

Different engagements warrant different approaches. One of the ideal environments for the agile project management (say SCRUM) is a product development project when the team takes on building a non-existing (or a new version of an existing one) product that gets elaborated on as the team progresses. It just naturally assumes close interaction with product management and demo-based turn-around. Integration project in a large highly-bureaucratic corporation where ten vendors have to cooperate and manage inter dependencies will naturally get very formal, and though can (and should) be delivered iteratively will have a lot of waterfall smell.

Consider how contract type affects the game plan. Another characteristic of the environment that well fits agile management practices is when the team is either in-house (e.g. business company running an internal project, ISV building software products for sale) or when performing organization runs on a T&M contract (e.g. outsourcing partner practicing Agile). Progressive elaboration to the extent when requirements get identified (not just clarified) as the system is being built is open ended in nature. Iteration cycle completes and produces an increment of the working product; the next cycle(s) will be driven by the priorities as of by then. Would you as a seller be happy to sign a fixed price contract without at least some level of due diligence on requirements? Would you rather want to build some requirements boundaries and document assumptions that would let you later be "flexible" and approach changes with a great agile attitude knowing your contract watches your back? I know what you think. I too wish I could explain all benefits of the "true agile" approach to all different businesses I get to work with. What an ideal world it would be.

Of course agile engineering practices are much less affected by the external environmental factors and writing unit tests as well as integrating continuously is like breathing regardless of whether you're up to building an internal product or a contracted vendor for one of the Blue Cross and Blue Shield licensees.

I'm slowly getting to what I was about to say here under number 2. Best practices are considered best in context. Requirements clarification and to some extent identification will be happening during construction regardless of your thoughts about it. It's the "art" part of the software construction. Though depending on the project environment you may well want to do a fair level of requirements due diligence upfront. Short on-site visit may be all you need. It will pay off.

And then finally a "requirement" can be very different. Without some level of "requirements" you just can't start the project, when existence of another level of "requirements" will only become apparent after final delivery.