…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 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.

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?

Product roadmaps can be powerful assets to leading a technology business – buy only if they are created and managed in the context of appropriate policies. In fact, the product roadmapping process a company uses can be as important to its business as the roadmap itself. In the Product Strategy Network’s roundtable meetings on product roadmapping, field-tested practices and policies are presented in detail by PSN Members. Here are a few of the highlights:

An article on testing strategy for non-functional requirements that stimulated a fantastic discussion about functional vs. non-functional requirements. Great points are made both to eliminate and to highlight the distinctions. The strategy for developing a test plan is good, and worth reading alone, but this article is fun in that it went in a completely different direction with a very well informed debate.

Okay, we're getting somewhere with our question. "Soul" seems to be the essence or the actuating cause that decides how someone or something behaves.

Does Your Product Have a Soul?
This brings us to the single most important question in this article: