On being creative:

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

On curiousity:

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

On Planning For Requirements

This may sound like a lot of work, but I ask you what are the alternatives?  If we don’t plan, how do you know if you are making progress?  How do you know when you will be done?  What answers do you give your project manager?  A bit of preparation can go a long way to answering those questions - Betsy Stockdale

On Requirements

Rather than declaring the requirements “done” at some point, define a baseline, a snapshot in time that defines an agreed-upon foundation for subsequent work and modifications. Once you’ve established a baseline, follow your change control process to modify the requirements, recognizing the implications of making changes. It’s folly to think you can freeze the requirements and allow no changes after some initial elicitation activities - Karl Wiegers

Don’t use uncertainty as an excuse for lack of precision. Acknowledge the uncertainty and find ways to address it, such as through prototyping - Karl Wiegers

On Delegating 

The other benefit of using visual models is that it is easier to bring everyone up to speed quickly. The models will explain what is going on in the project at a very high and very low level.  Models will show the context of the piece of the project that is being delegated, so it is easy to see how that part contributes to the whole. Your models should be the key tutorial tool you use when explaining the project to new resources - Jeremy Gorr

On Using a Business Objectives Model 

The Business Objectives Model is a separate exercise to discovering your product concept. It begins with problems. The discussions of “What is wrong with your business?” leads to answers that assist in defining the product concept. Imagine your stakeholders tell you that they need claws, large teeth, orange and striped fur, and that they needed it to be an elephant. It means they want a Tiger instead. This, unfortunately, is the state of most businesses, and a large reason why projects fail from scope creep and budget issues – Matt Offers.