Talk:GreeterBot Requirements Spec
- 1 GreeterBot Requirements Spec
- 2 General Description
- 2.1 Product Perspective
- 2.2 Product Functions
- 2.3 User Characteristics
- 2.4 Constraints
- 2.5 Assumptions and Dependencies
- 2.6 Apportioning of Requirements
- 3 GreeterBot Specific Requirements
- 3.1 External interfaces
- 3.2 Functions
- 3.3 Performance Requirements
- 3.4 Logical Database Requirements
- 3.5 Design Constraints
- 3.6 System Qualities and attributes (Non-functional requirements)
- 4 Livid Lobster Specific Requirements
- 4.1 External interfaces
- 4.2 Functions
- 4.3 Performance Requirements
- 4.4 Logical Database Requirements
- 4.5 Design Constraints
- 4.6 System Qualities and attributes (Non-functional requirements)
GreeterBot Requirements Spec
This section introduces the spec and product.
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.
The GreeterBot product comprises two robots:
- 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.
- 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.
- 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.
- IEEE802.3 Software Requirements Spec standard
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.
This section of the spec describes the general factors that affect the product and its requirements. This section does not state speciﬁc requirements. Instead, it provides a background for those requirements, which are deﬁned in detail in Section 3 of the spec, and makes them easier to understand.
The system is largely stand-alone, requiring only AC power and wifi network access. The diagram below shows the physical layout of the office
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.
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
- 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.
- 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
Question: should there be a communication interface from e.g. a web browser that lets tenants see who's in the lobby?
Site Adaptation Requirements
Person Enters Door
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
- User enters reception room through entry door
- 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"
- User speaks name or touches name on touchpad
- 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".
- 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.
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?
- Issue 1
Change system state
Goal in Context: Change the system state from enabled to disabled or visa versa
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
- Person presses button or switch
1a. Can system be unable to change state?
- Issue 1
Goal in Context:
Success End Condition:
MAIN SUCCESS SCENARIO
- step 1
- step 2
1a. extension 1a
- Issue 1
Assumptions and Dependencies
Apportioning of Requirements
GreeterBot Specific Requirements
- Door switch
Logical Database Requirements
System Qualities and attributes (Non-functional requirements)
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?)
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.
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
- Door switch