Writing software requirements should be easy, right? Right? Of course we know exactly what we need and can tell you exactly what the software should do.
Unfortunately, it's not always so easy. Writing software requirements well takes detailed, deep thought about business requirements. It also takes clear communication between the people who will use the software and the people who will write it.
It isn't always easy to translate between business-speak or industry-speak and developer-speak. This can cause costly confusion. Fortunately, there is a language called Gherkin to help bridge the gap.
So what makes a good set of software requirements, and how can we develop those requirements?