1

What scientific/empirical evidence is there that the mental separation between (business) analysis and (technical) design in software development leads to better results than considering both together?

Background: I'm talking about separation on a small scale here, i.e., for a single user story, separate between "acceptance criteria" that document what shall be done from a requirements-centric, non-technical point of view and "design+implementation" that determines how the acceptance criteria are implemented in a specific solution. I'm NOT talking about "first do all the analysis, then do all the design" (big design up front); which is assumed to be bad. I'm also NOT talking about "don't change the analysis once you have started design" (pure waterfall); which is assumed to be bad, too.

I always considered it rather obvious that such a separation between analysis and design is beneficial. And there is lots of advice that says this is a good thing, sometimes using different words like "requirements", "opportunity space vs solution space", "domain-driven design", ... but essentially meaning the same idea: Don't mix up problem and solution, but have a clear mental separation of them. But recently a co-worker challenged why we should do so. And I realized that apart from "common sense" and logically deductive arguments, I don't know of real empirical evidence that shows that such a separation is good. In which "good" could be anything from "less effort" over "better solutions" to "more maintainable software". Do you know any empirical studies?

T. Baum
  • 19

2 Answers2

2

If you rule out stereotypical waterfall-style constraints (all the analysis precedes all the design, with no revisits), but instead consider the ideal to be an oscillation back and forth within a small-grained scope, then in what sense are they separate even in your own idea?

"Analysis" tends to emphasise the investigation of the problem, whereas "design" tends to emphasise finding solutions to known problems, but I would say the distinctions in these two activities are vague rather than strict. And it's not uncommon that design throws previously unperceived problems into relief.

When conceived as a separate activity, the analysis stage tends to be about articulating the problem in writing, and is done best by people also broadly experienced in design, since this increases their ability to perceive problems.

The purpose of this activity is not to isolate analysis from design, but to produce an intermediary artefact - a written, and therefore communicable, description of the existing situation, prior to any proposed changes.

The fact that analysis and design are talked about separately doesn't mean they are done separately, any more so than talking of the left leg and the right leg separately, means each leg walks separately. The walking of the two legs, and which foot you start or finish on, or where your weight is borne at any one time, are usually relatively unimportant to the outcome of walking a distance.

When a development project requires more than one person due to its scale, that's when it becomes necessary for things to be communicable.

When something is small enough not to need communicable analysis, then a single person is likely to do analysis and design themselves like walking.

Steve
  • 12,325
  • 2
  • 19
  • 35
1

I will focus on the acceptance criteria that you seem to categorize in the analysis:

for a single user story, separate between "acceptance criteria" that document what shall be done from a requirements-centric, non-technical point of view and "design+implementation" that determines how the acceptance criteria are implemented in a specific solution

Considering that a user story is the placeholder for a conversation, the reason is that the acceptance criteria should be agreed with the user, and the user understand best the problem space.

Moreover, the acceptance criteria should be aligned with the user's goals. Having it bound with the designed solution would close the door to creative alternatives that might emerge to be "better" (whatever this should mean) than the first design. In other words, having acceptance criteria in the problem space is more open to change within a sprint.

Last but not least, acceptance criteria elaborated with the user in the problem space also allows to better understand what the user is really looking for.

Now is there a study that documents this? Maybe, but such a study would only make sense if we could isolate the impact of the acceptance criteria from the impact of the user story itself, and this on a representative number of projects, whereas in reality the personal abilities and expertise of team members is what will have the most impact on the results.

Christophe
  • 81,699