With the vast majority of projects being delivered using pre-built solutions, it is important to understand how to specify requirements for COTS (commercial-off-the-shelf) software and SaaS (software-as-a-service) projects.
In this video, I am going to walk you through possible solutions, why we use them, and what kinds of requirements techniques are important for you as a business analyst.
Whether you are working with SAP, Microsoft SharePoint, Salesforce.com, Archer, Service Now, or another tool, these requirements will help you leverage these powerful tools to lead a successful project.
I’ll be sharing specific techniques for business process analysis, use cases, and data modeling, as well as success stories from our participants in The Business Analyst Blueprint training program.
COTS Requirements are Critical to Project Success
Hi, I’m Laura Brandenburg from Bridging The Gap, and today we’re going to talk about how to specify requirements for COTS and SaaS projects. COTS being commercial off the shelf, and SaaS being software as a service.
The vast majority of projects these days are delivered using some elements of these prebuilt solutions and it can feel like, well, do we really need requirements? Do we really need business analysts? I see a lot of projects going through our Blueprint program as well as through my work with my husband who implements Salesforce, and I can tell you that the projects that are successful still leverage business analysis capabilities and specific business analysis skills and techniques to make sure the requirements, the COTS requirements, are actually in place. Because many of these options are highly configurable and customizable. We need to do the work of figuring out even if we’re going to use the solution as is, how it fits within our business process and how we get data into it.
In this video, I’m going to walk you through what the solutions are, why we use them, and what kinds of requirements documentation are really important to pay attention to. It’s going to be a little bit of a longer video, most likely, because I want to walk you through these examples, give you some visuals so you can see what they are, as well as share some success stories from our program participants on how they’ve actually used these techniques on their projects, doing COTS and SaaS type requirements work.
Let me go ahead and share my slides.
COTS and SaaS Defined
Now, the first slide I want to bring, just to kind of revisit these actual definitions and make sure we’re clear. COTS is commercial off the shelf or a solution that’s usually deployed internally. It’s where you license a software or install a piece of software on either a centralized server within your organization or maybe on specific computers that employees are using.
SaaS is software as the service. That’s in the cloud. You are not actually hosting it as an organization. The service provider is hosting it. You might still have quite a few customization and configuration options depending on the solution.
Just to be really clear, the kinds of requirements you do from a process and functional requirements basis are very similar regardless of what kind of solution you’re using. You don’t really have to worry too much about that from a functional perspective as a BA.
Examples of COTS and SaaS Systems
What are some examples of these types of systems? We’ve got SAP, Microsoft SharePoint. Salesforce.com is huge. Lately, we’ve seen a ton of people come through the Blueprint program, The Business Analyst Blueprint – our business analyst training program –Â and work on Salesforce.com projects and go on to become experts in Salesforce business analysis. I’m going to share a couple of their stories.
And then Archer is another one. We’ve got document management tools. We’ve got ServiceNow. I’m going to share an example of that. All these types of tools are, software as a service or COTS tools, and they all need requirements if you’re going to implement them successfully at your company.
One example I want to give you from my career where this didn’t work, it actually was a project I came into after the fact as a business analyst, was a document management system. They had implemented this document management system, just kind of put it in place, and the whole goal of the project was to reduce the amount of paper used and make the process more efficient.
The users at this other location hadn’t been trained on how to use it. Their workflow hadn’t been well understood, so they were given a solution that they didn’t think worked for them. And instead of printing a document once and then kind of handing it around the office using their old workflow, they were actually printing it and uploading it multiple times at each step of the workflow. It was more labor intensive and used more paper. It was actually a negative return on investment. That’s what happens if you just put a tool in place and don’t actually understand what your business process is or how to use that tool successfully within your organization.
COTS Requirements: Business Process Analysis
Let’s just share the first technique that’s really critically important, and that’s a business process or a business process flow diagram.
You need to understand how the business works today. It might be using spreadsheets; it might be a paper process. It might be using another system that you’re migrating away. You need to understand how that process works so that you can understand how it’s going to work using your new system. There tends to be a lot of flexibility right in how those solutions work, so you really need to understand what that process is so you can figure out what you need to implement.
You also need to understand the constraints of the software so that sometimes it’s actually easier to adjust or tweak the business process versus adjust and tweak the software. It gives you a more maintainable system with more longevity. You might need to understand how the software works so that you can adjust the business process, and your to be process actually changes to work better with the software that you’re implementing. Either way, you just need to understand what that business process is. And a process flow diagram like this one is, is really important as well as a detailed process textual template.
I’ll leave a link below for our free template that you can use to articulate your business process. We also have videos on that technique as well as creating a process map like this one. There are other videos here that you can check out as well.
Now as an example of this, Manuel Ninapaitan was in QA work when he joined our Business Analyst Blueprint program. And he was specifically doing QA work using an application called Service Now. He took it upon himself, as part of understanding the business process, to really look for opportunities to be more efficient. He also updated his email signature to have the job title of Business Analyst. This is why I wanted to share this story with you. It might be intuitive of how it works for you as a business analyst. It also can work if you are not yet in a business analyst role because it will give you opportunities to understand the process, to ask questions about how the process works. Bring that business analysis mindset to whatever role you’re in, because often these solutions do get deployed without business analysis. We see a lot of Salesforce administrators, for this reason, becoming somewhat de facto business analyst because their role is to administrate the system, but in order to do that work, and in order to meet the user needs, they have to start understanding the business process so they can make the little tweaks that they’re able to make.
An admin role is a great way to progress into business analysis. A QA role is a great way to progress into business analysis, and you can do that starting by understanding and analyzing the business process. Again, if you haven’t already downloaded that template, it’ll help you get started with that technique.
Learn more about business process analysis in this video:
COTS Requirements: Use Cases
Now, another technique that’s really important is use cases, or some way of analyzing the functional software requirements. This is not required for every feature. You wouldn’t analyze the login use case for your COTS tool because most likely you are not going to be customizing that. And if you are, there’s got to be a really specific business case for that. You might want to push back on that one. But there are going to be features where there’s maybe a lot of configuration options, or you do need to customize it to work within your organization’s business model, and that’s where the functional requirements are. Here we have a sample use case as well as a wire frame are incredibly important.
Now, an example of this was Jamie Moore. She had a particularly challenging feature, and there were multiple ways it could be used or implemented using Salesforce. There were different ways that it could happen. And so she wrote a use case to decide to show how different areas of functionality could actually be leveraged in Salesforce to accomplish the end user objectives. She got this great feedback from a senior level stakeholder. I’ve never seen it done this way before. And it’s absolutely fantastic.
Wouldn’t you like to receive that kind of feedback? Often we can feel like we’re presenting tools that are new to our community and that maybe that can be a little scary. Like, oh, I don’t know. Nobody’s asking me to write a use case for this. But you can see the indecision and the uncertainty and the lack of clarity about what that feature’s actually supposed to do. There are tools in your toolbox that you can pull out to use in those scenarios. And a use case can be a great one if you’re trying to figure out how a feature could work or what you need to configure or customize and how that can work because it gets really specific about how the user interacts with the system and what the system needs to do to support that business user.
Again, if you do want to go back, I’ll just show you that use case again, and that’s probably a little bit hard to read. But we also have an absolutely free download for the use case template where you can go ahead and have this template fully at your disposal to start using right away in your work as a business analyst. And again, that’s another free download and we’ll leave a link for that below.
You can learn more about use cases in this video:
COTS Requirements: Data Modeling
Okay, so third element of COTS requirements is data modeling. I would say data modeling is always important. Data is everywhere these days. It’s kind of a buzzword in a way, but as part of a COTS project, it might be one of the areas that you need to pay the most attention to. Maybe the second to only the business process.
What happens is often you are either migrating data from one system to another, maybe a legacy system to your COTS system, or maybe even spreadsheets to your COTS system and you need to migrate that data. That’s considered a one-time move.
And then the other example would be if that COTS system is actually integrating with another system. It could be your legacy system. It could be two COTS systems integrating together using an API. It could be any multiple number of things. But in that case, data is moving back and forth. In both of these scenarios, understanding the data dictionaries of both the source system and the target system, where the data is now and where it’s going to, as well as how those data fields map together is really important because often there’s logic. If your target system only allows 20 characters for company name and your source system allows 25 and people are often filling that in, it’s going to get truncated and you want to figure that out before you move data over and then people are saying the system is broken. You analyze these requirements with a data map.
It could be that there are fields that are broken apart in different ways or combined in different ways, or that are labeled the same thing, but actually used differently by the business. That’s where the business process layer comes in. You really want to understand what that data is and how it has an impact or how it’s going to flow.
One of our participants, Stephanie Belhomme, she is now an independent contractor as a Salesforce business analyst. She really learned to see how critical data modeling was as a tool that she could bring to her clients.
She says as a contractor, my clients are paying me to bring my best, to bring tools. It’s really important that I can do that. The Bridging the Gap program really helped her elevate her skillset.
But particular to data modeling, she realized that past projects she hadn’t really gone into that level of detail. There are always project pressures. Just like get it out there. Often, this was a great way to have a bigger impact for her clients and to make those projects go more smoothly as well.
To learn more about data mapping, check out this video:
Your Business Analysis Skills Can Make You a More Valued Contributor on COTS Projects
One other final thing I want to leave you with is about, just in general, how business analysis skills can make you a more valued contributor on COTS projects.
The example here is Tammy Schlador. Tammy was and is an expert in SAP. It’s another system. We’ve talked about multiple different systems here. She found that she was getting job offers that were very like SAP, developer or administrator focused because she was emphasizing her SAP skillset on her LinkedIn profile and her resume. And then when she would interview for a business analyst job, a new job she would find that she would do great at those SAP questions and she would fall short or felt like she was falling short at those business analyst questions about how she would actually work with users and end users, and how she would actually make sure the requirements reflected the process that was needed.
When you’re thinking about moving from one industry to another, which you may be just wanting to, think about, well, where is my career going to go? Am I always going to be in this one industry with this one domain and have a lot of expertise, both in the technology and in the business?
Probably not. Probably you’ll switch that multiple times over your career, and that’s going to give you a lot of opportunity to explore new opportunities. And in Tammy’s case, she moved from the steel foundry industry to the pharmaceutical industry and earned a 20% salary increase as a result of being able to shift industries like that. And it was because she had learned the business analysis skillset. Even though she had, I think it was like 20 years of experience doing business analysis on SAP, it was the. understanding and the grounding and the skills that we’ve just talked about that enabled her to move into a new job in a new industry. She actually had a recruiter contact her based on the updates she made to her LinkedIn profile, both to emphasize her business analysis skill set and add her training.
Just another example of how having a breadth of business analysis skills is super important and it’s really seen as valuable by your stakeholders as well, and by your hiring managers.
There we have it. A really good, detailed rundown of COTS requirements, the kinds of requirements that you need for these types of projects. Be thinking about your business process, your use cases and wire frames, your functional requirements. Definitely don’t forget those data requirements. A lot of people overlook them.
Also, this might seem like a lot to focus on, but realizing what’s in it for you is a much more longevity in your career and much more transportability of your skill set.
You’re not cut down or constrained by one area of expertise in either an area of software or an area of business domain expertise. You start to build a skill set that you can take with you anywhere, and that’s what we want for you.
Again, lots of resources that will further cover these concepts in other videos as well as the free business process template and the free use case template. Go ahead and download those if you want to get started right away.
Again, I’m Laura Brandenburg from Bridging the Gap. We build our profession one business analyst at a time, and success starts with you.
Thanks for being here.
>>Improve Your Requirements Analysis Skills<<
When you join The Business Analyst Blueprint® training 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.
>> Click here for more information about The Blueprint <<
No matter what type of project you are on, you need to have a structured business analysis framework and approach! Check out this video next to learn more about the 8-step business analysis process framework:
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.
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.
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….?
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.”
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.
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.
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?
Laura
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.
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.
Pingback: Tweets that mention What’s different about requirements for a COTS or Saas? -- Topsy.com