18-649 Project Assignment #3

Event-Triggered Behavioral Requirements

Due Thursday February 7, 2008 at 11:59 PM

Please submit all project-related correspondence to ece649-staff "at" ece.cmu.edu

This semester, your group will specify, design and build an elevator control system and use it to control a simulated elevator. You will learn of and deal with many of the details of building a distributed, real-time, embedded system.

In project 3, you will construct your full requirements from the scenarios/sequence diagrams in project 2 and demonstrate traceability.

For this part of the project you will finish writing your requirements for an Event-based System .   Follow the format of the "formula for behavioral requirements" you'll see in multiple lectures. A particularly important concern is that only one message can be used as the trigger for an action. If you need two messages to trigger an action, you will generally need to use multiple behavioral requirements and intermediate variables to do this. You can expect to probably need such intermediate variables in a few places, but not many.

Assignment:

Now let's use the scenarios & sequence diagrams from the last project to create the requirements.

For reference, here are the Use Case Diagram (CLICK HERE) and the Architecture Diagram (CLICK HERE). (also: .pdf version of architecture diagram)

We have provided the Behavioral Requirements Framework (CLICK HERE).

What you'll find in the document is the complete message dictionary for the elevator system and a set of behavioral requirements that is complete, except some are omitted and are your responsibility to fill in. Your job is to fill in the missing requirements and submit them to us as a list of numbered requirements following the numbering scheme used in the rest of the document. You should not worry about failure modes for this project phase; for the time being assume that all sensors and actuators are working at all times. You must NOT change the Constraints in this project phase.

You will also be doing traceability in this assignment, both from Sequence Diagrams to Requirements, and Requirements to Constraints. Here's a partial example for Sequence Diagrams to Requirements (CLICK HERE).
Here's a partial example for Requirements to Constraints.

*** Note that for project 3 you are not required to command the drive to a speed faster than Slow.  At Slow speed, the AtFloor[f, b] is essentially your commit point.  However, if you wish to control the elevator Drive at Fast speed, you need to calculate the commit point for the elevator based on the drive acceleration profile.

We want you to use the UML sequence diagrams you created in the last project to develop your behavioral requirements.  Here is the procedure for developing your behavioral requirements:

  1. Use the Scenarios and Sequence Diagrams from project 2 to generate your behavioral requirements for each control system object. We've provided some examples, but again, these are sub-optimal so you may want to write your own. Turn in the completed Requirements Framework.  Follow the format of the "formula for behavioral requirements" for an event-based system you'll see in multiple lectures. A particularly important concern is that only one message can be used as the trigger for an action. If you need two messages to trigger an action, you will generally need to use multiple behavioral requirements and intermediate variables to do this.

  2. Ensure traceability by annotating each text requirement you develop with the messages they correspond to in your Sequence Diagrams.  Each behavior could match up with zero or more Sequence Diagram messages, and each Sequence Diagram message should apply to at least one text behavior requirement.  There can be as many overlaps as necessary as long as every message is covered.  This is only required for messages going into and out of the controllers you are responsible for.
    You should have a team member DIFFERENT from the author of the behavioral requirements perform the traceability check on each Sequence Diagram. The team member who performs the check should record his/her name on the traceability check. Turn in the signed traceability check.   Complete and consistent traceability between your diagrams and documentation will be a major factor in your grade.

  3. You must also ensure traceability between the Requirements and Constraints for each object you develop requirements for. (For a single object, only trace to the Constraints of that object, not the Constraints for all objects). This is easily done using a table with the Constraints listed across the top and your Requirements listed along the side. You don't have to provide a detailed explanation - just use an 'X' if the Requirement directly supports the Constraint, and a '~' if the Requirement doesn't contradict the Constraint but doesn't directly support it. Turn in a Constraint to Requirement traceability check for each object you are responsible for writing requirements for. You will probably have at least one 'X' per column and at least one 'X' per row.
