…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.
Communication / Requirements / Software requirements specification / Writing
Posted on:
Writing Requirements Unambiguously
Writing requirements without ambiguity
This is one of the harder parts of writing good requirements. Marcus tells us to avoid it with a good example here. Jerry Aubin at Seilevel has written an outstanding post on the subject, The art and science of disambiguation. Jerry starts his post with a gripping example from Weinberg and Gause:
Requirements / Software requirements specification / Writing
Posted on:
A requirements documentation mistake
Learn from an early mistake of mine At a previous employer, the first time I played the role of requirements manager (technically, program manager – with responsibility for the functional spec), I made a bunch of mistakes – this post is about one of them. The setup We were engaged […]
Communication / Requirements
Posted on:
Everything I Needed To Know I Forgot in Kindergarden
“WHY?†is the central theme, the underlying cause, and the most important element to developing a successful product. And it plays an important role in documenting requirements. Without knowing why a product is valuable or why people will use it, or why it needs to be done in 3 months instead of 6, you aren’t likely to make the right decisions about what to include, when to include it, or how to market it.
Communication / Presentation / Requirements / Requirements gathering
Posted on:
Active Listening and Cultural Cues – When No Means Yes
Without good communication skills, you won’t understand what the stakeholders want. And you won’t structure and describe the requirements in a way that the developers will implement what you intend.
For a given project, there are three sets of requirements – the requirements you are given, the requirements you document, and the requirements that are interpreted by the delivery team.