Your strategy should be driven by the needs of the market. Becoming market-driven is critical to intentional product success. But it is not enough to understand your market. You have to sustain your understanding, and take advantage of it, competitively.
Category Archives: Requirements gathering
How Do You Manage Market Data?
Great product management starts with an insightful understanding of your market. Not just understanding a customer, and not even understanding all of your customers, but understanding your target market. What works for you?
Successful Products: Lucky or Intentional?
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 3 of your presentation to a venture capitalist should not say “And then we get lucky!”
Recycling An Active Listening Article
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.
Uncovering Requirements With UML Class Diagrams Part 5
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.
Posted in Requirements, Requirements Models, Requirements gathering, UML Modeling
Tagged managing data, modeling requirements, ooa, Requirements, requirements class diagram, Requirements gathering, Requirements Models, uml class diagram for analysis, uml class diagrams, UML Modeling, uml requirements
4 Comments
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 class diagrams.
Posted in Requirements, Requirements Models, Requirements gathering, UML Modeling
Tagged managing data, modeling requirements, ooa, Requirements, requirements class diagram, Requirements gathering, Requirements Models, uml class diagram for analysis, uml class diagrams, UML Modeling, uml requirements
1 Comment
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 object is made up of other objects. The two types of relationships we explore are composition and aggregation.
Posted in Requirements, Requirements Models, Requirements gathering, UML Modeling
Tagged managing data, modeling requirements, ooa, Requirements, requirements class diagram, Requirements gathering, Requirements Models, uml class diagram for analysis, uml class diagrams, UML Modeling, uml requirements
1 Comment
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 of the problem domain. That understanding prevents mistakes in interpreting requirements.
Posted in Requirements, Requirements Models, Requirements gathering, UML Modeling
Tagged managing data, modeling requirements, ooa, Requirements, requirements class diagram, Requirements gathering, Requirements Models, uml class diagram for analysis, uml class diagrams, UML Modeling, uml requirements, visio, visio uml, visio uml stencil
6 Comments
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 what they mean – but they mean different things to different people.
C.R.A.C.K. Users Are Addictive
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.
Read the rest of the article …
Posted in Business Analysis, Requirements, Requirements gathering
Tagged crack users, engaging users, managing data, stakeholders, users
Leave a comment
Latest Articles
Comments on all Articles
