Where do you start with requirements for software on embedded devices?
In cases where the embedded device interacts with a person, but without a traditional user interface (UI), testers have to look at the interactions between the device and the user. In other words, testers have to focus on what the device does for different types of users.
This approach may sound touchy-feely, but it shouldn't be. Testers can map out points of contact between the device and the person, and then develop a range of test cases for those points. Contact points can be physical, emotional or interpretative.
For example, in the case of the Fitbit, a number of contact points don't involve the simple UI that provides basic activity data during the day. For instance, does the location of the activity device on the person affect results? Does time of day or intensity of activity provide skewed data?
What constitutes a successful device? The contact points between the person and device matter there too. The goal of the activity tracker is not just to provide data to the user, but to use that data to encourage a greater level of activity. Presentation of that data matters. Although the FitBit itself has a limited UI, it connects to a website that provides real-time updates, easy to understand performance data and historical data. Most interestingly, it provides rewards to those users who achieve daily and lifetime activity goals. That's a contact point too, albeit with the website as an intermediary.
It also goes without saying that you need a range of users and activities to test devices with little or no UI. That goes for use cases during product design, so it's particularly important to test the design with use cases. Ultimately, it may also make sense to test outside of those use cases.