I was involved in a COTS implementation recently. The system had over 10,000 lines of configurations driving the system behaviour. Our internal testers required my to write out full functional requirements for the whole system in order to test against. As above, the requirements as a whole were not used to build the system from scratch as it was build by the vendor a few years ago. If I didn’t document every single little piece of functionality in the requirements it was deemed a requirements defect. Going through tens of thousands of lines of system configuration to determine what options we had to configure in order to know what to workshop with stakeholders was absolutely impossible. I started the project in 2010 and am still working on it in 2013!
Writing functional requirements for new modules that were being designed for us was ok, but trying to write full functional requirements for the pre-built system was insane.

What I do is document whatever I can with regard to business rules, configuration settings, data mapping, user roles/levels (RBAC), etc., and have a referenced documents section including the interface team documentation, the vendor implementation team’s documentation, and the data teams documentation. [Of course, that’s assuming all groups have completed the documentation.]

Ultimately, my main goal is to sufficiently document the system so that when I roll off the project, the remaining team has what they need to successfully implement and support the system.

I’m always interested in learning how I can be better.

Here’s the scenario – we have an existing COTS product with an RBL that is established. A change request is received, example of a user request for the application – Create a warning banner in the public area. Business statement – Add a banner to the public area and sub-folders to alert users that they are in a public area.

It was indicated that we can meet the user request w/ existing functionality. So I proceeded to check for an existing reqt to see if one was already written for this type of requested capability/function, there wasn’t one. I indicated that a new reqt needs to be written. Some team members feel that it is not necessary to write a reqt statement when the module/functionality already exists, their arguement that it is a ‘out of the box’ functionality that the COTS product offers.

I feel that when a new user requested capablility of an existing system is received, a formal reqt statement should be written and add to the RBL – thus documenting the user request.

So the question is – to write a requirement or not write a requirement….?

There’s a connection here to the definition of a use case, which I would hope is what you’re using: Post-conditions are a waste of space. Every post-condition has to be a precondition to a use case or there would be no way to know whether the post-condition was satisfied, nor would anyone care if it weren’t.

Making sure that every use case is detailed so that every intended use is covered is what I was talking about. If the vendor delivers on every use case, and you haven’t missed any, the rest is immaterial.

There are two things not to forget that often are: use case metrics, and cases for ‘grey’ actors like auditors, maintainers and backup systems.

The only other issue is that in-house time and cost tend to be loose and we expect missed deadlines. When you outsource, these have to be much more realistic with much higher odds of success. Estimates must be much farther-ranging in their search for input factors.