Talk:GreeterBot Requirements Spec

GreeterBot Requirements Spec

This section introduces the spec and product.

Purpose

The purpose of this document is to state the requirements for the GreeterBot product. It is a communication vehicle between the project sponsor and the development team. It defines what the project should and should not deliver.

Product Scope

The GreeterBot product comprises two robots:

1. A stationary robot located opposite the entry to an office suite. This robot is called GreeterBot, and it greets visitors and directs them to the appropriate office based on the visitor indicating who they want to see. GreeterBot has a camera it its head.
   
2. A mobile robot which starts in the vicinity of GreeterBot and leads the visitor to their destination. This robot is called Lividlobster, or "the lobster" for short. It is a HI-WANT part of the product.

When someone enters the office suite, GreeterBot will welcome them and ask who they've come to see. It will offer them the option of replying by speaking to the robot, or by touching a person's name on a touch screen. When the visitor has selected a tenant, it will indicate with an arm motion which of two hallways they should walk down, and will announce orally which office they should go to. It will then point to the lobster and instruct them to follow it.

The lobster will then move from the base of GreeterBot down the appropriate aisle as far as the destination office.

Glossary

• Tenant: someone with an office in the suite where Greeterbot is installed, to whom visitors should be directed
• MUST, SHALL, SHOULD: Defined by RFC2119. Must and Shall indicate requirements that must be met in order for the product to be acceptable. Should indicates requirements which are highly desirable and will be scoped and resources applied. However, if schedule or resources prevent delivery, the product is still considered acceptable.

References

• IEEE802.3 Software Requirements Spec standard
• RFC2119

Overview

The rest of this requirements spec specifies the requirements for the product. Section 2 provides a general description of the product. Section 3 states specific requirements for GreeterBot, and Section 4 states specific requirements for Livid Lobster.

Lividlobster is an optional part of the product, so it SHOULD be built. If it is to be build it must do certain things in order to be viable. The reader should understand that SHALL and MUST when referring to the lobster mean things it must do if it is delivered as part of the product.

General Description

This section of the spec describes the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are defined in detail in Section 3 of the spec, and makes them easier to understand.

Product Perspective

The system is largely stand-alone, requiring only AC power and wifi network access. The diagram below shows the physical layout of the office

System Interfaces

The system will work with 802.11g wifi. Networking is necessary to enable GreeterBot to tell lobster where to go, to pass camera images around, and for remote support.

User interfaces

GreeterBot shall have a microphone for capturing the name of the occupant the visitor has come to see. It should be built into the robot, but audio characteristics of the room may require it to be elsewhere in the entry space.

GreeterBot should have a tablet with a touch-screen showing a list of occupant names. A visitor may touch a name to receive directions.This feature is a HI-WANT.

Greeterbot shall support a user interface for editing tenant names

Hardware Interfaces

• Door interface: GreeterBot shall detect door opening as a trigger for visitor detection</u> Other hardware as required shall be used to detect visitors entering the reception area through the front door.

Software Interfaces

• Picture or video interface: Greeterbot shall expose an interface to client computers located in the offices which allow tenants to see who's in the reception area. It may offer a web page, or other interface which provides a static or moving image of the

Communication Interfaces

Question: should there be a communication interface from e.g. a web browser that lets tenants see who's in the lobby?

 

Product Functions

 

Use Cases

Person Enters Door

---

CHARACTERISTIC INFORMATION

Goal in Context: A user enters the door. A visitor wishes to visit a tenant, or a non-visitor wishes to go somewhere in the facility

Preconditions: System has been enabled

Success End Condition: GreeterBot points down the correct hall and announces the office location and Livid Lobster drives down the correct hall to the correct office door

Minimal Guarantee: The system has logged salient data and GreeterBot is in its idle pose

Primary Actor: User entering reception area

Trigger: Door opens

---

MAIN SUCCESS SCENARIO

1. User enters reception room through entry door
2. After 2 seconds, GreeterBot greets user with flashing mouth lights and announces "Welcome to Livid Lobster. Who are you here to see? You can speak the name of someone, or you can touch their name on my touchpad. Please come close and speak directly to me"
   
3. User speaks name or touches name on touchpad
   
4. GreeterBot responds accordingly by pointing down the correct hall and enunciating an answer of the form "The first hallway, 2nd door on the right. Please follow the Livid Lobster robot, who will guide you there".
   
5. Livid Lobster scoots off down the correct hall, stops near the correct door (but doesn't obstruct it), and plays a happy tune. It pauses there 30 seconds, then returns to its dock beside GreeterBot.

---

EXTENSIONS

1a. User is leaving reception area.System remains inactive

1b. User is not a visitor, and does not wish to be guided. Person speaks to GreeterBot before GreeterBot begins speaking (e.g. says "Hi BF"). System remains inactive and scenario ends

1c. Person is working in the reception area (did not enter through door). System remains inactive.

1d. There is a person working in the reception area when someone opens the entry door. What should happen? What if they're making noise, or not making noise?

3a. User does not respond, or response is undetected. System returns to inactive state.

3b. Oral response is detected but not recognized/matched to tenant name. GreeterBot says "I'm sorry, I don't recognize that name. Please say the name again, or say Cancel to end  this interaction". If user says "Cancel" system quiesces. If user doesn't respond in 30 seconds, system quiesces. If user responds within 30 seconds or touches touchpad, return to step 3. Issue: there needs to be a default instruction to the user in case they can't get the system to help them. What should it be?

---

OPEN ISSUES

• Issue 1

Change system state

---

CHARACTERISTIC INFORMATION

Goal in Context: Change the system state from enabled to disabled or visa versa

Preconditions: None

Success End Condition: System has started or shut down

Minimal Guarantee: System state is not changed

Primary Actor: user

Trigger: Press button or switch

---

MAIN SUCCESS SCENARIO

1. Person presses button or switch

---

EXTENSIONS

1a. Can system be unable to change state?

---

OPEN ISSUES

• Issue 1

---

Template

---

CHARACTERISTIC INFORMATION

Goal in Context:

Preconditions:

Success End Condition:

Minimal Guarantee:

Primary Actor:

Trigger:

---

MAIN SUCCESS SCENARIO

1. step 1
2. step 2

---

EXTENSIONS

1a. extension 1a

---

OPEN ISSUES

• Issue 1

GreeterBot Specific Requirements

 

External interfaces

• Door switch

System Qualities and attributes (Non-functional requirements)

Appearance

The Greeterbot shall have an illuminated mouth which flashes as it speaks. It's head shall have one degree of motion (TBD: how is it supposed to move?)

Safety

The moving components (arm, head, lobster) shall move slowly enough  and with low-enough force so as to not cause injury when striking an unaware person standing in their path. As a guide, a person shall be able to resist the motion of any actuators without undue exertion.

Portability

The Greeterbot and lobster are intended to be transported in a trailer to expos. A user shall be able to disassemble the system if necessary, using only ordinary hand-tools, such that the weight of any transportable component of the system does not exceed 100 pounds (2-person loading/unloading..

Livid Lobster Specific Requirements

External interfaces

• Door switch