CS 477 Lecture Notes

Week Six, Thursday: Informal Specification

First Team Presentations

Each team will have 5 minutes to present the project status. Two minutes will be provided to answer questions from the audience, leaving a one minute "guard band" between presentations.

Your first team presentation should utilize overhead projector slides (transparencies) and should cover:

Team organization and management style. What roles does your team have and who performs them?
Your customer's domain. Who is your customer, and what is his/her scope of operations?
Your customer's software system product need. What is the current situation and what is your customer's vision for the future? List the requirements for the software product as you understand them.
Your assessment of the situation. Can you meet the customer's needs this semester (fully or otherwise)? What can you reasonably expect to accomplish?
Your choice of software engineering approach (conventional or MBASE).

This is a lot of material to cover in five minutes, but you can do it if you practice with your team to hone your presentation. Don't waste time but get to the essential information. At four minutes you will be given a one-minute warning, and at five minutes you will be cut off.

You must turn in a paper copy of your slide presentation and a paper copy of your requirements document (if you are using a conventional approach) or a revised OCD (if you are using MBASE).

Agenda:

3:40 PM: Team A.
3:48 PM: Team B.
3:56 PM: Team C.
4:04 PM: Team D.
4:12 PM: Team E.
4:20 PM: Team F.
4:28 PM: Team G.
4:36 PM: Team H.

Specification Phase Overview

The specification is the next step (after requirements) in the refinement of the project conceptualization. The specification should reflect the requirements, but be less ambiguous and more complete. An informal specification document is written from the developer's point of view, where the requirements document is written from the customer's point of view. As a contract, the specification document should also have a greater degree of formality.

Specification Example

This is an example of an informal specification. Suppose you are a software engineer working for Rick's Universal Robots company. Further suppose that RUR wants to introduce a new domestic robot, the Robo-Butler. And suppose that the mechanical design of the robot has been fairly well established and that it is up to you to produce the software for the robot.

The target customer group for Robo-Butler is a typical upper-middle-class house-holder with two Infinitis in his driveway and fifty thousand dollars burning a hole in his pocket. He wants a household robot to impress his friends with.

You decide to hold some sensing sessions with typical members of the target customer group in order to establish requirements. Here are the results of the sensing sessions:

Requirements

The primary requirement is to impress the customer's friends when they are at the customer's house. That is, the Robo-Butler should (1) perform efficiently as a butler, (1.1) recognizing and (1.2) greeting the guests by name at the door, (1.3) offering to take their coats, and (1.4) escorting them to the host, at a party for example.
The Robo-Butler should perform other duties at social functions, such as (1.5) fetching drinks for the guests, (1.6) collecting empty glasses and taking them to the kitchen, and (1.7) emptying ashtrays as necessary.
(2) The Robo-Butler should not pose a threat or injure any person at any time. (2.1) We want the guests to be impressed by the robot, not afraid of it.
(3) The Robo-Butler should not let anyone into the party who is not on the invitaion list. (3.1) In the case of an unrecognized guest, the Robo-Butler should politely ask the guest to wait (outside at the doorstep) and then summon the host (customer-owner).
Many customers asked if the robot could wash dishes. At this time, the answer is "no" because that task is too difficult. (4) Perhaps in the next version, (4.1) a new software module can be added that will have that capability. (4.2) The same goes for vacuuming the floor.

Specification

A number has been assigned to each general and specific requirement identified above. The list of specifications is structured accordingly.

2.1 Butler Functionality

The primary functionality of butler behavior will require a speech recognition module, a vision module with face recognition, a voice module with speech synthesis, and appropriate locomotion and manipulation modules.

2.1.1 Guest Recognition

The vision system shall utilize an appropriate face recognition technology and shall allow the customer to easily load images of his friends for training. The recognition shall be 98 percent accurate under typical operating conditions under typical exterior or interior lighting, day or night (except in the case of guests arriving for a Halloween party).

2.1.2 Guest Greeting

The Robo-Butler, upon recognizing a guest or group of guests who are all on the invitation or general access list, shall open the door for them and politely greet each by name with an appropriate welcome (such as "How very pleasant to see you again, Ms. Calvin, won't you please come in?).

2.1.3 Guest Posession Assistance

As the guests enter the house, the Robo-Butler shall assist the guests with their coats, hats, and other posessions which they wish the Robo-Butler to store for them. Robo-Butler shall extend his hand, palm up, to each guest in turn and say "May I take your coat (and hat)?" as appropriate. If a guest should say, for example "Yes, please, and will you also take my cane?" then the Robo-Butler should accomodate the request and say "Yes, certainly."

The robot should place the collected guest posessions in the hall closet in an appropriate manner, planning the best process for doing so (there are a lot of implicit specifications in this one, and they need to be further broken out).

2.1.4 Guest Escort

The Robo-Butler should say "please come with me" or other expression as appropriate and lead the way to the host (customer-owner). If there should be some event, such as a guest saying "just a minute while I adjust my hair in the hall mirror," for example, the robot should wait appropriately and then continue escorting the guest(s).

2.1.5 Drink Fetching

Robo-Butler should not offer drinks to the guests, but should respond to requests such as "will you please bring me a glass of white wine?" This requires knowledge of various drinks and how to assemble them, and how to carry them without spilling. A tray will be be used to carry drinks as appropriate. The robot should also respond appropriately to requests by the host for drinks for his guests.

2.1.6 Glass and Plate Bussing

The Robo-Butler, when not answering the door or performing drink fetching duties, should look around and be on the alert for empty glasses not being held by guests and empty or abandoned-looking plates not being used by guests. When these items are identified, Robo-Butler should take them to the kitchen, using a tray as necessary, and put them on empty counter space in an efficient way.

2.1.7 Ashtray Emptying

When not otherwise occupied, Robo-Butler shall keep an eye out for ashtrays more than one third full (of cigarette butts), and shall empty them into an appropriate fire-proof receptical.

2.2 Safety

All behavior modules shall be proven correct to preclude unexpected behavior. The Robo-Butler shall be incapable of exerting more than 40 pounds force within two feet of a human, and shall be incabable of moving any component at a greater speed than two feet per second within two feet of a human.

2.2.1 Benign Behavior

The Robo-Butler shall have a distinctly "robotic" motion so as not to startle humans with potential false recognition, yet the robot shall have a butler-like demeanor so as to immediately convey his benign function.

2.3 Security

The Robot-Butler shall preclude the entrance of uninvited guests.

2.3.1 Unrecognized Person

Upon the non-recognition of a person at the door, the robot shall not unlock or open the door, but shall immediately summon or go to the customer-owner.

2.4 Extensibility

The software shall allow for the "easy" extensibility as defined below:

2.4.1 Dishwashing

Future dishwashing capability shall be allowed for. The vision and manipulation modules shall be replaceable, or otherwise upgradable or adaptable.

2.4.2 Vacuuming

Future vacuum cleaning capability shall be allowed for. The vision and manipulation modules shall be replaceable, or otherwise upgradable or adaptable.

This page established February 19, 1998; last updated January 17, 2000.