"It's spot on" - wouldn’t you love to hear that from users of your next application? Maybe a little more
research into the relationship of usability
and requirements is in order.

The adages “early and often” and “trust but
verify” especially apply to the practice of UI design
and the process of gathering requirements. Since
the creation of an appropriate interface is (or
should be) directly related to the MRD (Market
Requirements Document), I’ve compiled some
research about MRDs.

Hopefully a better understanding of the
requirements process and early involvement in
that process can help us, as designers, contribute
to the construction of useful and usable products
- because the last adage a product manager or an
interface designer wants to hear applied to their work is “it’s a day late and a dollar short”.

Requirements Gathering Essentials
Focus is the most import aspect of any
requirements document. A good requirements
document clearly states the objective of the
project and defines its scope, to clarify what the
project does and does not cover.
Link

Requirements Document Alphabet Soup
– Explained
An article comparing the different requirements
document formats used in the software industry.
. . BRD, MRD, PRD, FSD, PSD, SRS, IRS, etc.
Link

Bridging the Gap with Requirements Definition
How do you ensure that your new product doesn't
flop? One effective method is to conduct a
requirements definition phase before developing
a new product.Requirements definition simply
means "figuring out what to make before you
make it.
Link

Understanding Customer Needs
Buyers of software often have trouble understanding and clearly describing their problems, and articulating detailed solutions. Non-technical users lack the depth and vocabulary to precisely specify what they need; technical representatives are often missing clear priorities, user experience and company-wide scope.
Link

Writing the Market Requirements Document
This document is written for product managers in high-tech companies who are chartered with documenting product requirements in the form of a Market Requirements Document (MRD).
Link

How to Put Together a Marketing Requirements Document (MRD)
Focus is the most import aspect of any
requirements document. A good requirements
document clearly states the objective of the
project and defines its scope, to clarify what the
project does and does not cover.
Link

Crafting Market Requirements
“Voice of the Customer” (VOC) is a process for
eliciting needs from customers. It embodies a
market-driven approach that involves spending
time with current and future customers to
determine past, present, and future market
problems that customers need to solve in order
to meet their business goals and objectives.
Link

MRD Template
Link

MRD Sample
Link

The PRD and Me
A PRD is a document that outlines all the
requirements that should be met for building a
product. The PRD is created when the MRD
(Marketing Document) has been finalized and
delivered. The scope of the PRD could be a few
FSDs (Functional Specifications Document) or it
could be a massive bundle of documents.
Link

Yes! Expect or Write an "Agile"
Requirements Document
The problem with MRDs is not what they contain
but when they’re written.  . .  It is not uncommon
for an MRD to be a year or two ahead of the final
release, which requires the product manager to
see far enough into the future to anticipate new
technologies and competitor capabilities. 
Eliciting and Specifying Requirements for Highly
Interactive Systems Using Activity Theory
Link

Eliciting and Specifying Requirements
for Highly Interactive Systems Using
Activity Theory
It would seem that the products under
development are often not the products that
stakeholders and users actually want.
Formal methods of generating and specifying
requirements have a chequered past when it
comes to dealing with interface design.
Link