In the past, I've put a lot of effort into defining all or at least the majority of a given system's requirements up-front. The reason for this is because I've worked in fairly process-heavy environments. While I continue to see the value of this effort, it simply isn't feasible in most environments. Actually, I beg the question: is it feasible in any environment? Most developers find the requirements definition process a pain and question its value; however, experienced engineers recognize the value and strive to find a way to work it into the software engineering process. Unfortunately, this doesn't happen enough. For most small systems, this may not pose an issue; however, once these systems grow to a significant team size or fall victim to enough attrition, new team members start to feel the pain of this missing documentation. New team members aren't the only ones who feel the pain of limited documentation. As anyone who's witnessed one of the many failed contracting efforts in the software or construction industry can attest to, faulty requirements definition can be the death of any project. For this reason, I hope more developers will find the value of requirements and seek to develop them for their own projects. What is the right way, tho? How should we solidify the abstract thoughts that form the projects we engage in? Tyner Blain does a good job of describing an agile approach to requirements definition. I hope more take this to heart. Due to a change in scenery over the past year, agility has been more important than process. The change in viewpoint has been interesting and ultimately driven me to the same opinion Tyner has, where a full definition is desired, but is easier to swallow one bite at a time.