Should we buy this application, or build it in house? How should we make that decision today?
Interaction design / Requirements / Requirements Models / Use Cases
Posted on:
Actor Hierarchies And Then Some
Actor Hierarchies give us an overview of the people who will interact with the system. We can extend this model to provide a visual indication of how use cases are distributed through the organization. Further, we can leverage a hierarchy to show how use cases are rolled out to the users – a targeted communication for our stakeholders.
Agile / Requirements Models / Use Cases
Posted on:
Incremental Delivery and Evolving Use Cases
Amazon.com started by selling books. Their initial use case was “Sell books online.” The vision was always “Sell everything” – hence the name. But they started with a simple use case and evolved it.
Requirements / Requirements gathering / Software development
Posted on:
Prototype Fidelity
Prototyping is invaluable for getting feedback on a design. It is also great for getting validation of requirements. It can even be used as a means to document the requirements. What level of fidelity should be used when getting feedback? Jan Miksovsky provides some guidance from the real world.
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?