Each requirement should be less than 50 words, and all but the most complex should be less than 25 words. (If you have a requirement greater than 25 words long, then consider breaking it up into simpler requirements, perhaps using nested levels of numbering). Each requirement shall be less than 100 words and shall be a legitimate English sentence. Only the first 100 words of any numbered requirement will be graded. Hyphens and equal signs both count as spaces when determining word count.

Note that some elements of the system are "environmental". What this means is that we're going to implement them in the simulation and you don't have to (you're also not allowed to change them). The requirements for environmental portions are given so that you know what you can count on in terms of their behavior, and none of them have been omitted for this project assignment.

The only type of change you're allowed to make for this project phase is to add behavioral requirements for sections indicated in the document (DoorControl, DriveControl, LanternControl, HallButtonControl, CarButtonControl, CarPositionControl, Dispatcher). You must not change anything else about the specification, including (but not limited to) interface information for each object. While this may seem restrictive, we're doing this to ensure you take approximately the right path through the initial project design. You will get more flexibility later.

There may be some "bugs" in this assignment despite doing an independent review before release. If you find something suspicious please let us know immediately so we can fix it. Please see the course policy page for more info regarding the availability of course staff.

Team Design Portfolio:

Each team shall maintain a design portfolio to organize all materials for the design package of its elevator system.

1) Organize your design portfolio

Your project3 directory should contain the most up-to-date design package for your elevator system organized into the following directories.  This directory structure will develop as the semester progresses. This is to organize things for the rest of the course -- you'll be keeping this same organization and updating things for each subsequent project phase.

2) Ensure your design portfolio is complete and consistent.  The following is a partial list of the characteristics your portfolio should exhibit:

Handing In Results

Each team shall submit exactly one copy of the assignment. (Multiple HTML files are OK.)

Please include at the top of each file the assignment number, your group number, the names of your group members, and the file name.

Projects shall be submitted by copying all needed files into your group's directory in the course AFS space in the following directory:  /afs/ece/class/ece649/Public/project/group#/project#/
(group# is your group number and project# is the number of this project.  you may need to create this directory yourself)

Any submission that contains files with modification dates after the project deadline will be considered late and subject to a grade deduction (see course policy page for more information).

Submission shall be electronically in the form of a web page with text and in-lined images, in HTML 2.0 format, viewable from both MS Internet Explorer and Netscape Navigator.  (In other words, we want "plain-vanilla" html to eliminate problems printing and viewing.) Any drawings shall be in non-animated GIF format. (You can use other graphics formats at your own risk, but we must be able to view them in the web browsers mentioned above).  You can also submit your project in pdf format, but make sure it prints correctly on a postscript printer.    A regular text editor should be sufficient for this assignment - you may want to make the traceability tables in Excel or Word and use the 'Save as HTML' or 'Save as Web Page' feature in the File menu. If you need some help with HTML please come to Office Hours :)

Additionally, the result should be easily readable when printed on a black-and-white laser printer. Each HTML file AND picture shall include the team number and names of all members of the team.

This is probably a new experience for most of you. We don't expect perfection. We expect an honest, good-faith attempt to complete the assignment, getting as much help as is appropriate from your classmates and lab partners. We suggest you leave at least a week of time to think about the requirements. There is not too much writing for this project, but quite a lot of thinking. If you stumble we'll make sure you get fixed up before the next project segment, and in fact will hand out a complete set of requirements as the solution set. (BUT, if you really want to win the performance contest, you'll probably have to be a bit more clever than the baseline solutions we help people come up with...) You'll be allowed to change the behaviors in later labs for optimization and debugging, but you should give this your best shot. (In particular, we expect that people will take several project phases to create a good dispatcher, as some things just can't be specified well without a lot of experimentation.)

Grading (115 points):

This assignment counts as one team grade.
Grading will be as follows:

We want you to go through the process of developing behavioral requirements from UML scenarios and sequence diagrams. which is why we're requiring that you show traceability between them. Consistency and coherence are the two criteria we're looking for.

Back to course home page