1. Desired and undesired behaviors must be documented as requirements.
2. Requirements must be versioned in tandem with source code, build artifacts and test results.
3. Requirements must be tested, and results recorded, before each delivery.
4. Requirements must be monitored, and results recorded, after delivery.

FAQ:

Q:  Why?
A:  Following these practices will increase accountability in all stakeholders, help quantify work efforts, reveal complexity that would be otherwise missed and provide living documentation for your systems.

Q:  Do all requirements have to be defined before development?
A:  Not necessarily, that might be a waste. However, it is also not the opposite extreme. When in doubt, be explicit. The idea is to gradually grow the detail of the requirements as new features are requested with each version. Keeping versions small and atomic is a best practice.

Q:  What happens when requirements change?
A:  Work needs to be done to analyze the implications of the change throughout the system. The discipline of documenting and versioning the requirements makes this process explicit and the appropriate parties accountable. If requirements are organized to mirror the code, and the code is properly decoupled, this should be as simple as replacing a slice of requirements/source code.

Q:  What project management tool should I use for this?
A:  Businesses don't care about epics, user stories, kanbans or tasks and how you can organize them into expanding lists or burndown charts. Frankly, if it can't hook into your code, it's almost pointless. Specification by example using version controlled files is ideal. BDD feature files are best because there are well established ways to automatically verify the status of the requirement. That said, any tools that can help with the process of keeping the requirements in sync with the tests and code are useful. Event Modeling is a great way to capture requirements visually, just don't forget the feature files.

Q: Writing all these requirements sounds time consuming, it's easier to just make a code change and move on!
A: Well, changing or adding a requirement is a signal to change the behavior of the system. This has implications and should be recorded and versioned to ensure accountability and documentation of your system.

That's my perspective

Software development never seems to be measured well. Why? Every other industry seems to have figured it out. I think a big reason is that it's so hard to measure the process, let alone define metrics for measuring the quality of said process. This year, I'm devoting significant effort to building a foundation for measuring both productivity and quality, so I can reduce project risk for all stakeholders. Look forward to future updates about improvements to requirements specification and design, better auditability of systems, squashing bugs before they happen with functional programming, and fixed price projects.

Happy new year!