Archive of Requirements gathering Articles

We’re dedicating our “blogging time” this week to doing some infrastructure upgrades - we have to address some security issues on the site. Until we get through these changes, we’ll be recycling some of our existing content. For our recent readers, it will be “new to you” and for our long time readers, we appreciate your patience. Today we look at one of our better received articles on active listening.

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 have to deal with more complex relationships that involve more than two objects to properly describe. This does not happen as frequently, but when it does, our modeling efforts are more likely to uncover overlooked requirements. In this article we learn how to describe relationships that involve more than two objects.

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 class diagrams.

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 object is made up of other objects. The two types of relationships we explore are composition and aggregation.

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 of the problem domain. That understanding prevents mistakes in interpreting requirements.

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 what they mean - but they mean different things to different people.

Barry Boehm, inventor of the spiral model of software development, may also be the originator of the CRACK acronym for the type of users we want on our projects. When defining (and executing on) projects, we don’t just want CRACK users, we want CRACK stakeholders. And we want them to stick around. In fact, we’re addicted to them.

How do you approach starting a small requirements project as part of a large initiative within a massive enterprise? Do you boil the ocean? Your customer knows she needs “requirements” to give to her development team. She asks you - what will you deliver, and how long will it take? Great questions. If you have to write a statement of work, with time/cost estimates, and a list of deliverables - what would you do?

[photo by Henkster]

Writing good requirements is more than just about following a set of rules. You can capture knowledge about your goals and your product with a set of well crafted requirements. But to truly write good requirements, you have to gain a level of understanding that surpasses knowledge. Insight springs from understanding, and insight leads to great requirements and ultimately great products.

No matter how good your quality process is, you are introducing bugs. This article reviews the places where bugs are introduced in the software development process (from stakeholders to users), and reviews ways to address those bugs.