Ftfrentals Software Requirements SD Notes

You might also like

Download as odt, pdf, or txt
Download as odt, pdf, or txt
You are on page 1of 2

FTFRentals System Requirements

This is an unordered list of things to generally keep in mind when


purchasing/developing/implementing a system for the management and operations of FTF Rentals
specifically:

• No vendor lock-in (preferably with the use of open standards and open-source software)
◦ Rationale:
▪ Allows for easy future modification and adaptability given the historical growth of
the division as well as future plans for growth
▪ Increased opportunity for staff innovation
▪ Increased security of data
▪ Less costs
• Backed by a relational database system or object relational database system
◦ Ability to export data from application to standard formats (Excel, csv etc)
◦ Preferably ability import data to application for quick set-up and/or batch updates
◦ Allows for ad-hoc reporting (preferably ability to run SQL queries, else some type of
interface)
◦ Concurrency
◦ Easy view implementation
▪ Employee role determines their view of system (show them what is most important
to them based on KPI, management strategy etc.)
• All equipment for rental should be modelled
◦ Suggested attributes (some may or may not be applicable based on equipment) include:
certified (boolean), date of certification, certification document, equipment serial
number, engine serial number, description, current status, current location, technician
notes, on-rental (boolean), running hours, hours last serviced, owned-by (linked to re-
rental vendor table behind-the-scenes but the how is up to implementer/developer), c…
◦ Ultimately up to software developer/implementer but our business rules should always
be kept in mind
• Keep track of equipment certification and reports are needed for an
administrator/coordinator to be able to successfully keep track of all certification quickly
and efficiently
• Equipment status and location must be easily updated and preferably updated via a web
application by coordinator (status) and inside/outside sales team (location)
• Sub-system for equipment return
◦ The flip side would be a sub-system for equipment dispatch with an accurate way to
capture how equipment looks when it goes out and save it. Then upon return capture its
state and automatically generate a communication for any damages.
◦ Automatic documentation for customer to note time of return or pick up if we are
transporting the equipment
• Technician reports can be done in-field via web application and signed on-screen by
customer to reduce paperwork and provide real-time (or near real-time if checked by
administrator/coordinator) updates to equipment status and maybe location
◦ Added benefit of real-time time clock including overtime
• Geolocation of equipment with automatic routing for technicians
• Equipment maintenance scheduling capabilities
• Reports generated must include reports for equipment based on location, status, ownership
(ours or vendor); equipment return-on-investment; equipment utilization, equipment
certification
• Accurate modelling of business rules:
◦ Daily, weekly, monthly rates
◦ Rates differ for on-land, offshore, 0 to 8 hours running time per day, 0 to 12 hours
running time per day, and 0 to 24 hours running time per day (maybe needs review)
• A month is not always a calendar month
◦ Extensions
▪ Electronic signature of extensions (all rental transactions?) will reduce
administrative load and increase sales coverage and effectiveness
▪ Ablity to change rental due-date based on customer agreement
◦ Long-term contracts with periodic invoicing capability
▪ Automated invoicing generally with ability to manually alter process with
authorization
◦ Linked to equipment table (with real time or near real time updates of running hours and
status) and automatic checks for hours of usage and stoppage due to equipment being
down.
▪ The rental may or may not be stop based on why the equipment is down and
customer agreements
◦ In-house transportation must be modelled as a non-recurring, add-on item
◦ Equipment operator must be modelled as a non-recurring, add-on item
◦ Rental transaction should also be able to be manually stopped with checks and balances
◦ Ability to set-up (and keep track of) unserialized add-ons (cables, wire ropes, platforms
etc.) as a package with serialized items to be rented as packages/kits
◦ Value Added Tax
• Employee scheduling
◦ Team leader define schedule and employees have ability to check scheduling on-line and
print schedule etc.
• Customer and vendor relationship management system
◦ Keeps track of all rental customers who are sometimes different from our VAI credit
customers
▪ This will allow us to consistently apply our transactional security measures (first-
time customers required to provide certain documents) and reduce administrative
load
▪ Database should include attribute to track if customer is a credit customer or not
(terms can be looked up on system)
• a bit of a fudge because of having to interface the two systems but will prevent
financial policy violations and ensure credit policy enforcement
◦ Vendors for supply of products and services for equipment should be modelled in system
◦ Vendors who supply us with equipment should also be modelled in system
◦ Preferably a web application can track all customer/prospecting and generate a quotation
seamlessly while allow both inside and outside sales to communicate effectively
◦ Communication automation linked to customer database

You might also like