[chetatkinsdiet]

If this is how you're defining requirements for software or new product creation you're doing it wrong.

The goal should never be to describe every single outcome or scenario- the goal should be to build understanding between business/product/development team so that they understand the point of the work that the software replaces. It's no different with hardware or really any new product creation. The goal is to create a conversation that gets us to solving the problem- when the spec gets to covering all cases the chances we get this wrong and stray from solving the actual problem goes up massively.

[Idontagree]

The article is making a point about understanding or what happens in a conversation for something like requirements, neither you nor him provided an exact answer as to how to define requirements, because it's something we havn't yet been able to automate.

Also it's starting a conversation about the very topic..

[chetatkinsdiet]

Good point- that all said, if we're automating requirements we're not solving the problems that tend to matter. The key to requirements building is in the process. The best process I've found so far is User Story Mapping (Jeff Patton has an amazing book on it)