Successful Products: Lucky or Intentional?

Posted on:

Is your product successful because you were lucky, or because you were methodical and intentional? Do you want to build a plan where you are dependent on good fortune, or do you want to make your own “luck?” Both approaches work, but only one makes sense as an intention. Slide […]

Recycling An Active Listening Article

Posted on:

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 […]

Uncovering Requirements With UML Class Diagrams Part 5

Posted on:

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

Posted on:

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 2

Posted on:

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

Posted on:

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 […]

C.R.A.C.K. Users Are Addictive

Posted on:

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 […]