Client Information
NTT Data Japan is a Japanese system integration company and a subsidiary of Nippon Telegraph and Telephone (NTT). NTT Data is a company that focusses heavily on research and development to contribute to the growth and continuity of society. It produces and uses innovative technology to solve problems that we face today through projects such as the Vatican Apostolic Library Digital Archive Project, the Smart Shirt project and the Sota nursing care support services.
NTT Data is looking for new, innovative ways to develop its Sota robot further and expand its presence different industries. Our project involves researching the capabilities of Sota (voice recognition, translation, WiFi connectable) and the available software and APIs compatible with Sota then use this research to develop a new program for Sota.
The client/organisation are extremely technically proficient, so running the service (that our team will provide) will be relatively easy to maintain. The users themselves should also be relatively technically capable due to them most likely having several software developing/programming skills in the field.
There is an increasing amount of competitors in this area of sociable robots, such as Jibo and Buddy. Sota is currently used in healthcare to interact with patients and remind them when to take their medicine. We are using Sota to for different purposes, which are mentioned in the research part of the website.
Specific Challenges
Initial Problem Statement
The client wanted us to build a system for Sota in a suitable use case. We each came up with three use cases and then met with the client to discuss our findings. The client helped us narrow down the nine use cases to three which were the most viable in their perspective. The client also introduced us to the three pillars of NTT Data - Agent AI, Voice UI and Internet of Things. We further researched the three use cases according to the three pillars and finally decided to implement Sota as a household robot that assists with cooking. This is useful for users who are not familiar with cooking or want to learn how to cook quickly and frequently. Sota will help users manage their household tasks, making cooking more convenient for users.
What is Needed for the Project
What is needed?
- Extensive research into Sota and its features - In order for us to write a program that makes use of all of Sota’s features, we have to acquire a good understanding of the product.
- Innovative ideas for a new Sota program - In order to create a program that is new to Sota and NTT Data that is competitive in the social robots market, we have to present innovative ideas for the program.
Main deliverables
- Commercially viable program for Sota.
- A program that makes use of NTT Data’s three pillars.
Requirements Gathering
Our requirements were gathered by discussion with our client. Since our project involved starting from the very beginning, with designing the problem statement, we included our client in our decision making to ultimately pick a problem statement and build a list of requirements on our idea.
Personas
MoSCoW Table
Based on our requirements, we did a MoSCoW analysis and identified functional and non-functional requirements.
| Requirement | Type |
|---|---|
| The robot should incorporate voice UI by allowing the user to create and update a grocery list by speaking to it. | Functional |
| The robot should verbally respond to user input. | Functional |
| The robot should update grocery lists which should be accessible to the user. | Functional |
| Sota should also incorporate Image recognition by being able to identify ingredients that the user might not know. | Functional |
| Sota should be intelligent enough to recommend a recipe to the user depending on the ingredients the user has suggested to Sota. | Functional |
| Sota should also be able to walk the user through recipes using voice UI. | Functional |
| Sota should be able to carry out basic conversions e.g ounces to grams. | Functional |
| Sota should be able to set alarms and timers. | Functional |
| Sota should be able to recognize ingredients under various light conditions. | Non-Functional |
| The instructions provided by the robot should be vivid and easy to understand for the user. | Non-Functional |
| Sota should have a quick response time. | Non-Functional |
| Sota should be dependable i.e deliver services when requested. | Non-Functional |
| Sota should be able to work normally without threat to life or environment. | Non-Functional |
Use Cases (Considered)
The following are brief descriptions of the use cases we have chosen to research deeper into and potentially use for our project
A more complete version of our research into our use cases can be found here.
- Medication Habits - This software would notify user if he forgets to take a pill / takes more than the required amount. (useful information for doctors, esp. In case of elderly or case of people taking medication with high addiction ratio). Sota would be next to the pillbox and, if the user opens it more than X-times, it would warn the user and notify the doctor.
- Cooking Assistant - The software would act as the user’s “cooking assistant”, giving the user each step in recipes and helping the user in conversion of measurements. It saves recipes that users either load into the robot or access through Wifi from their device. Additionally, Sota can update a user’s groceries list as the user is cooking and look out for emergencies and injuries, contacting the appropriate number if it detect any.
- Personal Assistant - This will help the user from the time he/she is up right to the time when they go back to bed. Some examples are that it can stream music depending on your mood, it can plan meetings and alert the user of any upcoming meetings and it can also control the smart home(IOT).
For each of these use cases, we have looked into how we could implement it, the value it would have, the advantages and disadvantages and its competitors. Furthermore, we have analysed it against the three pillars of research that NTT Data has specified:
- Internet of Things
- Agent Artificial Intelligence (Tangible Computing)
- Voice User Interface
Use Case (Chosen)
As a team, and with our client, we decided to use our second use case (Cooking Assistant) as the use case that we are going to implement.
Decision criteria
- Commercial Viability - This use case has more potential as a commercial product, as it would include features that currently exist in other smart kitchen appliances and electronic devices. Furthermore, an increasing number of people today are interested in implementing smart home devices, a category to which Sota belongs. Further improvement of this product can be carried out through making Sota interact with other smart devices using its bluetooth feature.
- Technological Trend - Conversational computing is being explored in greater depths and is being used in more devices than ever before. Our use case would follow this trend and make use of new findings in this field.
- Ease of Implementation - The Cooking Assistant would also be quite simple to implement while remaining an innovative idea. We will use APIs such as Clarifai, Google API and Microsoft Cognitive Services, all of which are available open source, to implement our proposed features.
- An idea that the team likes - Every member on our team is keen to implement this use case, as we all find it very useful and interesting.
- Most Innovative - This use case is one of our most innovative use cases, as it provides features that are not yet widely available in the market.
Use Cases (Detailed)
| Use Case Name | Find Recipe UC1 |
|---|---|
| Description | A user asks LeChefu to find a recipe that contains several ingredients. |
| Primary Actors | User |
| Secondary Actors | System |
| Pre-conditions | User has switched Sota on and loaded this system |
| Main Flow | 1. User says “Recipe for” 2. User says list of required ingredients 3. System parses ingredients - Go to Alternative Flow if no ingredients found - Continue with Main Flow if at least one ingredient found 4. System reads out steps in recipe |
| Post-Conditions | None |
| Alternative Flow | ERROR |
| Use Case Name | Convert Measurements UC2 |
|---|---|
| Description | A user asks LeChefu to convert an amount of one measurement to another. |
| Primary Actors | User |
| Secondary Actors | System |
| Pre-conditions | User has switched Sota on and loaded this system |
| Main Flow | 1. User says “Convert” followed by a quantity and two measurements 2. System parses query to find required fields 3. System parses query - Go to Alternative Flow if either less than two measurement units are found or measurement units are not supported by our system. - Continue with Main Flow if two measurement units are found. 4. System tells user the converted value. |
| Post-Conditions | None |
| Alternative Flow | ERROR |
| Use Case Name | Identify an Ingredient UC3 |
|---|---|
| Description | LeChefu attempts to identify an ingredient that the user shows it and tell the user what it is. |
| Primary Actors | User |
| Secondary Actors | System |
| Pre-conditions | User has switched Sota on and loaded this system |
| Main Flow | 1. User says “Identify this ingredient” 2. System takes a picture of its view 3.** System queries the Clarifai API with the image 4. System picks the food item of highest probability identified in the picture - Go to Alternative Flow if no items found - Continue with Main Flow if at least one ingredient found 5. System reads out the item name |
| Post-Conditions | None |
| Alternative Flow | ERROR |
| Use Case Name | Create Grocery List UC4 |
|---|---|
| Description | User attempts to create a new grocery list of a specified name. |
| Primary Actors | User |
| Secondary Actors | System |
| Pre-conditions | User has switched Sota on and loaded this system |
| Main Flow | 1. User says “Create” followed by a name 2. System parses query for the name and converts it into our chosen file name format 3. System checks validity of grocery list name - Go to Alternative Flow if grocery list already exists or is not found in the query - Continue with Main Flow if a valid name is found 4. System creates the grocery list 5. System notifies user of completion |
| Post-Conditions | None |
| Alternative Flow | ERROR |
| Use Case Name | Select Grocery List UC5 |
|---|---|
| Description | User selects a grocery list to use as their current default list. |
| Primary Actors | User |
| Secondary Actors | System |
| Pre-conditions | User has switched Sota on and loaded this system |
| Main Flow | 1. User says “Open” followed by a name 2. System parses query for the name and converts it into our chosen file name format 3. System checks validity of grocery list name - Go to Alternative Flow if grocery list does not exist or is not found in the query - Continue with Main Flow if a valid name is found 4. System selects the grocery list 5. System notifies user of completion |
| Post-Conditions | None |
| Alternative Flow | ERROR |
| Use Case Name | Update Grocery List UC6 |
|---|---|
| Description | User updates a selected grocery list by saying items to add or delete. |
| Primary Actors | User |
| Secondary Actors | System |
| Pre-conditions | User has switched Sota on and loaded this system |
| Main Flow | 1. User says “Update” followed by names of items with either “add” or “delete” in front of them 2. System checks if a grocery list is currently selected - Go to Alternative Flow if no grocery list is selected - Continue with Main Flow if there is a selected grocery list to update 3. System parses query for the items to delete and items to add 4. System updates grocery list 5. System notifies user of completion |
| Post-Conditions | None |
| Alternative Flow | ERROR |
| Use Case Name | Delete Grocery List UC7 |
|---|---|
| Description | User deletes a grocery list from the system. |
| Primary Actors | User |
| Secondary Actors | System |
| Pre-conditions | User has switched Sota on and loaded this system |
| Main Flow | 1. User says “Delete” followed by the name of the grocery list that they want to delete 2. System parses query for the grocery list name 3. System checks if the grocery list exists - Go to Alternative Flow if no grocery list of specified name exists - Continue with Main Flow if there is a grocery list to delete 4. System deletes grocery list from folder 5. System notifies user of completion |
| Post-Conditions | None |
| Alternative Flow | ERROR |
| Use Case Name | Access Grocery List UC8 |
|---|---|
| Description | User asks LeChefu to read a grocery list from the system. |
| Primary Actors | User |
| Secondary Actors | System |
| Pre-conditions | User has switched Sota on and loaded this system |
| Main Flow | 1. User says “Read” [OPTIONAL: followed by the name of the grocery list that they want to access] 2. System parses query for the grocery list name. If no list name is found, currently selected list is used. 3. System checks if the grocery list exists - Go to Alternative Flow if no grocery list of specified name exists - Continue with Main Flow if there is a grocery list to read 4. System reads each item from the grocery list 5. System notifies user of completion |
| Post-Conditions | None |
| Alternative Flow | ERROR |
| Use Case Name | Set Timer UC9 |
|---|---|
| Description | User asks LeChefu to set a timer for a specified amount of time. |
| Primary Actors | User |
| Secondary Actors | System |
| Pre-conditions | User has switched Sota on and loaded this system |
| Main Flow | 1. User says “Timer” followed by the name of the grocery list that they want to access 2. System parses query for time in hours, minutes and seconds. 3. System checks if the grocery list exists - Go to Alternative Flow if no grocery list of specified name exists - Continue with Main Flow if there is a grocery list to read 4. System reads each item from the grocery list 5. System notifies user of completion 6. a) System concurrently carries on with other tasks if user continues b) System exits use case if user cancels timer c) System remains idle 7. When timer time runs out, timer stops and Sota notifies user |
| Post-Conditions | None |
| Alternative Flow | ERROR |
| Use Case Name | Error ERROR |
|---|---|
| Description | System notifies user of an error that has occurred due to incorrect usage. |
| Primary Actors | Robot |
| Secondary Actors | System |
| Pre-conditions | User has given system an invalid request. |
| Main Flow | 1. System says that request is invalid and gives tells user about the nature of the error 2. System waits for the next query. |
| Post-Conditions | None |
| Alternative Flow | None |