18-649 Project 3
Event-triggered Behavioral Requirements and Traceability
course webpage for due dates
*Please submit all project-related questions to
- Dated entries will appear here if the project is updated after it has been
- Emphasized that the given time-triggered requirements does NOT need to be re-written into event-triggered requirements.
- 9/18: Updated minimum requirements spreadsheet.
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
In project 3, you will construct your full event-triggered requirements from
the scenarios/sequence diagrams in project 2 and demonstrate traceability
between the requirements and sequence diagrams.
For this part of the project you will finish writing your requirements for an
. Follow the format of the "formula for behavioral
requirements" you'll see in multiple lectures. A particularly important
concern for event-triggered design 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.
Now let's use the scenarios & sequence diagrams from the last project to
create the requirements for some controllers (DriveControl, LanternControl, HallButtonControl,
In this assignment, you SHOULD NOT re-write the given time-triggered requirements for some components
(DoorControl, CarPositionControl and Dispatcher) back to behaviorial requirements.
In a few cases, such as for the safety subsystem, behavioral requirements in the pre-provided project materials do not follow this event-based rule. That is because they have been implemented in a time-triggered style. You'll be changing to time-triggered in the next project. For this project, however, you must do all your work in an event-triggered style so you can understand how that approach to design works. (You do not need to re-do existing material in a time-triggered style unless it forms a part of the required hand-in items for this assignment.)
For reference, recall the design documents mentioned in Project 2:
This week, you'll be adding requirements to Behavioral Requirements II.
- Architecture diagram -
- Use Case diagram - architecture/usecases.html
- Behavioral Requirements I - System Object Descriptions and Message
Dictionary - reqs/requirements1.html
- Behavioral Requirements II - Distributed Controller Requirements -
- Issue Log - logs/issuelog.html
What you'll find in Behavioral Requirements I is the complete message
dictionary for the elevator system. In Behavioral Requirements II, you
will find 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. Your
portfolio includes a partial example of:
Note: 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
- Sequence Diagrams to Requirements traceability (
- Requirements to Constraints traceability (
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:
- 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.
Follow the format of the "formula for behavioral requirements" for an
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.
- 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
- Each requirement shall contain
exactly one verb. This will likely lead to multipart requirements when
the same IF part results in multiple THEN parts. In the example that
follows, R1.1a and R1.1b are considered to be separate (but related)
requirements that each include the common text stated in the R1.1 line.
So the word count for R1.1a is 7+8=15 words and R1.1b is 7+6=13 words.
R1.1 If mMessageX[f,b] is received as true, then (7
R1.1a State variable A shall be set to True. (8
R1.1b OutputY shall be set to False. (6 words)
- Ensure traceability by completing the Sequence Diagrams to Requirements
Traceability table. Expand the Excel template in the portfolio to include
a row for each requirement and a column for each sequence diagram arc. Be
sure to follow the instructions given in the notes page of the Excel
- Each behavior should match up with one or more Sequence Diagram messages
(complete backward traceability).
- Each Sequence Diagram message should apply to at least one text behavior
requirement (complete forward traceability).
- When tracing to multipart requirements (as in the example in #1 above), you
should trace to each subrequirement (with the understanding that it includes
the common text). So in example, you would trace to R1.1a and R1.1b, but
NOT R1.1 by itself.
- There can be as many overlaps as necessary as long as every Sequence
Diagram message and requirement is covered.
- If a requirement only sets a state variable and does not set any output,
then the requirement will not trace to any sequence diagram arc. In this
case, it is acceptable to trace it to the "Setting State Variable"
column in the traceability table.
- Some arcs in the sequence diagram will originate from system modules (like
the smart sensors). Since you do not have requirements for these objects,
just put a single entry for each system object in the System Modules section
and indicate the arcs that trace to that object.
- 7. If a requirement is related to a message that is not consumed by any controller,
you may trace it to the "Future Expansion" column. In the elevator, only messages that have no consumers
(e.g., mHallLight and mCarLight messages) can be traced to "Future Expansion
- Your traceability table must include all 7 of the controllers. For
the controllers that you did not write requirements for (DoorControl,
CarPositionControl and Dispatcher), you should trace to the requirements that
have been provided.
- You must 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 for each object should record his/her name on the
traceability check. Complete and consistent traceability between
your diagrams and documentation will be a major factor in your grade.
- 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. The team member who performs
the check for each object should record his/her name on the traceability
You should perform this traceability exercise for all 7 of the
controllers. For the controllers that you did not write requirements for
(DoorControl, CarPositionControl and Dispatcher), you should trace to the
requirements that have been provided.
- Issue Log - As you are working on requirements, you will likely find errors
or omissions in your sequence diagrams. If that happens, you must update
your sequence diagrams so that they are consistent, and track each modification
in your issue log. Finding bugs is not a bad thing! In fact, if a
team is not finding bugs, it is much more likely that they are not looking hard
enough than that there are no bugs to be found. It is possible (but not
likely) that you will not have any errors in your sequence diagrams, so there
are no points assigned for this part. But keep in mind that we can go
back and compare your current sequence diagrams to previous weeks, and we will
expect modifications to be logged, and you might have points deducted if it is
clear you are not making a good faith effort to track bugs in your project.
- Peer Review Log - You must complete a peer review checklist for each set of
requirements ie. one peer review per object. Record the results in a
review sheet and also complete a log entry into peer review log. Recording
defects on the peer review sheet does NOT result in point deductions. Be
honest. We just want to know if you found something or not in the review. If
you find something, you should fix it before handing in the assignment or else
note it in the issue log as an open issue.
- 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. You are not required to write requirements for these or perform
traceability on them.
The only types of changes you're allowed to
make for this project phase are
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.
- add behavioral requirements for sections indicated in the document
(DriveControl, LanternControl, HallButtonControl, and
- define new state variables for those control objects.
- perform traceability
- refine sequence diagrams (if you find errors).
- update the issue log with any errors you find and the fixes you make.
- improvements log entries.
It is OK to add additional scenarios and sequence diagrams as you like to get a
head start on future weeks, and the account for them in your behavioral
Here is the minimum requirement chart for this project. Each group member must:
Remember that every required element must appear at least once in the table in the row that it belongs to.
- Write requirements for at least one component
- Trace requirements to sequence diagrams for at least one component
Since this must be done for all 7 components, some group members will do more than one.
- Complete Requirements to constraints traceability for at least one component.
Again, this must be done for all 7 components.
- Complete at least one peer review of a set of requirements for a component they did not write.
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:
The portfolio you submit should contain the most up-to-date design package for
your elevator system organized into the following directories. You are going to update your portfolio every week, so be
sure to keep an up-to-date working copy of what you submit.
Files that you should update for this week are:
- Portfolio Table of Contents (as needed)
- Scenarios and Sequence Diagrams
- Improvements Log
- Issue Log
- Requirements II
- Sequence Diagrams to Requirements Traceability
- Requirements to Constraints Traceability
Ensure your design portfolio is complete and
The following is a partial list of the characteristics your portfolio should
- Changes requested by the TAs in previous projects have been applied.
- All required documents are complete and up-to-date to the extent required
by the projects (you do not need to update files or links related to future
- All documents include group # and member names at the top of the
document. (This includes code, where this information should appear in
the header field)
- Individual documents have a uniform appearance (i.e., don't look like they
were written by 4 individual people and then pieced together)
Handing In Results
Each team shall submit exactly one copy of the
Follow the handin instructions detailed in the Project FAQ
to submit your portfolio into the afs handin directory (
Be sure to follow ALL the portfolio
guidelines detailed in the Portfolio Layout page.
Any submission that contains files with modification dates after the
project deadline will be considered late and subject to a grade deduction
policy page for more information).
If you don't already have an ECE account send e-mail to email@example.com
and Cc to requesting a course account
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 set aside a couple days in order 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. 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
Grading (135 points total):
This assignment counts as one team grade. Be sure you follow the
hand-in formats described above. The grading criteria for project 3
can be viewed
. Please note that the grading rubric is only a general guideline
and that you are still responsible for all the details in the writeup. If
the grading rubric and the project writeup conflict, the project writeup takes
precedence. If you find a conflict, please let us know by sending mail to
the staff list. Grading will be as follows:
(40 points) - 10 points per
object for the requirements needed in the requirements framework (there are 4
objects total, because DoorControl, CarPositionControl and Dispatcher
are provided). You do not need to re-write the time-triggered requirements for those
components back into behaviorial requirements. Each member must do at least
(45 points) - 5 points per
object for the Sequence Diagrams-to-Requirements Traceability (there are 7
objects total, because the DoorControl, CarPositionControl and
Dispatcher need to be completed). PLUS 10 points for all the sequence diagram
arcs being traced to a requirement or system module.
Each member must do at least one object.
(25 points) - 5 points per object
for the Requirements-Constraints Traceability (there are 5 objects total,
because the DoorControl, CarPositionControl and Dispatcher need to be
completed, but there are no constraints for the HallButton and CarButton
controller.). Each member must do at least one
(20 points) - 5 points per object
for completing a
review of the requrements (there are 4 objects total, because DoorControl,
CarPositionControl and Dispatcher are provided).
Each member must do one review on a different
(5 points) - A list of which
points corresponding to which tasks were primarily completed by each team
member (every point must be assigned to a specific team member). An entry in
the Improvements Log that tells us what
can be improved about this project. If you encountered any minor bugs that we
haven't already addressed, please mention them so we can fix them. If you have
no suggestions, say so in your entry for this project.
(0 point. Must be completed or the project won't be graded) - The minimum requirement chart
that indicates the minimum work for each group member.
Please remember to replace "Member X" with your name & andrewID. An example can be found in project 2
Each team member must satisfy the minimum stated per-member requirements
(e.g., one object for each activity).
Team members who omit any required per-member activity will be penalized as
described on the course admin page.
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