Once you have selected the ERP platform that you think can best fit for your company, it would be good for the client to prepare a document as well explained as possible, a requirements document. In which he details what he expects him to do the ERP or management software,he basically writes “a letter to the magi”. Including each department of the company (Purchasing, Sales, Commercial, Production, Quality, HR, etc.).
Depending on the partner, this requirements document is made more in detail or more generic. From here the implementation partner performs an analysis of these requirements to begin the management of the project. Below we will explain what we consider that a good analysis of requirements by the partner should be based.
What do we consider a bad requirements analysis?
Analyses with too much detail are trap analyses. In this case basically the partner details with extreme accuracy what the software is going to do, detailing the tables and fields of the database. The relationships between tables and detailing the screens.
They are analyses that take a long time to write, sometimes up to a year. They have many pages, reaching more than 1,000 on many occasions. In terms of image, it looks very good and it is very professional. But in our opinion they are trap analysis. They are done this way because in time of implementation or deliveries if we have ignored something, some field or some development will come to us with the typical phrase. “This is not in the analysis we did, to do it you will have to pay an extra.” Beware of requirements trap analysis.
What do we consider a good requirements analysis?
The analyses must be generic without reaching excess detail on the part of both, specifying what we want the software to do, including printed documents that have paper in the circuit and we can even help ourselves with some screenshot to clarify what processes we want the software to do.
When it is validated by both parties, we proceed to program and deliver (we will explain in future blogs). The client reviews the development and proposes its improvements. On the part of the implementer, the delivery is scheduled and made again. For the second time the client checks again and indicates new improvements or changes. (sometimes this second review is not necessary). 2 revisions should be enough to close the development. Working in this way we will not find surprises or the phrase “this was not in the analysis”, since the analysis has been written at a generic level.