One process of software development that we should never compromise on is that of requirements engineering. While lengthy requirements process can slow development down, the truth is in the long term poor requirements development actually costs more. It’s vital to ensure that teams make every effort to understand the underlying requirements of their product and ensure that it is written and documented in a way that is unambiguous and easy to understand for future maintenance.
Requirements help in two ways, the first is the obvious benefit to the quality of the product. If everyone in the team understands the system well and the expectations of their part in the great system, it’s likely most system defects can be prevented in the product. Most people understand this, but don’t invest the time because they feel the time it takes to develop decent and proper requirements will hamper their ability to deliver quickly. Ironic, if you consider that the second benefit good requirements engineering brings is that of improved efficiency.
While you could argue that your team is refining the requirement over time – a lot of development effort is getting wasted on work not being spent on the right thing. You can either throw this time away and consider it as part of your agile process or you can actually see this as a time benefit and invest a little more time refining your requirement needs upfront to prevent wasted effort. It might not seem like it adds up too much if you’re releasing weekly or daily, but it does all add up.
This might not be possible with every user story or in POC work, but there should still be decent acceptance criteria for information available before work starts. A set of completion criteria should then also be set for what the requirements need to look like before any software is released. The main reason for this last part is software maintenance. Whether you release updates on monthly/weekly or even daily basis, your requirements should also be the go to point for what any function is supposed to do. As amendments get made, these requirements need to get updated and tests maintained according to the purpose of the requirements. Requirements that are not well written create long term maintenance issues as often the people who maintain the software are not always the same people that wrote it.
So, what makes a good requirement? Well the following below guidelines will go a long helping you identify if your requirements are at a place where they can be deemed complete. I would like to add an important caveat here that while a user story doesn't always equal a requirement, a product can function without user stories, but not without requirements. User stories should always point to key requirements for further clarity if they can't contain the info themselves. Don't use Agile or DevOps as an excuse for throwing away detailed requirements:
If it is simple to understand, properly and uniquely defined, prioritized and within scope of the product/project
Is the requirement measurable, specific and non-contradictory or ambiguous?
Is there enough information specified in the requirement to write a full test case?
Is there enough detail to enable you to write a test case with steps based on the requirement?
Is the expected behaviour described for all error conditions?
If you can't get any of these questions answered, then perhaps your software is not as ready for release or testing as you think it is.