Interviewing, Brainstorming, Documenting Use Cases, Prototyping, and Analyzing Documents are our top-five tips. Read more for details
Are people reading your requirements? A blogversation.
Tony just put up a post at Seilevel’s blog on making sure your spec is reviewed. Kent Newsome recently posted about starting cross-blog conversations here, possibly inspired by Amy Gahran’s post about it here. Tony’s post is a great topic to cross-blog about. Three easy steps to blogversation Post your […]
Readability and Requirements
Thanks to the download squad for pointing me at the Juicy Studio: Readability Test! You can go to Juicy Studio’s site, and calculate the reading level of any URL. You can also try the Readability Grader at Jellymetrics, for a modern take on it. Of the multiple analyses provided, the […]
Why We Should Invest in Requirements Management
Need to convince someone in your management chain why they should invest in managing requirements? There are some great arguments…
Managing requirements conversations
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 […]
Communicating a delivery schedule with use cases
Use cases are a great tool for establishing the scope of a project. They provide a framework for defining what needs to be implemented (if it doesn’t support a use case, we don’t need to implement it). They also set expectations with stakeholders (here’s what you can do with the […]
Stay away from my users!
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?
Secret decoder ring
I’m having a little trouble reading the spec – I left my secret decoder ring at home! Ever hear that before? A set of requirements that makes perfect sense to one team member can be completely unintelligible to others. Requirements written in business-speak, or full of accounting jargon may be […]
Everything I Needed To Know I Forgot in Kindergarden
“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.