Symbolism and Communication

Posted on:

Symbolism and communication
One of the challenges in successful communication comes from the way people use symbols as part of the organization of their thoughts. Symbolic thinking and reasoning is an incredibly efficient process. It allows us to create representational views of the world that allow us to process much more information than our brains have evolved to handle.

What does this have to do with requirements?

We see from our earlier post on requirements gathering techniques that communication is central to the most important requirements elicitation methods. Understanding how people associate ideas symbolically helps us communicate more effectively.

iRise – software prototyping tool

Posted on:

We received a comment from Tom Humbarger at iRise on an earlier post, which led us to take a look at their site. iRise provides a tool for rapid prototyping of web-based applications, and there’s an overview of the products available. They have iRise Studio which allows people to create […]

Dilbert does product managers

Posted on:

http://www.dilbert.com/comics/dilbert/archive/dilbert-20060129.html We won’t copy the image of the cartoon – but we’ll tell you that it opens with Alice: “I’ll need to know your requirements before I start to design the software.” ObRelatedTopic: How to interview when gathering requirements Great Dilbert products The latest book (Nov 2005) from Scott Adams, […]

How To Interview When Gathering Requirements

Posted on:

We previously stressed the importance of understanding why something is a requirement. Unfortunately, we can’t just ask “why why why?!” until we reach the end of the chain. This won’t be any more effective for us now than it was when we were in kindergarden. Eventually, our listeners will get frustrated, or worse, defensive.

Managing requirements conversations

Posted on:

In Documents vs. Conversations, on the Pyre blog, Greg Wilson does that thing that we so rarely do – he takes a step back, and thinks from an entirely different perspective about managing requirements. He proposes the idea of managing requirements as conversations, instead of as documents. Greg makes the […]

Stay away from my users!

Posted on:

We’ve dealt with user representatives who believed that they knew better than the users. We’ve dealt with people afraid to let consultants talk to the users, because the consultants might mis-set expectations and create bad will when the development team fails to deliver. We’ve dealt with over-protective information-hogs, who don’t want to telegraph their moves, for risk that they might lose control of the project, or lose credit for the project to someone else. How do we get past these barriers?

Everything I Needed To Know I Forgot in Kindergarden

Posted on:

“WHY?” is the central theme, the underlying cause, and the most important element to developing a successful product. And it plays an important role in documenting requirements. Without knowing why a product is valuable or why people will use it, or why it needs to be done in 3 months instead of 6, you aren’t likely to make the right decisions about what to include, when to include it, or how to market it.