Article provides an overview of twelve rules for writing good requirements. Each rule has its own page (linked from this one).

Provides comparison and understanding of looking at products in terms of what the products can do, versus what the user can do with the products.

By writing better requirements

If you want to be a bad product manager, ask customers to tell you why they love your product. If you want to be a good product manager, ask customers to tell you why they hate your product.

From Rachel Davies:

In the last few years, the agile software development movement has created a paradigm shift in how we work to understand system requirements. Agile teams shape software systems using a collaborative process, with executable software at its heart and documents marginalised to a peripheral role. This creates a fundamental shift away from tools for managing requirements artefacts. Instead, we need tools that support collaboration and the gradual distillation of business rules into automated test suites.

Seth Godin provides us with guidance about the importance of revolutionary change, not just evolutionary change.

Discussion of agile vs traditional requirements management

Overview, explanations, and details from Scott Ambler.  This documentation approach can be used for agile and non-agile processes.  It can also be used for product management / development and for business analysis.

When you hire a product manager, one of the first series of tasks she should complete is to position the product. Positioning a product means defining your target market and key messages you will use to appeal to them.

Positioning the product in the most effective way typically requires leaving the office and doing substantial market research, including quantitative research (questionnaires) and qualitative research (prospect interviews and ethnographic studies).

Presents philosophy that there are four classes of software:

• MeWare:  The developer creates software.  The developer uses it.  Nobody else does.
• ThemWare:  The developer creates software.  Other people use it.  The developer does not.
• UsWare:  The developer creates software.  Other people use it.  The developer uses it too.
• NobodyWare:  The developer creates software.  Nobody uses it.

Includes detailed real-world analysis of City Desk, a software package - applying the ideas