What Requirements to Specify for COTS and SaaS Projects

The number Commercial-off-the-shelf (COTS) software options have increased exponentially in recent years. A sister of COTS, the “SaaS” or Software-as-a-Service where the commercial solutions are made available over the web, with no hosting or installation required, has made these solutions even easier to implement technically.

Here are a few of the more common COTS and SaaS applications that business analysts work with for their organizations include:

  • Salesforce.com
  • ServiceNow
  • Microsoft Sharepoint
  • SAP
  • QuickBooks

But this is just scratching the surface. In a world where the selection of tools is virtually endless and can be configured to meet any business need, where does business  analysis fit?

First, we need to come to terms with the fact that our organizations will be doing less and less custom software development.  That means instead of building custom software from scratch, we will be finding tools and customizing them.  The availability and flexibility of tools requires us to adapt our requirements process.

COTS Requirements: What Business-Analysis-As-Usual Activities Remain Relevant?

A project is still a project. Whether you are building custom code or buying an off-the-shelf solution, BA activities remain relevant. Let’s take a quick look at them.

Understanding the business problem.  As business analysts we need to understand what problem the business is trying to solve. Nothing really changes here, except that in the process of seeing the available tools, we might uncover more problems because the solutions look so simple and are readily available. The new challenge we will face is with the variety of options available, business users will likely come to you having done their own research and know what tool they want before they even initiate a project to implement it.

Understanding the business process. As part of understanding the business problem, you’ll need to understand how the business process works today (or the “as is” business process). As part of helping the business embrace the solution, you’ll need define how it will work in the future (or the “to be” business process).

Scoping the solution.  Helping the business uncover what the scope of the solution needs to be.

  • What features do we need?
  • What package should we purchase?
  • How much back data will we migrate?
  • What are the integration points with our existing systems?

Whether you are building a new solution or integrating an pre-existing one into your business, these types of questions need to be answered. And to get to the right level of detail, you’ll typically create use cases (or user stories) and a variety of data models.

A clear business process framework. Just like with any other type of project, having a clear business analysis process framework, or way of approaching a project and taking it from beginning to end, is absolutely essential.

(To take a deeper dive into the BA process framework, check out our free Quick Start to Success workshop.)

COTS Requirements: What Requirements Documents are Unnecessary?

There is one primary requirements specification that doesn’t make a lot of sense when implementing a commercial-off-the-shelf solution.

Detailed ready-to-build specifications. The system is already built so detailed functional requirements will be less important than customization requirements, business rules, and data migration requirements.

COTS Requirements: What Requirements Deliverables Become Even More Important?

Understanding the business process. With new flexibility, it means that we’re more likely to make the software work around the business process rather than the business work around the software. So that means business analysts will find themselves digging even deeper into the business process than previously, ensuring the new tools are appropriately configured or customized to meet the business needs.

Building enterprise analysis into our requirements efforts and putting in place a solid business case. In a world with so many ready-to-go solutions, the last thing we want to do is get too far into our requirements before we identify our solution approach.

Software and vendor selection criteria. Each time I look for a new tool, there are typically 5-10 good options in about the same price range. How do I make the best possible decision? As business analysts, we can help our business and IT teams make informed decisions and select better vendors  and software applications to invest in.

Personally, I see some great opportunities here for business analysts.  I think the best thing we can do as in this increasingly COTS environment is position ourselves to be involved in the selection and evaluation. If we are only involved after all the decisions have been made, it’s likely to limit our roles. But if we’re involved upfront, during the selection process, we’ll have the opportunity to dig further into the problem space and business process.

>>Improve Your Requirements Writing Skills

When you join The Business Analyst Blueprint® certification program, you’ll learn all 12 of the industry-standard techniques and the business analysis process framework – to build your confidence in the best practices of business analysis.

You’ll create validated work samples and be a credentialed business analyst as a recipient of the Applied Certification in Business Analysis™ (ACBA).

>> Click here for more information about The Blueprint <<

10 thoughts on “What Requirements to Specify for COTS and SaaS Projects”

  1. Good article and interesting discussion.

    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.

  2. I agree with everyone — I work in the healthcare industry and there is significant use of COTS (best of breed) with heavy use of interfaces (HL7). Business requirements are needed for documenting the business problem and vendor/system selection. Beyond that it’s tough to write a true functional specification.

    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.

  3. I found this article very useful and seems relevant with what I struggle with as a Requirements Analyst with COTS products.

    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….?

  4. This is a very interesting article on how the role of BAs has changed. I have spents > 10 years in the cutsom software building world (Music industry) where not many off-the-shelf software solutions were available. There was a lot of importance around understanding the business and developing detailed requirements that could be transformed into solutions. Recently, I have joined a “software company” supporting Finance where the projects are around vendor evaluation to see which software solutionbest fits the business needs. The benefit of this is definitely having the capability to implement best practices that have been utilized while building a solution that is available (COTS) or “SaaS.”

  5. Dave has pretty much said it. Generalizing, I’d say that it’s most important to detail the uses (print this data) rather than the functions (capture this data). Getting the use right requires the function, and leaving that to the vendor leaves room for creative solutions you may not have considered.

    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.

  6. Yes, that is what I am saying.

    But, in addition, even for items that are originally identified as not being gaps that require customization based on the vendor’s understanding of the requirements, I find it best to add as many details as possible about those requirements to help ensure the correct understanding.

    A simple real-life example from the insurance world … original requirement reads “The system will capture the time of inception on a new business application.” The vendor assumes that it only means the capture of an additional data element which can be configured in their system. But, later in design when we explain that this piece of data must be sent to print on the application and the issued policy, they might then identify it as a gap and start the change control process (or it gets deferred to a future release). If we had added some details around that original requirement to clarify that the “inception time” must be printed, this situation could be avoided.

  7. Hi Marc and Dave,

    I’d be interested to hear a bit more about the types of details you document. What I was thinking is that, compared to custom software development, you don’t document each and every detail that it would take to build the COTS from scratch. That would be redundant because those requirements are already built. Perfectly agreed that for customizations or transition requirements, detailed documentation would still be necessary.

    Is that also what you are both saying?


  8. I agree with Marc … the key thing to remember is that the vendor may think they understand the requirements but really don’t. They may be clear and obvious to you and everyone else in your organization but it can be interpreted differently by the vendor.

    I believe that detailed requirements are definitely needed for those items that can possibly be misinterpreted and, of course, the gaps between the requirements and the vendor solution that result in customization. A detailed gap analysis is crucial to properly identify these items during the requirements phase before the change control process begins.

  9. The biggest issue is the amount and precision of detail required. With an in-house project, you can catch and correct requirements weaknesses as you go. When you contract for development or a service, you don’t have that luxury. You can’t assume that the vendor will point out ambiguities or omissions in the requirements. A look at how many ERP vendors are being sued by their clients brings that point home.

    I reserve a distinction between “requirements” and “specifications”. They may be structured alike, but the specification has to be both clear and very complete; it will be much thicker and somewhat legalese. This is the kind of thing I approach with dispassionate paranoia; having once been royally burned by too-casual a relationship with the contractor, it ain’t gonna happen again.

  10. Pingback: Tweets that mention What’s different about requirements for a COTS or Saas? -- Topsy.com

Sign up for weekly updates and access to the FREE Quick Start to Success workshop:

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)

Laura Brandenburg

Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.

Scroll to Top