In this article, we build on our ability to represent straight forward business relationships in UML class diagrams. These relationships describe how two objects are related to each other. Representing relationships in class diagrams helps us to better understand the domain and helps us to uncover hidden requirements. Occasionally, we […]
Uncovering Requirements With UML Class Diagrams Part 4
The hardest part of gathering requirements effectively is uncovering the requirements that people don’t immediately tell you. You have to ask the right questions. And one of the best ways to find the right questions to build a class diagram of the business domain. This article continues our introduction to […]
Uncovering Requirements With UML Class Diagrams Part 3
UML Class Diagrams are very effective at uncovering requirements. They give us insight into how the business thinks about objects and their relationships. And from that understanding, we think to ask questions we might otherwise overlook. In this part of our series, we look at how to represent when one […]
Uncovering Requirements With UML Class Diagrams Part 2
We continue our exploration of UML Class Diagrams with this article that explores how to represent basic business relationships in a class diagram. Drawing these relationships can dramatically clarify requirements documents. Using a class diagram to supplement other requirements documents provides for a centralized reference that enables a shared understanding […]
Uncovering Requirements With UML Class Diagrams Part 1
UML Class Diagrams can be used not only for documenting software design, but for documenting software requirements. One of the challenges in writing clear, unambiguous requirements is being precise about what a particular word means. This is especially true with symbolic terms like “quote” or “customer” – where everyone knows […]
A Picture Is Worth A Thousand Requirements
Object oriented analysis and design (OOA/OOD) is a technique used to gather requirements and develop software, as an alternative to more traditional text-based techniques.
OOA allows for clarity of communication, by creating descriptive and unambiguous documentation of requirements. It comes with a great big giant caveat –