Writing Effective Use Cases

What Hacker News says

1. gfodyOct 2020
   Writing Effective Use Cases by Alistair Cockburn [1] is a pretty solid style guide for technical writing.

   [1] https://www.amazon.com/Writing-Effective-Cases-Alistair-Cock...

   thread
2. vicentereigMar 2016
   If they fall into the formal specification category, I've found Writing Effective Use Cases by Alistair Cockburn to be very helpful.
   thread
3. shaileshJul 2013
   Assuming that you've found an interesting business problem to solve:

   1. Write a list of desired features. Next, prioritize those features.

   2. Write brief functional specifications for features of highest priority.

   3. Decide on how you want to use the software stacks for different tiers, e.g.

      Browser - Bootstrap or Zurb, AngularJS
   
      Server stack - node.js, Ruby, Python
   
      Database - MySQL, Postgres
   
      These examples are sketchy, just to give a feel of things.
   

   4. Research any libraries that automatically handle common functional units, such as authentication and authorization, analytics et al.

   5. Some functional units might be implemented more easily by gluing together services. E.g. using New Relic for deep application monitoring, Twilio for cloud communications.

   6. Design and implement all functional units.

   7. Profit!

   8. Write a Thank you HN note, :)

   One should do this exercise for a "toy" application like "To Do List" first. It helps remarkably when we go about building serious stuff.

   Books: 1. Code Complete by Steve McConnell - worth at least skimming it.

   2. Design Patterns by Erich Gamma et al http://www.c2.com/cgi/wiki?DesignPatterns

   Also, definitely have a look at Peter Norvig's slides: http://norvig.com/design-patterns

   3. About Face 3: The Essentials of Interaction Design by Alan Cooper

   4. Writing Effective Use Cases by Alistair Cockburn

   Websites: 1. Obviously, HN, :)

   2. http://highscalability.com/

   It may look like a huge undertaking, but it really isn't. A quote from Michael Abrash seems appropriate here, "Winning a hard race prepares us for the next harder one."

   This is just top of the mind; hope this helps.

   Good luck.

   Edit: formatting.

   Show morethread
4. ericHosickFeb 2011
   First, it's great to see such a wonderfully thought out article on the selling of programming tools to programmers. I've been doing this stuff for like 25 years now and I've seen a lot of fads and tools come and go.

   I would like to try and not group TDD and BDD as similar things because in my eye they really aren't: they both provide very different approaches to solving a problem. If you were to simply cover TDD then I would agree with you that it is something that focuses on programming and the programmer and operates within that area of software engineering.

   BDD, on the other hand, really has little to do with telling a programmer how to test their code or even how to program. About the only thing BDD "requires" a programmer to do is implement the Behavior described. There are a lot of ways to do this, but BDD adds a lot of other cool things too (like you can verify the requirements provided too).

   So, when you mention that "The 'good' programmers all do things this certain way" and see BDD as a tool forcing that. Well, I don't think that is the case.

   The funny thing is that BDD isn't even a new thing because it relies on scenarios. It is very similar to Use Cases with one minor, but important, difference: there was no standardization on Use Cases (Writing Effective Use Cases by Alistair Cockburn is a great book). Cockburn left the way scenarios are written open to the engineers whereas BDD provides a simple language, Gherkin, that can be used consistently across different tools (Cucumber, Behat, Specflow are a few examples).

   So, from that aspect, this isn't some new "fad" that is being sold to developers. It is just a few changes to a well known tool: Use Case.

   Show morethread
5. waldopatFeb 2026
   You don't need spec kit or humanlayer per se, though they are good reference points for starting out, but you do need your own CLAUDE/AGENTS, README, ARCHITECTURE, SDRs, policies, research docs and planning docs all nicely organized in files and folders to work well with AI agents.

   Particularly in a brownfield development context, using AI to research issues, gaps, bugs, tech debt, reusable patterns etc. as research files is really useful. I find the sweet spot is ~750 lines for each file. Planning files can max out at 1,500 lines if needed or otherwise broken up into individual phases. You can always ask an LLM to create a starter set of docs to get you going and then maintain as you go along.

   For the management nerds, none of this is new. See: Writing Effective Use Cases by Alistair Cockburn and Agile Specification-Driven Development by Ostroff, Makalsky and Paige. The fundamentals remain the same and I'd say become even more important in a brownfield context with a high degree of tech debt or complexity. Greenfield is a different story.

   What's important with spec driven development is that the LLMs dramatically reduce the cost of both good documentation and good technical specifications. Once you have a good plan and good references, you can build anything with a high degree of accuracy.

   I'd add caution about drift. The more documentation you shove into the context, the worse things can get. You can also create a beautiful and perfect functional spec that becomes a swiss cheese of gaps when you create your technical implementation plan. Always check and use different AI models adversarially to ensure you are actually getting the plan you want. Usually ChatGPT can spot Claude's blind spots, for example. And always test manually.

   Show morethread
6. payrollengineAug 2023
   Gathering user requirements using use cases is a proven technique that Alistair Cockburn described in detail in his book Writing Effective Use Cases back in 2000. The use cases are developed during requirements engineering with the users and serve as a guide for the development of the solution. In practice, knowledge transfer from business to engineering is often difficult because of the different ways in which people work...
   Show morethread