In order to successfully evaluate and select a packaged software application you must first clearly identify the functionality that you are looking for in the product. A Software Requirements Document specifically identifies and documents the overall business purpose for the software and includes a more detailed listing of the functional modules, and the general and technology requirements for the software. To create this document you will need to collect, prioritize, and organize the data in a format that will be useable by your internal team as well as one that can be passed on to software vendors so they can assess if their software offers a fit for your organization.
Define the Objective - Start out your requirements document with a statement that defines the business reason you are evaluating software at this time. The business objective can typically be defined in one or two statements then qualified with some bullet point line items that more clearly define and support the primary objective.
List the General Requirements - You should start the requirements document by listing the general requirements you have for the software. This includes technical requirements (ie. database, operating system, etc.) and general use requirements such as workflow, drill down, query and reporting tools, etc.
Define the Functional Modules - Next you should define the functional modules that will be evaluated as part of this project. This may require you to translate your business terminology to modules that are offered by the software vendors. For example Financials (General Ledger, Accounts Payable, etc.), Manufacturing (Shop Floor Control, Quality Control, Inventory, etc.), Human Resources (Benefits Administration, Position Management, etc.) are examples of how you can translate your terminology for the software vendors.
List the Specific Functional Requirements - Within each module, list out the key specific functionality you require. While it is not necessary to list every single item your list should include enough functionality that will allow you to compare and contrast the different software solutions available to you.
Request Vendor Information - Finally, your document should include a request for information about the vendor including vendor size, target user and customer profile data, and certifications and partnerships. You should also ask for a ballpark cost estimate for the project based on the information they have to date.
As you put together your software requirements document here are a few key points to keep in mind. Make sure that your requirements document is:
List the General Requirements - You should start the requirements document by listing the general requirements you have for the software. This includes technical requirements (ie. database, operating system, etc.) and general use requirements such as workflow, drill down, query and reporting tools, etc.
Define the Functional Modules - Next you should define the functional modules that will be evaluated as part of this project. This may require you to translate your business terminology to modules that are offered by the software vendors. For example Financials (General Ledger, Accounts Payable, etc.), Manufacturing (Shop Floor Control, Quality Control, Inventory, etc.), Human Resources (Benefits Administration, Position Management, etc.) are examples of how you can translate your terminology for the software vendors.
List the Specific Functional Requirements - Within each module, list out the key specific functionality you require. While it is not necessary to list every single item your list should include enough functionality that will allow you to compare and contrast the different software solutions available to you.
Request Vendor Information - Finally, your document should include a request for information about the vendor including vendor size, target user and customer profile data, and certifications and partnerships. You should also ask for a ballpark cost estimate for the project based on the information they have to date.
As you put together your software requirements document here are a few key points to keep in mind. Make sure that your requirements document is:
- Complete. The document should include all of the key requirements that are important to your organization. Define what you need the software to do but not how it will do it. Expect to leverage from the best practices offered by the packaged software applications.
- Consistent. Keep the wording of the requirements unambiguous and with a consistent level of detail; be concise and direct. Avoid vague requirements and word redundancies or paragraphs of information that contain multiple requirements. Use terms and acronyms consistently and define them in a glossary. Avoid the use of and/or.
- Feasible. The requirements that are included in your document should be realistic in terms of functionality a software application can provide. If the requirements are too extreme your only choice may be customization of applications that can be costly and not recommended by most software vendors.
- Prioritized. Develop a rating system so that the document clearly defines what requirements are most critical to your final decision. A suggested ranking system may be Required, Important, and Nice to Have.
Increase your KPIs by using manufacturing software solutions. Have a chat with Alenu Group today at +65 6884 5030
No comments:
Post a Comment