Rishikesh Tembe shared twenty rules for software product delivery last month. His rules are from the perspective of a former software developer. Some we like. Some, not so much.
Business Analysis / Requirements / Requirements gathering
Posted on:
Idea Seeding Better Than Brainstorming
Kevin Cheng and Tom Chi, at OK/Cancel have written an article sharing the creative process they use for creating their awesome strips. Idea seeding is the process where they use time constraints and design/refine cycles to improve their ability to create quality “product.” They also wonder about extending this approach to other areas where brainstorming is normally used.
Process Improvement / Requirements / Software development
Posted on:
Software Silver Bullet
“I believe the hard part of building software to be the specification, design, and testing of this conceptual construct,[…] If this is true, building software will always be hard. There is inherently no silver bullet.” – Frederick P. Brooks, Jr. 1987
Communication / Requirements / Writing
Posted on:
Logical Requirements
We talk about characteristics of good requirements, including completeness, correctness, and ambiguity. But how do we assure that our requirements are complete, correct, and unambiguous? Simple, Captain, with logic.
Foundation series / Requirements / Requirements gathering
Posted on:
Foundation Series: JAD Sessions
JAD is an acronym that stands for Joint Application Design. JAD sessions are collaborative meetings where the customers meet with developers to determine what the product needs to be or do.
Process Improvement / Requirements / Software development
Posted on:
Skip The Requirements, Empower The Developers
Enough of the debates about requirements and what we call them. Why don’t we just hire great developers and empower them to work directly with the customers?
Requirements
Posted on:
Abstraction And “Requirements”
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.