Commercial off the shelf packages (COTS) are packaged solutions that can be used out of the box or configured to meet the business needs. This is instead of creating software from scratch. The benefit of the latter is that the solution can be developed to meet the requirements exactly.
Using COTS may involve requirement trade-offs but:
- May be a quicker and cheaper solution.
- It may not need a team of architects, developers and testers as with a custom-made solution. This will depend upon whether resources are needed to design and built interfaces of the COTS system with other systems in your enterprise landscape.
- It has already been developed, tried and tested with the independent organisation creating it and with their existing customers.
- If the software package has been around for some time it may have also gone through a round of improvements based on customer feedback, be of high quality and reliable.
- For a large organisation that has grown through acquisitions, different business units within the organisation may have different processes. Having packed solutions allows management to enforce conformity of business processes and thereby allowing centralised support teams which results in overall reduction of total cost of ownership.
- Having packaged solutions allows organisations to buy once, review once and reuse multiple times.
There are 4 main challenges with gathering requirements for commercial off the shelf packages.
- May not meet all the requirements.
- The business may be more likely to write their own requirements and go direct to a supplier without fully understanding their needs.
- It can be difficult to distinguish why one supplier is better over another.
- IT constraints might not be understood. For example, the location of data hosting may be an issue. IT policy may not allow cloud hosted solutions or there may be additional security checks required.
The important tasks for business analysis include:
Below takes each of the points above in turn to explain in more detail.
Understanding the business problem and opportunities
The business will have a good knowledge of the problems they want the software package to resolve and what success should look like. The more stakeholders there are may uncover different problems to overcome. Further problems may also be identified during the gathering and documenting the business process. See the article How to gather benefits and requirement justifications using NLP for further guidance on this.
Inputs
Finding out about the inputs required will identify the people, data and system interfaces the system needs input from. If a purpose of the software package is to make a manual process more reliable and efficient then there may already be existing paper or system inputs that can be used for documenting the interfaces and data that the software system needs to use.
Outputs
Outputs may mean that the data needs to feed into other systems or be in the form of MI reports. If this involves replacing existing manual processes then these can be looked at as a starting point. Questions can be asked around what outputs need to be replicated, gathering of existing examples, changes required and what new outputs are required and in what form.
Documenting and agreeing the required Business processes.
This is important as the software tool needs to fit with it or have manual work arounds if the software cannot match the requirement exactly. By understanding the end to end process allows questions to be asked on which ones require the software to be involved and understand the impact if it isn’t possible. For more detail on business process modelling see A guide to Business Process Modelling.
Non-functional requirements
These can be particularly important to understand constraints that the software must meet. For example, if your company has standard software then any new software packages may need to be compatible with it. See the article Gathering Non Functional requirements and who to involve (Part 2) for categories and questions to be considered.
Functionality / features
Pulling together the problems to be resolved, opportunities, inputs, outputs and business processes will identify the functionality and features required.
Understanding of priority
This is important because it may not be possible for a software package to meet all the requirements so an understanding is needed of which ones are showstoppers and which ones can be managed in a different way.
Selection and scoring criteria of vendors
Documenting functionality and non-functional requirements in a spreadsheet format is one method that can be used to then ask each vendor to respond with how they can meet each requirement along with a description of how each can be met. This can then be used as part of the scoring criteria along with other factors.
It is common to score packaged solutions on the following criteria
- Capability
- Flexibility
- Infrastructure
- Performance
- Reference Sites
- Reporting
- Support
- Cost
There is more detail around further questions and evaluation criteria in A guide to the RFP process.
Thoughts? Questions? Please share in the comments.
If you have found this article useful then you might like my book – The Business Analysis Handbook – Techniques and Questions for better Business Outcomes. The book is available from www.koganpage.com and all major print and e-book retailers.
