As you can tell from the previous discussion, the SRS performs basically the same function as an RFP. In other words, it is a product or a deliverable. As such, it is only reasonable that the customer pay for it. Once they have that specification, they could present it to competing software development firms.
The successful custom software development companies that I worked for were able to get their customers to understand this concept. The unsuccessful companies, on the other hand, were not able to get their customers to understand this paradigm.
Sophisticated customers who are experienced with developing custom applications will have no problem understanding the need for a good definition of the requirements for the project before the work is done.
Less sophisticated customers may not understand how important such a detailed definition for the solution to be delivered. If you are dealing with such a customer my recommendation is that you try to find someone on the customer’s staff that has a technical background. If such a person exists, I would use that person as an ally to talk to the main customer about the need for detailed description.
If you cannot find such an ally, I recommend a face-to-face meeting which includes a presentation of standard project management methodologies – all of which emphasize how important it is to define the requirements.
If the customer is still unconvinced, you should seriously consider dropping the project. I have worked with such customers and they are the ones who continuously ask for and expect without charge “scope creep” enhancements. Such customers are difficult to manage and are difficult to work with profitably.
However, regardless of whether or not you are able to convince your customers to pay for the SRS, that specification should have these characteristics:
1. The SRS should be well organized with numbered sections and/or paragraph numbers. This makes it much easier to go immediately to the proper location in the specification when you are reviewing it with the customer. This also makes it easier to relate the contents of the SRS with the detailed project plan.
2. There should be a new version number assigned to every copy of the SRS that is viewed by the customer, beginning with version 1.0. You should always have the technical staff review the SRS before it is sent to the customer and it makes sense to assign version numbers to these copies as well as to the copy sent to the customer. But the very first version that the customer sees should always be ‘1.0’. If some other number is used the customer will be confused. I recommend that internally reviewed copies of the SRS begin with version numbers such as ‘0.8’ or ‘0.9’.
3. You should use active verbs when writing the spec. You should say, “The system will do
You should put into the SRS mock-ups of the Graphical User Interface (GUI) screens that will be used when the solution is implemented. Particularly when dealing with unsophisticated customers, this is truly a case where a picture is worth a thousand words.
4. Show as much detail as possible. For example, if the solution is to include reports, you should document the complete specifications for the reports.
To further elaborate on this detail, there are three pieces of information that need to be specified for any report.
First, each report has some selection criteria which is generally entered by the operator. Often that criterion includes a date range. Or it may include a customer code that allows the report to be run for a single customer (or facility, or vendor, or user, etc.) This is where the GUI interface mock-up in the SRS is most valuable.
Second, the specification for the report should document how the data is to be sorted. This is often independent of the selection criteria but on occasion the selection criterion allows the operator to select how the information to be included in the report is to be sorted. For example, in an Aging Report for an Accounts Receivable application you may wish to see all open invoices that are more than 30 days past their billing date. That is the data that is to be selected for inclusion in the report. But once that data is selected, it is normally grouped by customer so that all of the open invoices for each customer are listed together.
Third, the specification for each report should show the detailed information to be shown for each record in the report. Continuing with the example of an Aging Report, the record for each open invoice should include at a minimum the invoice number, billing date and amount. Each group of invoices for a particular customer should show contact information for that customer (generally someone in the Accounts Receivable department who can talk about any open invoices).
Such detail will allow the customer to understand how to use the report and it will also tell the programmer how to develop the code for the report.
Version Control
The latest version of the SRS should always be an accurate description of the current software that has been delivered to the customer. Whenever a modification is made to the software that reflects a functional change that represents a new capability the SRS should be updated to reflect that modification.
Examples:
1. A new report is added
2. A GUI is modified (a screenshot of the new GUI should be included in the modified specification)
3. The software is updated to work on a new version of an operating system.
The version number of the SRS should be modified with each such change. There should be a table within the SRS, preferably towards the front of the document that shows a history of changes. Each row in that table should include: the new version number, the date the change was made, who updated the SRS (it should be the project manager at the time) and a brief description of the change(s).
Some people, particularly attorneys in my own experience, like to have changes tracked within the document. I’m not a fan of doing this. I believe that the document becomes almost unreadable eventually.
Instead, the software vendor should use the same version control software that they are using for the source code itself. The SRS should be included in that database. That version control software will allow the latest version, as well as any of the earlier versions, of the specification to be easily retrieved.
No comments:
Post a Comment