… Quick tangent. What’s with the covers of software training books?…..

Regardless if it’s with freelance development for a small client, or product development at a large company. Ensuring that everyone is on the same page is critical. This takes various forms depending on the project. From character sheets & other types of concept art to mood boards & HTML wireframes. Throughout my career, either in an office or freelancing, I’ve worked with various types of preproduction assets. One of these is the Software Requirments Specification or SRS for short plays an important role. In a different pipeline, it may be called by different terms such as the design document. What goes in the SRS can vary but overall it tends to focus on the software non-functional & functional requirements. While the document may also discuss architecture, UI/UX design, color theme, etc. It normally only does in broad brush strokes and will reference those external documents. In the end, the SRS is all about functional & non-functional requirements.

Non-Functional requirements (NFR) from a high level can be described as what a system is”to be“. NFR tend to avoid specific functionality, an example of an NFR might be that a user interface should be clean and easy to read on a specific or multiple forms factors. For myself, the NFR tends to be the high-level description of a feature set. I then break that feature set done into a series of functional requirements that aim to fulfill that the goals laid out in the NFR.

A Functional requirement (FR) from a high level can be described as what a system is supposed “to do“. Going back to the UI example from above. A functional requirement might describe the UI breakpoints for different screen resolutions to address readability. Or how a submitted password will be evaluated for spaces, special characters, length, etc, before being submitted to the backend for processing.

From my experience, the client understands the software from the NFR perspective. But the FR’s allow the developer to understand the scope of a feature and a way for both the client & developer to verify that a feature set is complete. This document helps prevent scope creep, allows for clear review goals, & acts as a communication tool between the developers and all the other stakeholders involved with the project.