Great point about having too many people SMEs in the room.

Interesting observation about requirements volatility and the “cost of code.” With incremental processes, I think you may be on to something. On waterfall projects, we still have a very large cost of misdelivery (even if the coding is cheap, the lost ROI is expensive).

I don’t know that I’ve experienced “group-based requirements” as being more volatile than others (doc analysis, SME interview, etc). Anecdotally, I think I’ve seen the most volatility when doing sequential interviews of SMEs with differing perspectives, and by getting those folks in the room at the same time, I’ve been able to reach consensus more quickly. All during the elicitation phase. Can you elaborate on how the group-stuff is more volatile than requirements gathered in other ways?

Somewhere in all of this the RA was said to be the reality check for delivering implementable requirements. Efficency comes up in this discussion. We are still using RE techniques that originated when code was expensive. As code has become cheaper, RE techniques have not changed. Given the volitility of requirements gathered via JAD and other group techniques, would it be more efficent to gather and deliver applications at the level of the individual? My guess is yes. Otherwise, the application will be recoded in a few weeks when the next paradigm wins discipline adherents.

Great comments and questions! I agree with your second paragraph, and would say that I am asking the right question (in a somewhat Socratic way).

Starting with agreement. Your point about risk-adjusted analysis of cost/benefit is perfectly right. Also, recognizing that some topics are analytically harder to absorb than others is a key insight. That combined with variation in BA skill / horsepower will drive tactical staffing decisions more than anything else. For some BAs, a complex domain is “simple” and for some, a straightforward domain may still be “hard to grasp.”

As to the question I was asking – I intentionally used the phrase “twice as good” because the desired results will vary by project and project objective. My goal was to have people ask “what are the results that matter for my project?”

Quality of requirements might be paramount, given binary choices, but not with a continuum of quality and the law of diminishing returns. There is absolutely a minimum level of quality, below which every incremental effort is best spent improving quality. What about above that level?

Using hypothetical data to make my point: 20 requirements written with “good enough” quality (conceptual accuracy, spelling and grammar mistakes, slightly non-optimal prioritization) will provide “more results” than 10 requirements written with the same conceptual accuracy and perfect spelling, prioritization.

We also have to balance resources across the team – if we have developers starved for work (analyst bottleneck), then the “value” of an additional requirement today (even if it gets rewritten in the future) may exceed the value of perfecting an existing requirement. We may also be constrained by SME/stakeholder availability.

It is a complex balancing act, and requires exactly the kind of analysis you provide in your comments – but that analysis is going to be specific to a given situation.

Given all that, I still think the “summary” answer that I wrote originally is sound:

A simple question deserves a simple answer: two if you can afford it, one if you can’t.[...]

Having two interviews, each by one analyst, each of a single SME, will probably unearth more requirements than if both analysts interviewed a single SME once in a joint session. When the schedule/budget is tight, use this approach for the most efficient requirements gathering. When efficiency is not a driver, then doubling up the analysts will get better data – just not twice as good.

Based on all the great feedback in the comments, I would say that we all agree that investing in “more analysis” is better, and we should push to staff the double analysts. When we can’t get the staffing we desire, I lean towards the single analyst model, although the facilitator/scribe method does have a lot of benefit as long as both people have the needed skills.

I’m not sure you’re asking the right question. What does it mean to get “double the results?” Are we talking about quantity of requirements or quality of requirements? If you’re asking if two analysts could generate twice as many requirement statements as one, then I would say, probably not. If we’re talking about quality of requirements, then how does one measure this to determine if two analysts are better than one?

I think the answer lies in the complexity of the domain under consideration. I wouldn’t necessarily double up analysts on, say, the requirements for User Management. In general, this functional area tends to be straightforward and has identifiable patterns. However, for functional areas or domains that are quite a bit more complex, then the marginal benefits of a second analyst and the concommitant increase in quality of requirements becomes a better value proposition. The costs of screwing up the domain model or data model for a system is much higher than screwing up look/feel in a UI. A second analyst eyeballing a domain model and the web of business rules that accompany it can be invaluable when the business is complex and confusing – especially if one is involved in de-tangling the organic structure of legacy systems.

The question, “is the cost of two analysts worth the marginal increase in quality of requirements delivered?”, can only be answered in context to the risk inherent to the functional area being examined.

OK, it looks like y’all are ganging up on me about the facilitator/scribe combination. I like the idea very much, and agree that it is effective.

In the article above, I proposed that it is more expensive (and therefore less efficient) to use this approach – that the doubled cost, while yielding markedly improved results, will not yield more than doubled results.

I’m happy to be proven wrong – so – everyone who’s read this far – please chime in: are two analysts more than twice as good as one?

I guess I should have titled the post “How many people for SME interviews”, and called out that it is only one form of requirements gathering. We also have an article that identifies several types of requirements gathering.

As to larger meetings – yes, there are other types of meetings – I was targeting the interview specifically in this post. Getting more people in the room changes the dynamic of the session into a different type of session.

Depending on the level of expertise of the SMEs, larger sessions may be required to get a full understanding of a process/requirement. Otherwise, larger meetings will have SMEs “taking turns” telling us stuff – it could be more efficient to split those meetings into smaller more targeted sessions.

Thanks again for reading!

I was at the Proforma user conference last week where one customer described their requirements elicitation meetings, which always included both a facilitator and a scribe. In this case, the scribe used the Proforma tool directly to model the business processes live in the meeting, which they found to increase accuracy and shorten the requirements documentation process. They also recommend that smaller groups are better, a point with which I agree, although sometimes more than the two SMEs that you recommend can be optimal.