This video discusses the perfectly-formed requirement, which should be unambiguous and testable. It presents the Snow Card, focusing on the requirement, rationale, fit criterion, and supporting materials.

This presentation discusses “designing and documenting user interactions.” It emphasizes the importance of writing good documentation, the value of style guides, while never losing site of the end goal of creating good user experiences.

How do agile requirements work? Where does documentation fit in? For many of us, the transition from the security of upfront analysis and detailed specification documents to ‘doing Agile’ and embracing the process of discovery is a terrifying prospect. Agile theories don’t readily address the concern ‘how will we know where we’re going if we don’t start with a Business Requirement Specification?’

When you are gathering and documenting software requirements, it is not always easy to remember all the dimension that should be included in this activity. The book “Mastering the Requirements Process” proposes a template that should help you in this activity.

This short video discusses what the content of a business requirements document should be and provides ten tips on how to create the perfect business requirements document.

What do you document and how much should you document? This question is often present in software development projects and even more now with Agile approaches. This article presents a template for managing software requirements and software problems. This templates have been validated within the industry in various parts of the world.

Document management is a important part of requirements and specification management with topics like taxonomies, focusonomies among others. A “taxonomy” is a grouping mechanism. A “focusonomy” is a tagging mechanism that allows to recognize document that focus on the same topic.

One of the first questions Business Analysts ask when confronted with an agile method is “How agile method cant incorporate our documentation.” And sometimes it is not a question, but an affirmation. This article provides good framework for integrating agile and formal documentation.

Story writing is usually taught now as a singsong “As a I want so that .” The writer should then immediately document acceptance criteria in the form of a constraint list or automated acceptance tests. Many consider it poor form to create a story that someone outside the team can’t understand from its documentation alone. In this article Paul Dupuy explains that an ideal user story’s documentation should be nothing more than a short, memory-jarring name.