When starting a project, writing good requirements are important. The requirements are uses throughout the project and can set you up for success. After reading three different articles about good requirements, I found they match similar ideas I have based off my previous work experience. Two main ideas which I find similar are following a structure and confirmation.
Jim Heumann writes how developers can apply developer concepts to writing requirements. Developers need to structure their code to keep it readable and easy to maintain. The same can be used for requirements. As stated earlier requirements are used through the entire project. This means requirements need to be able to be edited multiple times in the beginning without repeating requirements. By organizing the requirements, you can ensure the requirements are consistent to meet the characteristics of good requirements from Karl Wiegers.
Confirmation is very important when moving requirements through a project. I have seen in my experience we read requirements from our own point of view. Sometimes we don’t stop to think how could others interpret these requirements. Thomas Hathaway discusses confirmation and prioritization. Part of confirming requirements must be assigning a priority to them. If a developer looks at a requirement, they might interpret a lower priority than the business usually because they don’t understanding the business. I have found the best way to accomplish this would be for the developers, requirement writers, and the business to discuss the requirements together. This allows for many of the different interpretations to be consolidated before working on designing the system. All of this work on the requirements early on prevents later rework because of misinterpretations of the requirements.
Writing good requirements is a lot like writing good code, Jim Heuman