…Is another man’s treasure. There are many different ways to document requirements when developing software. And there is a proliferation of requirements documents - MRD, PRD, SRS, FRS and design documents. Everyone has a perspective on what each document represents, and each person on the team has a unique perspective on what questions the document answers.

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

Article by Suzanne Robertson about how to approach writing requirements when you are under constraints that prevent you from completing them.  Good article, very stimulating discussion in the comments.

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.

When you define a product roadmap, you also define the release dates for your product. Change happens. Your market changes, your customers change, your requirements change. Unpredictable events happen. Your competitors release a new killer feature, your developers have an epiphany (or run into a roadblock). Should you change your release schedule?

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