As a systems engineer[1], I really appreciate that the author mentioned requirement prioritisation. Many requirements are contradictory, and it's all too easy a

As a systems engineer[1], I really appreciate that the author mentioned requirement prioritisation. Many requirements are contradictory, and it's all too easy and common for people to avoid conflict and just agree to a cop-out set of requirements such as the system being all of: feature packed, simple to use, able to be designed and implemented on a tight schedule, error free/secure, of high performance, etc. There's an entire comedy movie, Pentagon Wars[2], dedicated to this phenomenon. There are a few other aspects of bad requirements that are particularly common: * Requirements specifications created in absence of a software architecture. You end up with 2000 requirements all starting "SoftwareX shall ..." and then software developers assigned to individual components of the software are left guessing as to whether each requirement applies to their component. It's also much harder to make decisions like "that file export component of our software with 5 requirements... let's just use libxyz as-is rather than reinvent the wheel" vs. the same decision when considering 2000 requirements. * Requirements without justification. The reason why a requirement exists is extremely important. If you want to change the requirement or have failed to meet it, you want to know the consequence and who you'd reach out to in order to advise of the change. * Non verifiable requirements. Write down a few paragraphs of a test outline when writing requirements, not after the system is already designed (it's too late then). A bad requirement such as "SoftwareX shall have a simple user interface that is easy for newcomers to use" is meaningless during design and development and will get ignored. The threat of a planned verification method being "Bring 10 people of average computer literacy in a room and ask them without having used SoftwareX before to complete the following 10 tasks with SoftwareX in 1 hour. Pass if the average task completion rate is 80% or higher." will get designers and developers thinking. * Not using exemplars, images, videos, etc in requirements. Good requirements may be as simple as observing that SoftwareY is pretty good for certain aspects, and should be a source of inspiration. Or "Watch this video of SoftwareZ in action, this is what we want our software to do as well." [1] https://en.wikipedia.org/wiki/Systems_engineering https://en.wikipedia.org/wiki/Systems_engineering [2] https://en.wikipedia.org/wiki/The_Pentagon_Wars https://en.wikipedia.org/wiki/The_Pentagon_Wars