Writing Effective Requirement Documents – An Overview
From the post:
In every UX Design project, the most important part is the requirements gathering process. This is an overview of some of the possible methods of requirements gathering.
Good design will take into consideration all business, user and functional requirements and even sometimes inform new functionality & generate new requirements, based on user comments and feedback. Without watertight requirements specification to work from, much of the design is left to assumptions and subjectivity. Requirements put a project on track & provide a basis for the design. A robust design always ties back to its requirements at every step of the design process.
Although there are many ways to translate project requirements, Use cases, User Stories and Scenarios are the most frequently used methods to capture them. Some elaborate projects may have a comprehensive Business Requirements Document (BRD), which forms the absolute basis for all deliverables for that project.
I will get a bit deeper into what each of this is and in which context each one is used…
Requirements are useful for any project. Especially useful for software projects. But critical for a successful topic map project.
Topic maps can represent or omit any subject of conversation, any relationship between subjects or any other information about a subject.
Not a good practice to assume others will make the same assumptions as you about the subjects to include or what information to include about them.
They might and they might not.
For any topic maps project, insist on a requirements document.
A good requirements document results in accountability for both sides.
The client for specifying what was desired and being responsible for changes and their impacts. The topic map author for delivering on the terms and detail specified in the requirements document.