This is an article by Steve Calde who will be presenting at the July 2008 Catalyze webcast.

"Personas and other user-modeling techniques are often solely discussed as tools for product definition and design, but they are useful tools in other arenas, as well. Technical writers responsible for creating user documentation can benefit greatly from a well-defined persona set, too.

Using personas to guide your user-documentation creation-process helps you:

• Determine the primary and secondary audiences for your documents
• Prioritize technical writing tasks by giving you a tool for identifying which aspects of the product are most important to your readers
• Write documentation in a way that helps your users achieve their goals, instead of simply cataloguing all of the product's features."

Ten Tips for Driving Better Project Outcomes
This is the recording of the June 12, 2008 Catalyze Webcast recording with Carey Schwaber from Forrester.

"It’s no secret that in the battle to bring effective business software to market on time and on budget, business analysts are on the front lines.   What can business analysts do to improve requirements definition practices and make a difference in project outcomes?  Join us as Forrester Senior Analyst, Carey Schwaber, shares a set of 10 practical tips that you can immediately put into action in your organization.  The Webcast was sponsored by iRise."

The slides are available here.

From CIO.com and Esther Schindler...

"A handful of über-programmers are immediately recognizable to most software developers, often on a first-name basis—the way that other communities might recognize "Britney" or "Oprah" without further explanation. These individuals shape the way programmers design and build applications, by identifying process improvements or designing life-changing tools.  One unquestioned person on that list is Grady Booch. His primary influence on object-oriented programming was as an original developer of the Unified Modeling Language (UML)."

1. The fundamentals never go out of style
2. You need a regular rhythm of releases
3. Focus upon growing executable architectures
4. Create social structures that encourage innovation while still preserving predictability
5. Have fun!

Read the entire article for all of the details and links.

Video tutorial of a stakeholder interest analysis from Com Kaner, professor of computer science from Florida Institute of Technology.

"An example of a stakeholder interest analysis." [Kaner & Bach's Black Box Software Testing Course (BBST Public Course), hosted at the Satisfice Moodle server, www.satisfice.com/moodle, BBST Public Course, enrollment key = "whitebox".] Developed for an ethics course that Keith Miller and I taught at University of Illinois, this illustrates the same type of stakeholder analysis that we do when evaluating requirements for test documentation, test automation, scenarios, etc"

Here is a blog post that "suggests a minimal way to gather requirements, one that produces a (minimum) requirements document in an iterative and agile manner.

Nick Malik blogs for the Inside Architecture blog on MSDN.

We know that we must involve all the stakeholders if we want to discover a project’s requirements. But we need some guidelines on how to involve the right people and, given how busy everyone is, how to minimize the time and maximize the result. In this column, requirements guru Ellen Gottesdiener shares her considerable experience running requirements workshops.

Requirements are (or should be) the foundation for every project. Put most simply, a requirement is a need. This problem, this need, leads to the requirements, and everything else in the project builds off these business requirements.

This article from Jason Moccia of OneSpring examines the issues with traditional textual requirements and how simulation helps solves these issues.

Jason has over ten years of experience in the software development field and is a co-founder and managing partner of OneSpring (www.onespring.net).

From SoftwareMag.com - a Journal for IT Professionals.

"Successfully addressing requirements management from a more iterative approach requires aligning business with IT; open communication is key"

This is an article by Lana Gates on the importance of requirements to business.

In moving from requirements analysis to design, use cases are often recommended as the starting point for the derivation of classes. However, exactly how classes are to be found within the use case is not entirely obvious. Typical approaches suggest a simple noun/verb search or brainstorming. Recent work is moving towards an interrogation of the use case diagram as a means of validation and of the description (and scenario) to elicit objects in the problem domain. This paper presents a set of Elicitation Questions that enables the interrogation of descriptions from the perspectives of specification, software architecture and design. This qualitative 'interrogation' teases out design issues. The Elicitation Questions were trialled through application to a real industrial project at a financial services company. Feedback from practitioners shows that the Elicitation Questions are important in raising design and testing issues from the use case descriptions but the organisational culture in how software is developed would impact its uptake.

"Features. We love them and we hate them. Features you need, enhance your ability to complete tasks, and are easy to love. Features that get in your way or add extra effort, interpretation or exploration, can be a pain."

In this blog post, Frank identifies ten tips for to bring some discipline to feature creep when identifying user experience strategy and defining user interfaces.

1. Get task focused
2. Map business requirements to user tasks
3. Talk about user tasks and not features
4. Design for probability not possibility
5. Validate features with user tasks
6. Map features to tasks
7. Create a feature-task matrix
8. Think scenarios first, use cases second
9. Use tasks to test features and features to test tasks
10. Use diary studies to evaluate feature adoption over time

Read the entire post to get all of the details and story.

Frank is a usability consultant and founder of Experience Dynamics.

Summary: In this paper from StickyMinds, Tom and Joe present a simple, practical calculation of the cost of requirements errors in application software development projects.  They also recommends a way to find and fix these costly errors early in a project, when they are least expensive to correct.

This is the presentation from the Catalyze Community monthly webcast featuring Charlie Kreitzberg on December 13, 2007.

Charlie spoke on "Web 2 and You - How Web 2.0 Will Catapult Business Analysts and Usability Professionals into Center Stage" which examined his models for understanding Web 2.0 and explored the vast opportunities for professionals who define and design new software and websites.

The file upload is the PDF version of the presentation which include Charlie's notes.  You can also view the presentation online at SlideShare.net.

The recording for the webcast is available here.

Charlie also has a blog on Catalyze called ID : The Art of Interaction Design.

This is the recording of the presentation from the Catalyze Community monthly webcast featuring Charlie Kreitzberg on December 13, 2007.

Charlie spoke on "Web 2 and You - How Web 2.0 Will Catapult Business Analysts and Usability Professionals into Center Stage" which examined his models for understanding Web 2.0 and explored the vast opportunities for professionals who define and design new software and websites.

The slides from the presentation are available at this link.

Charlie also has a blog on Catalyze called ID : The Art of Interaction Design.

This is the recording of the first Catalyze webcast originally broadcast on August 23, 2007.  Jackie Parker from River Lee International demonstrates how to apply the art and science of facilitation to Joint Application Design or JAD sessions.