SMS Storetraffic Glossary
Table of Contents
This is a auto-generated Article of all your definitions within the glossary.
Glossary
This is a auto-generated Article of all your definitions within the glossary.
-
Administrative Details
In this final section of your SOW business document, you should outline any other relevant project or contractual specifics. If your SOW is meant to accompany or be included in an RFP, you may want to lay out your company’s standard payment terms or contract terms. You could also consider including details about how project management and status updates/reporting will be handled throughout the project. In short, this is your catchall section for details that are specifically relevant to your software development project, your project management and process requirements, and how you intend to use your SOW. Could include: Payment terms / payment model Standard company contract terms Reporting requirements Project management details
-
Assumptions
Assumptions Everyone working on a software development project will have a set of assumptions about it. Problems come in when the assumptions aren’t acknowledged. To help ensure all stakeholders - internal and external - are aligned, document all assumptions that are being made about the project at hand. Questions to consider: What assumptions are you making about hosting, deployment, or post-launch support? What assumptions are you making about technology stacks or compatibility? What assumptions are you making about approvals required in order to move from one phase of the project to the next? Example: Assumption 1 The vendor will provide on-demand support and maintenance for 12 months. 2 The system will replace our current, legacy system within 3 months of launch. 3 The project lead will have final say on approving design decisions for the front-end system. …
-
bidirectional traffic counter
A traffic counter which has the ability to report IN traffic and OUT traffic separately thus proving the ability to calculate occupancy. (Example: PEARL or 3DScope counters have the ability to sense which direction people are walking unlike legacy break beam solutions, mono overheads as well a inaccurate thermal solutions).
-
Commercialization
SMS Storetraffic offering this technology to the market.
-
Déclencheurs
Un événement défini qui, lorsque détecté, envoie une alerte ou notification. (Exemple: Occupation maximale de 500 personnes, une notification E-mail sera déclenchée si plus de 500 personnes se trouvent dans le lieu).
-
Deliverables
It’s time to think about what you are expecting the outputs of the project to be. Think about this as a way to expand upon your project goals and define what success would look like for your software development project. Depending on the size of your project, you can consider breaking down the deliverables into project phases, sometimes referred to as a work breakdown structure (WBS). Questions to consider: What work breakdown structure makes the most sense for your project? Have you considered all relevant key performance indicators? Has everything been detailed out sufficiently to avoid scope creep? Have you outlined all relevant extensive and comprehensive tasks? The level of detail you provide in this section of the SOW document will depend on your project. If you are hiring software developers to do the work for you, you’ll want to keep the deliverables specific but non-technical, as the software developers will help you define the specifics of how the deliverables will be achieved. Example: The project will be broken down into two phases with the following deliverables: Project Phase 1: Build Back-end Big Data System Engine that analyzes real estate market data at scale Pre-processing of internal statistical data Processing of external geospatial data sets Integration with existing data storage system Project Phase 2: Build Data Visualization Platform User-friendly web application that provides access to data on demand Flexible visualization tools that provide geospatial data maps Report generation functionality
-
Functional Requirements
Next up in your SOW document should be a list of all functional requirements for your software project. Functional requirements should describe what a software system is supposed to do (i.e. how it should function). The end result of functional requirements will be the features of your application, website, or product. Should include requirements related to: Administrative functions and permissions Enough specificity for functionality implementation to begin User functionality and operations for every screen All workflows performed by the application Consideration for all relevant hardware and software restrictions Depending on the complexity of your project, you might want to break down your functional requirements by screen, application area, persona, or by some other means to make them more understandable.
-
HMI
Human Machine interface. This is the web portal that is used to access the 3DScope II for configuration purposes.
-
HML
High Medium Low
-
interval
Measurement of time. Traffic counters are usually set to the following intervals (15, 30, 60minutes, Daily, Weekly, Monthly or Triggered (Real Time))
-
Items Sold
The total number of items sold summarizing all transactions within a specified time.
-
LC
Low ceiling model 3DScope II counter
-
Live T.M.A.S. Subscription
Unlocks the ability of the PEARL or 3DScope counters to send traffic to T.M.A.S. in real time (Triggered) as soon as someone walks IN or OUT to update reporting.
-
Non-Functional Requiments
Non-functional requirements should describe how a software system works. The end result of non-functional requirements will be product attributes that may be more “behind the curtain,” but are just as important as functional requirements. Should include requirements related to: Security. Will you be storing PII or other sensitive data? Does your company have any specific security standards that should be adhered to? Capacity. What kind of data storage requirements do you have? Do you expect your needs to change over time? Compatibility. What are the minimum hardware requirements? What are the technical limitations that should be considered? Reliability. Do users need 24/7 access? What are the acceptable down times for your system? Scalability. What is the maximum load that should be able to be handled? Consider both data and user traffic. Usability. Are there specific UX standards that should be followed? Consider also ADA accessibility.
-
pass-by
people passing in front of a location WITHOUT entering it
-
Project Schedule
After you have defined your project deliverables, you need to lay out the project schedule. This is key for any project planning document! Start by considering the high-level project duration, then break down your project into distinct tasks (or use the phases from above) and set the start and end dates for each. Questions to consider: What dependencies exist for individual tasks? Who will be responsible for each task? What development process will you be using (such as Agile)? How will project delays or missed deadlines be handled? Example: Task description Responsible Party Schedule 1 Vendor Evaluation & Hiring Internal Start date: March 1 End date: April 15 2 Build Back-end Big Data System Vendor Start date: April 30 End date: June 15 3 Build Data Visualization Platform Vendor Start date: June 15 \ End date: Aug 1 4 Testing & Deployment Joint Start date: Aug 2 End date: Aug 15
-
RACI
Responsible, Accountable, Consulted, Informed.
-
Risks
Every IT and software development project will come with risks. To help all levels of management understand what could Make sure to include all stakeholders in documenting the relevant risks for their area of expertise. Should include: Value risks - not providing the required value to internal stakeholders or external customers to make the project successful or profitable Usability risks - potential problems with the usability of the software system Feasibility risk - project failure due to technical or staffing shortcomings
-
Sales Data
Total amount of $$$ which your location generates per hour or day.
-
SIS
Store-In-Store
-
Staff Hours
Total number of staff hours which represents sales associates on the sales floor of a location.
-
Transactional Data
Accumulated total of transactions performed.
-
Triggers
A defined event which when detected sends an alert or notification. (Example: Max Occupancy is 500 people, an E-mail notification will be triggered once people passes 500 in the location).
-
UPT
Units per transaction, which is an average of items sold based on all transactions for the selected interval.
-
UWB
Ultra-Wideband (UWB) is a short-range, high-bandwidth wireless communication protocol known for precise location tracking and secure, low-power data transmission, often used in applications like real-time location systems, contact tracing, and keyless entry.