Use cases represent the activities that people do when interacting with a system to achieve their goals. Use cases are a very effective tool for communicating and documenting what a system is intended to accomplish. Formal use cases are use cases that use a specific structure to represent the information. Knowing how to read a formal use case is important.
Lists / Product Management / Requirements / Requirements Models / Use Cases
Posted on:
The 8 Goals of Use Cases
Why do we write use cases? For the same reasons that our users use our software – to achieve a goal. In our case, we want to assure that we are creating the right software. By looking at this goal in more detail, we can make decisions that drive the best possible use case creation. Lets apply our product management skills to writing better use cases by writing an MRD for use cases
Product Management / Requirements / Software requirements specification / Writing
Posted on:
Writing Passionate Requirements
One of the ten big rules of writing a good MRD is writing passionate requirements. What in the world is a passionate requirement [they were all wondering]? When you believe in the product, are committed to the work, and aren’t bored, you can write passionately. The goal of a requirement is to create sustained understanding. A dry document can create understanding, but an engaging document will sustain it.
Product Management / Requirements / Software requirements specification / Writing
Posted on:
Writing Atomic Requirements
One of the ten big rules of writing a good MRD is writing atomic requirements. Just as verifiable requirements must be concretely measurable as having been met or not, so must atomic requirements. If a requirement has multiple elements that can be implemented separately, it is not atomic.
Product Management / Requirements / Software requirements specification / Testing / Writing
Posted on:
Writing Verifiable Requirements
One of the ten big rules of writing a good MRD is writing verifiable requirements. Verification is both a function of having a precise goal, and having the ability to affordably measure the requirement. A precise goal is a verifiable requirement if we can clearly answer “yes” or “no” when asked if the requirement has been implemented. We also face the practical realities of being able to measure the results profitably.
Outsourcing / Product Management / Requirements / Software requirements specification / Writing
Posted on:
Writing Unambiguous Requirements
One of the ten big rules of writing a good MRD is writing unambiguous requirements. Ambiguity is a function of communication. The writing can be generically ambiguous, or ambiguous to the writer. A requirement could be precise in intent, but ambiguous in interpretation by the reader. Understanding our audience is as important as precision in language. We write unambiguous requirements because misinterpretation of requirements is the source of 40% of all bugs in delivered software.
Product Management / Requirements / Software requirements specification
Posted on:
Writing Consistent Requirements
One of the ten big rules of writing a good MRD is writing consistent requirements. Consistency within an MRD has two dimensions that are important to requirements – logical consistency and grammatical consistency. There is also the element of writing an MRD that is consistent with other documentation – external consistency.
Product Management / Requirements / Software requirements specification
Posted on:
Writing Complete Requirements
One of the ten big rules of writing a good MRD is writing complete requirements. We identify problems and opportunities in the market. We determine that one of these problems is valuable enough and practical to implement. Then we have to write the requirements, and make sure that the requirements will completely solve the targeted problem.
Design / Product Management / Requirements / Software development / Software requirements specification / Writing
Posted on:
Writing Design-Free Requirements
One of the ten big rules of writing a good MRD is writing requirements that do not specify design. How do we specify enough detail to be actionable without constraining the engineering team? How do we trust our developers to do the right thing? The Big Rule of Avoiding Design-Agnosticism […]