I don’t know how many of our readers have reached a conclusion to this debate, but we have for now. Thanks to everyone who has contributed to, enjoyed, or at least tolerated this ongoing discussion. Roger had some good comments in our previous article – we’ll try and address one of his points here. His point, I believe, is that using the word “requirements” to describe multiple levels of abstraction in the definition of a product is a bad thing.
Requirements
Posted on:
Requirement Naming – Stick A Fork In It?
The discussion about requirements and the naming of things continues? Can we stick a fork in it already? Maybe, but probably not. Catch up on the cross-blog discussion with Roger and Adam.
Requirements / Requirements Models / Use Cases
Posted on:
Subordinate and Superordinate Use Cases
Use Cases can be built up by combining other use cases. When a use case is made up of other use cases, the component use cases are known as subordinate use cases. The “parent” use case is referred to as the superordinate use case. This is known as composition. See an example of how composition works for use cases.
Design / Interaction design / Prioritization / Requirements / Software development / Software requirements specification / UX
Posted on:
Fifteen Ways to Shut Down
There are 15 ways for someone to shutdown a laptop running Windows Vista. This adds unwarranted complexity to our software. How can we avoid the same problem in our software?
Business Analysis / IIBA / Lists / Organizations / Requirements / Requirements gathering
Posted on:
Ten Requirements Gathering Techniques
The BABoK (Business Analyst Body of Knowledge) lists 10 techniques for gathering requirements. Here’s an overview of each one. For more details, check out the latest Guide to the BABoK.
Business Analysis / Requirements / Writing
Posted on:
Pairing Business Analysts
Pair programming is a bit of a foreign concept for many people in business. A few years ago, it was foreign to most programmers too. Pair programming is a powerful technique for software development because it allows two people to look at the same problem/solution from two different perspectives at the same time. Would that same approach work for business analysis?
Interaction design / Product Management / Requirements / Requirements gathering / ROI / UX
Posted on:
Gathering Implicit Requirements
Johanna Rothman just wrote an article titled Implicit Requirements are Still Requirements. She points out that her expectations were not met, even though her needs might have been. Johanna also implicitly begs the question – how do we gather implicit requirement?
Interaction design / Prioritization / Product Management / Requirements / UX
Posted on:
How To Not Suck At Design
Michael Shrivathsan just wrote an article presenting five tips for creating products with great design. Michael’s List Start with the user interface. [Roger Cauvin adds, start with a working first iteration] Work closely with UI designers. Pay attention to details. Simpler is better. Be brave. Our Thoughts User centric design […]
Product Management / Requirements
Posted on:
Valuable and Functional Requirements
Roger asked some interesting questions on one of our previous posts about market and product requirements. In a couple recent articles, we presented some specific examples to clarify the semantics and language of different types of requirements. Roger asks six questions about functional and non-functional requirements in the comments on the last article. In this article, we answer them.