Who is responsible for the requirements?

Question

I am a Business Analyst for a company whom have an in house development team and an in house administration system. We also have an off the shelf system including service contract that directly works with the in house administration system.

The issue is that I know I am responsible for the in house system requirements but they overlap into the requirements for the off the shelf system. Now is it my responsibility to write technical requirements for their system or is it the BA of the off the shelf company who should pick this up?

Answer 1

Bottom line is: as one of the (or the only?) Business Analyst(s) for your company, you are responsible for reviewing your business process, technical, resource, and product needs. So if you have requirements that overlap both in-house and off-the-shelf systems, you still have to capture those requirements.

In many organizations, a systems engineering or administration group would then be responsible for deciding if your requirement is satisfied by an in-house application or an off-the-shelf application. A natural conversation would involve you in those discussions with the systems people and you could (should!) modify your original requirements to clarify any specific points.

If there is another individual who is responsible for the off-the-shelf applications and requirements, then you should still write your own requirement but coordinate with that other person.

Generally speaking, you are writing requirements for the overall "business". It's up to the systems admins or engineers to decide how to satisfy that requirement.

The other half of your question refers to the BA in the company making the off-the-shelf (OTS) product. Don't worry about their requirement. You only need to make the requirement clear from your company's point of view. The OTS company will accept your requirement as a customer input, then will create their own internal derived requirements from that (and hopefully modify their OTS product to support your need).

Answer 2

You should write the requirements of your company.

They are then partly fulfilled by an off the shelf product and partly fulfilled by an in house system.

In chooseing the best off the shelf system you use the total list of requirements and compare with the features lists of the various options.

The remaining requirements you give to your in house team to implement features which fulfill them

Answer 3

The answer to this is "it depends".

It depends on the nature of the contract and engagement your company has with the supplier of the off-the-shelf system. Only by looking at that relationship can you answer the question categorically for your organisation.

This is because it can work in many ways. Usually the supplier organisation will want to create the change specifications because that is an income stream for them (i.e. they will bill their client for the effort and make a profit on the income). In addition, by taking responsibility for writing the specs they are taking control of the change pipeline and, unfortunately, can manipulate that workstream in terms of scope and timing to their own advantage. Yes you may consider that unethical from a user point of view, but have no doubts that it does go on.

So the client may want to write the specs specifically to avoid the above. However, be aware that you, as the user/client-side analyst, should only ever go as far as Business Requirements and Functional Requirements specifications because you are not best placed to write Technical Specifications for a third-party product. If the supplier actually allows you to do this, and accepts what you specify on a fixed-price contract, then it's a win for you as you have taken some control over the product (which is why the supplier should never want you to do it!).

Be very wary of being "allowed" to write the technical specs for a third party system if the contract is a Time and Materials (i.e. Cost plus) basis as this could prove very lucrative for the supplier. Common sense should (but rarely does) prevail.