Neil encouraged the use of techniques like finding analogous problems to the one you are attempting to design for, and using that analogy to uncover solutions which might be applicable - James Hulgan
So, what does a curious BA look like, what do they do differently?
- They ask probing, open-ended questions that make people stop and think.
- They explore a stated requirement vs. accepting it as-is from the stakeholder.
- They investigate the options and alternatives instead of accepting the first solution given.
- They are open to the possibility that “change” could be good. They ponder, research and communicate the risk and value of change—even if time is short and deadlines are tight - Angela Wick Garay
On Involving Developers & Testers in Requirements Elicitation
Developers are stakeholders in the project, but sometimes their input isn’t solicited and they become the “victims” of the requirements that are thrust upon them. I like to have developers review requirements as they are evolving. That way they know what’s coming and can spot areas that need more clarity. You also need developer input when specifying internal quality attributes that aren’t visible to users. Developers can offer suggestions no one else might have thought about: easier ways to do certain things; functionality that would be very expensive to implement; unnecessary imposed design constraints; missing requirements, such as how exceptions should be handled; and creative opportunities to take advantage of technologies - Karl Wiegers and Joy Beatty
Testers are also likely to find many ambiguities, conflicts, and concerns with the requirements as they are developing their test cases and scenarios from the requirements. Testers can also provide input on specifying verifiable quality attribute requirements - Karl Wiegers and Joy Beatty
