While studying IT just over twenty years ago, only one way, the waterfall model, was taught to implement software projects. Since then, many new ways have come along, Scrum and Kanban to name but a few. Every way/process sounds perfect on paper and, of course, aims for the success of the software project and meeting the customer needs.

During my career, I've noticed that one process is no better than another. The processes are usually made for perfect people and so far I haven't met the perfect person. Much depends on the implementation of the project. A project has a better chance of succeeding if the goal of the project is clear. By clear, I mean something other than "we're implementing a new generation of app X ...".  

Regardless of the project model, the goal of a project is usually described through requirements. Some models attempt to fully describe the requirements before the implementation and testing phases. In some other models, the requirements are described in general terms and refined as the project progresses. In quite a few projects, this is done by software developers. There is nothing wrong with this in itself, but software developers are not experts in the problem area and often lack the experience that those working in the field have gained over the years.

The above could easily be simplified, so that the experts in the domain must be in the project and then the job will work. This is both right and wrong. Being involved is not an intent value, but it is even more important to bring the information they have to the knowledge and understanding of software developers. How this step is implemented pretty much dictates whether or not a project has a chance of success. In addition, another important prerequisite for success is that domain experts are available during the project. Em. in my experience, two things are more important than how experienced IT experts are in the project. Expertise is needed, but even more needs to be understood by the customer.

Thanks for reading the text all the way out here. Here you can read how to approach requirement specification.