Outline
Tonight
„ Course Overview (Phang)
„ Course Deliverables (Anderson)
„ Project Proposal (Phang)
„ Requirements Specification (Anderson)
„ The Need for Requirements (Gillett)
„ Effective writing and communication (Irish)
ECE496 Design Project
Course Seminar
Tuesday, Sept. 14, 2006
Next Tuesday
„ Question/answer session
1
ECE496 Goals
2
Annual ECE Design Fair
A capstone design project for ECE students to
1. Integrate their technical knowledge acquired through
their undergraduate education
2. Effectively communicate their ideas and work
3. Develop team work and project management skills
3
4
1
Awards
Support Resources
„ Website: https://ccnet.utoronto.ca/20069/ece496y1y
„ Books
Internal Awards
„
„
„
„
ALOHA Award ($10,000)
Gordon E. Slemon Design Award ($1k) – students and faculty
Centennial Thesis Awards (2)
MET - Fourth Year Thesis/Project Award in Networks & Applications
– P. Anderson, ECE298 System Design Course Notes
• Available on ECE496 website under ‘Handouts’
– J. Eric Salt and Robert Rothery, Design for Electrical and
Computer Engineers, Wiley, ISBN 0-471-39146-8
• In Eng. Library (5 copies on 2-hour short term loan)
• Sold at U.T. Bookstore
External Awards and Events
„ 2007 IEEE ICUE (International Conference for Upcoming Engineers)
at Ryerson University
„ IEEE Student Paper Award
„ Myron Zucker Industry Applications Student Design Award
„ IEEE Canada - TELUS Innovation Award
„ Design Centre (SFB520)
„ Your direct supervisor
„ Your section administrator
5
ECE496 Website Map
6
Design Centre
Course Description
- Course Description
- Project Categories
- Course Administrators
- Industry Involvement
Student Information
- What Section am I in?
- Deliverables/Evaluation
- Student Deliverables
- Deliverable Dates and Grading
- Project Proposal Guidelines
- Requirements Specification Guidelines
- Design Review Guidelines
- Individual Progress Report Guidelines
- Group Oral Presentation - Guidelines
- Group Oral Presentation - Schedule
- Group Design Fair - Guidelines
- Group Design Fair - Schedule
- Group Final Report
- Responsibilities
- Student
- Supervisor
- Section 1 to 7 Administrators
- Language Across the Curriculum
- Design Centre Technician
- Business Services Coordinator
- Webmaster
- Report Submission Procedure
- Guides
- ECE Design Centre
- Awards
- Resolving Personal Conflicts
- Intellectual Property Rights
- Health and Safety Guildelines
- Supervisor’s Almanac
„ Sandford Fleming, room B520
„ Borrow equipment, computers, lockers, make PCBs,
soldering station and microscope, wireless
transceivers,etc.
7
8
2
Know your Supervisor and Administrator
Section Administrators
1. Khoman Phang
2. Phil Anderson
3. Hans Kunov
5.Hamid Timorabadi
6. Dan Beresford*
7. Ross Gillett*
4. Kostas Plataniotis
Students
Supervisor
•The ‘expert client’
•technical guidance
• evaluation of progress
Administrator
• standardize marking
• guidance through design flow
• guidance of communication
*Industrial Administrator with ECE backup
9
Course Support Staff
10
Mark Normalization
„
„
„
„
Kelly Chan
(Registration)
Mark normalization ensures mark consistency across sections
Your marks can go up or down (slightly)
Marks heavily weighted towards final deliverables
Don’t overemphasize marks - focus on making a strong impression
with your supervisor and administrator
Mike Mehramiz
(Design Centre)
11
12
3
Student Responsibilities
ECE496 Overview
fall
spring
Design Fair
Done
Oral Report
Do It
Individual
Progress Report
Design Review
Requirement Spec
Start Decide What Decide How it is
it must Do
to be Done
Final Rep’t
„ Keep a copy of the ECE298 course notes and Supervisor’s Almanac
„ Meet regularly with supervisor and review feedback from marked
reports
„ Keep current your email address on course website
„ Understand responsibility of supervisor, student and administrators
„ Must petition if you hand in a deliverable late or if you fail to appear
for an oral presentation (need medical certificate in the event of
sickness)
„ Try to avoid issues with intellectual property (IP) by keeping your
profitable ideas out of ECE496
„ Assign a group representative for the team
Proposal
Deliverables
14
13
Fall
Spring
Proposal Sept 19
returned Sept 28 at “Meet Administrator”
Individual
Progress Report Jan 25 (?)
Oral Report
draft: Sept 26
Requirement Spec final: Oct 12
Jan - Apr
Final Rep’t Mar 22 (?)
between: workshops with Comm Centre
Design Fair
Apr 3-5 (?)
preparing for the Design Review: Oct 19
Design Review report: Oct 26
review meeting: Oct 28 – Nov 10
about the deliverables for spring: Nov 23
15
16
4
2006/2007 Schedule and Deliverables
Sept
2006
Oct
Notes on How to do Well
2007
Nov
Dec
Jan
Feb
Mar
Apr
Project Proposal
Requirements Specification (Draft)
Requirements Specification (Final)
Design Review
Exam & Holiday
Individual Progress Report
Reading Week
Oral Presentations
(tutorials)
Final Report
1. Self-manage. It is easy to “put off” work that has
no deadline, but this catches up with you.
2. Watch for long delivery times, long processes...
3. Look ahead to the design fair & final report.
4. Marks are NOT for (just) deliverables. Supervisor
will assign 50% based on his/her evaluation of
your work, including biggest chunk of the
“final report” mark.
5. Writing well helps, but you are COMMUNICATING
about your project. More later...
6. Have regular, focused meetings with your
supervisor.
Design Fair
18
17
To help you manage your supervisor:
Who is responsible for making sure
everything is done properly and
gets in on time?
not your supervisor
19
20
5
Other Stuff
1. $100 from every one of you. Extra money
available but very limited. Apply at time of design
review.
2. Many awards (ex: Aloha, worth $10k). Be sure to
apply.
3. Note treatment of research / competition projects.
21
22
Project Proposal
Project Proposal Sections
„ A group document
„ Due Tuesday Sept. 19th at 3pm. Place hard copy in
boxes outside SFB560, according to assigned section
(to be posted) Submit electronic copy on ECF network
using ‘submit’ command
„ a 3-page summary:
„
„
„
„
Evaluation Page (to be posted)
Title Page (to be posted)
Student-Supervisor Agreement
Background and Motivation
–
–
–
–
– what you want to do, your motivation, and what you hope to
accomplish
– a feasibility assessment of the project considering skills,
resources, and risks
A context for your project:
What is the design problem?
Why is the problem important?
What’s been done in the past?
„ Project Summary
– Project Goal statement
– Project Requirements – very brief, only key requirements
– Scope of Project – What is part of the project? What isn’t?
23
24
6
Project Proposal Sections (cont.)
„ Feasibility Assessment
– Skills and resources
– Risks
– Previous background work (if applicable)
26
25
Requirements Specification
Requirements Specification - Specifics
What the artifact must be
to do what it has to do
Executive Summary
• stand alone (no forward refs!)
• it is a summary, not an intro or conclusion
• one page. Executives don’t like to read!
ex:
1. Power consumption shall be under 10 watts.
2. Cost of production shall be under $200
3. Shall operate in the ambient temperature range
of -20 to +50 degrees Celsius
27
28
7
Requirements Specification - Specifics
Requirements Specification - Specifics
Background and Motivation
• where this fits in the world
• what technologies are in play
• appropriate comments!
Requirements
• they shall use “shall”
• they shall be measurable & testable
• they shall be traceable to the project goal
• constraints & functions go here
29
Requirements Specification - Specifics
30
Requirements Specification - Specifics
Test information
• outline how you are going to prove that
what you end up with meets your
requirements
Solution Space and Risk Identification
• where are you going to look for solutions?
• what are the tradeoffs? (objectives!!)
• what are the risks (possibilities of failure /
partial failure)
(if there are no risks, you need to talk to
your supervisor about getting a new
project)
31
32
8
Requirements Specification - Specifics
References
• use them (plagiarism is a University offence)
• use them (we expect you to back up your
information)
• use them properly
Requirements
Ross Gillett, M. Eng, P. Eng
Appendices
• support and extras
September 2006
33
34
R. Gillett, P.Eng. (2006)
Outline
•
•
•
•
•
Why Have Requirements?
• “I will cut and trim your grass for $25.00”
Why Have Requirements?
What Are Requirements?
Risks
Requirements Specification
How it is done in the Real World
• We all know that this means:
– Cut all of the area of the property to an even
length
– Trim the grass at the edges of the property
• Other, less common activities need more
definition .....
35
R. Gillett, P.Eng. (2006)
36
R. Gillett, P.Eng. (2006)
9
Why Have Requirements?
• What if they cut only one side, or one square metre
at the edge?
What Are Requirements?
• Requirements:
– Statements of verifiable attributes such as
• function, performance, mass, volume, ...
– They still 'cut and trimmed the grass'
• What was really 'required'
• How could we argue that it was not done?
• "Whenever a job or its completion criteria are not
completely defined - lawyers get rich"
• Specific, detailed characteristics of an engineering
project are documented as 'requirements'
– No implementation details
– Not a simple thing to create, usually involving
• Analysis, calculations, simulations
• Design insight (but not details)
• Compromises when conflicting needs arise
– Not just "words and fluff", this is true
engineering
37
R. Gillett, P.Eng. (2006)
38
R. Gillett, P.Eng. (2006)
What Are Requirements?
Risks
• You may not think if it, but you are
constantly planning ways to mitigate risk
• This course has identified 3 types:
– Functional Requirements
• What it can do, and how well
• Verifiable - you can answer the question 'Prove it’
– Constraints
• Boundaries within which design must remain
• Verifiable - you can answer the question 'Prove it’
– Buy insurance for car, house
– Take an earlier subway during exam week
– Extra calculator, pen, et cetera for exams
– Decide NOT to bungee jump, parachute, ...
• Risks are identified as 'bad events' that can
– Objectives
• Design goals that are not defined as precise values
(".. to the maximum extent", ".. as much as possible", etc)
39
R. Gillett, P.Eng. (2006)
– Make you unable to finish
– Make you unable to get your project to work
40
R. Gillett, P.Eng. (2006)
10
Why Bother? Why not
start designing?
Requirements Specification
• You Requirements Specification needs to
state clearly
– Goal, background, et cetera ...
– And the following essential elements:
• What you are doing (Requirements)
• How you will measure / prove / demonstrate that
it was done (Verification/acceptance tests)
• Solution space understanding and Risk
identification
• Be sure to read and follow the outline!
• Complex projects require multiple
– people
– companies
– countries
• Without a process involving
– analysis
– requirements decomposition/documentation
– verification
...... NOTHING could be built successfully
41
42
R. Gillett, P.Eng. (2006)
R. Gillett, P.Eng. (2006)
Why Bother? Why not
start designing?
Why Bother? Why not
start designing?
Complex Design by Multiple Individuals
(like your project!)
"Simple_design_by_one_individual"
+15V
9
7812
RED
- Voltage regulator to
accept 15 Vdc system
voltage
6
+12V
C1
10u +
25
V
+15V
C2
100
n
BLK
2
U1
TL082
3
- Correct input levels
to RF unit
- Correct connector
pinouts to Unit that I also
built
+
5
GRN
D3
Antenna
Output
Transmitter Chip Set
IRF
Z30
1
4
+12V
RP
1
330
k
RCS10C
Transmitter
Q1
8
-
R5
22k
- Comparators with
hysteresis needed
+12V
+15V
R4
51k
AUX Input
(Grip Enable)
+12V
- Centre Frequency
- Tracking Range
- Locking Range
- Jitter
OTX
STRBI
Transmit
Delay
Counter
(Tx_Delay_Ctr)
D1
R3
330
k
1
BLU
R1
100
k
R2
4k7
R6
510
R7
10k
D4
1N4007
R1
3
82k
D8 . .D39
D0 . .D7
ESTOP Out
8
Control
Word
Rx_Ok , Tx_Enable ,
Node_Addressed
3
Next_Block
Tx_Completed
+12V
Clear/Disable
1N4007
RDYI
Phase Lock Loop
GND
+12V
'1'
Transmit
Controller
To/
From
Receiv
er
Section
Control Word Output Enable
Echo Data (From Receiver
Section)
'0'
32
RP
2
1M
0
+12V
B0
B1
B3
A3
6
Q2
U1
TL082
C3
100
n
5
+
+12V
Transmit
Block ID
Counter
(Tx_Block_ID_Ctr)
IRF
Z30
7
4-Bit Magnitude
Comparator
A1
Transmitter Multiplexer
4
5_Blocks
A0
B2
ESTOP
R8
51k
R9
10k
R1
0
330
k
D2
R1
1
510
R1
2
10k
32
All_Sent
('A=B')
A2
- Interface Voltage levels
- Software Design
- Communication
Handshaking
DIP Switch Settings:
3,7 Closed
Others open
Clear_Disable
3
(2 Additional Strobes for Growth)
Transmit Block Selector
Circular Plastic
Connector
4
Pentium III with Parallel IO card
32 + Strobe
32 + Strobe
43
R. Gillett, P.Eng. (2006)
R. Gillett, P.Eng. (2006)
- Digital Logic / VHDL
- Hardware Interface Voltage levels
- Firmware/Software Interface Design
- Communication Handshaking
44
11
Requirements Decomposition
Example
Top Level
Definition
System Level
Requirements
First Level
Requirement
Decomposition
Second Level
Requirement Decomposition
(e.g. Drive Train)
Engine Output Torque:
(must meet or exceed specified torque/speed curve)
How it is done in the
"Real World" ...
Drive Train Output Torque:
> X kN-m
Transmission Gear Ratios:
1st gear: 5:1 2nd gear: 3:1 3rd gear: 1.5:1 4th gear: 1:1
Total Vehicle Mass:
< Y kg
Engine Mass:
< 500 kg
Acceleration:
0-100 km/h in 5 sec
Passenger
Vehicle
Engine Volume:
(must fit within engine compartment)
Payload Capacity:
2 adults
Passenger cab volume:
(must fit two adults)
Engine Fuel:
Gasoline
Internal Combustion
Engine
(i.e. not a diesel or
propane engine)
Colour:
Red
45
46
R. Gillett, P.Eng. (2006)
R. Gillett, P.Eng. (2006)
System Engineering Process
Example (cont)
Requirements Decomposition
• If this process continued, you could define
requirements for an entire vehicle
• All requirements shown can be verified
(demonstration, test, observation)
• At some stage, design decisions and
trade-offs must be made (creative process)
– i.e. the gasoline-powered engine could be a
piston type, or a rotary type like a Mazda RX-8
System Architecture
Definition Document
Functional Flow
Block Diagram
(UseCaseA)
Subsystem
Architecture
Definition Document
Detailed Design
(H/W, S/W,
Mech ...)
Layouts,
Part Lists,
Assembly
Functional Flow
Block Diagram
(UseCaseN)
*
System
Req'ts
Traceability
*
Subsystem
Req'ts
Requirements
Detailed
Design,
Manufacturing,
and Test
Documentation
* Verification
Ops Concept
47
R. Gillett, P.Eng. (2006)
Component
Req'ts
Test Reqts
and
Procedures
48
R. Gillett, P.Eng. (2006)
12
Your Project is Narrower
System Architecture
Definition Document
Functional Flow
Block Diagram
(UseCaseA)
Subsystem
Architecture
Definition Document
• Why follow a process?
Detailed Design
(H/W, S/W,
Mech ...)
Layouts,
Part Lists,
Assembly
Functional Flow
Block Diagram
(UseCaseN)
*
System
Req'ts
Traceability
*
Subsystem
Req'ts
Component
Req'ts
Requirements
Test Reqts
and
Procedures
Detailed
Design,
Manufacturing,
and Test
Documentation
* Verification
Ops Concept
Structured Design Process
–Structures the development and
representation of design as it evolves
–Keeps everyone on the "same page"
–Prevents preconceptions that can jeopardize
a design
49
50
R. Gillett, P.Eng. (2006)
R. Gillett, P.Eng. (2006)
F
Real World Example
i
t
l
ti
bl
Real World Example
• Example of Design Goal, Requirements,
and Detailed Design Implementation:
• The Goal or Requirements can be stated
as follows:
– The car "drives itself"
or
– The driver only needs to steer while the car
maintains speed
Cruise Control for a car
51
R. Gillett, P.Eng. (2006)
t
52
R. Gillett, P.Eng. (2006)
13
Real World Example
•
•
Real World Example
Both statements are true
Only one is accurate: #1 could be
(mis)interpreted as:
[This would require an intelligent
system, with vision, safety/legal issues
to be resolved, and other complexities]
• The expression of requirements must
be clear, or you can get enormous
misunderstandings regarding
complexity, safety, ….
Urban legend: Somebody set “cruise
control” on a camper van and then
began making his dinner in the back . . .
53
54
R. Gillett, P.Eng. (2006)
R. Gillett, P.Eng. (2006)
ECE 496
Communication
Overview
September 14, 20065
Robert Irish
Director of Engineering
Communication Program
55
56
14
PEY vs. no PEY
• Significant
disadvantage in
experience
documenting design
• Hopefully some
experience in workplace
• Need to work hard to
make sure you are
writing/presenting at a
level equal to your
peers
Writing vs. Documenting
• Advantage if you
learned from 298/299
• May be rusty from lack
of application
• Need to make use of
the concepts you
learned and the
resources you acquired
in 2nd yr.
• This
course
doesn’t
have any
• EVERY design activity
requires documentation to:
– Clarify specs, goals, design
– Communicate progress,
success, problems
– Demonstrate credibility of
selves, and of work
• Documentation itself is a
design activity
57
58
Documentation
Required Documentation
“Communication that describes events
to establish a common understanding of
completed or promised actions.”
59
•
•
•
•
•
•
Project Proposal (Group)
Requirement Specification (Group)
Progress Report (Individual)
Oral Presentation (Group)
Design Fair Poster (Group)
Final Report (Group)
60
15
Audience
Supervisor
• Knows project
• Knows subject
• Interests
4 stages of writing
Coordinator
• Knows project from you
• Knows general subject
• Interests
– details (module
development, testing)
– “mysteries” (problems
that emerge, creative
solutions)
– Big picture – system level
issues, module issues
– Testing procedures
– How problems are solved
1.
2.
3.
4.
Drafting
Revising
Editing
Proof-reading
61
Drafting
62
Revising versus Editing
•
•
•
•
Putting everything down on paper
Pulling out the main idea
Defining project purpose
Demonstrating how project fits in the
world, past present and future
• Determining measurable objectives
• Determining tests to prove objectives
are met
• Revising considers the central idea and
document as a whole
• Editing is primarily concerned with the
clarity of expression
• Proposal is a revised and edited version
of Proposal Concept Document
63
64
16
Revising
Editing
• May delete, add or shift whole sections
• Ensures that the document contains the
appropriate material
• Ensures material is in the appropriate
section
• Ensures connections between sections
are clear and logical
• Ensures the relationships between
ideas are explicit
• Ensures relationships are reinforced by
section and paragraph structure
• Ensures relationships between
sentences or points in lists
65
Proofreading
66
Resources
• Last thing you do
• Primarily concerned with error
• Refer to Hit Parade of Errors
http://www.utoronto.ca/hswriting/hitpara
de.htm
• 13 errors = 13 passes over document
Guides:
• Design and Writing Reference Texts
– ECE 298/299 Communication Course Notes
• Dictionary
• Hit Parade of Errors
• Revision Checklist
Engineering Communication Centre
http://www.engineering.utoronto.ca/English/ECP.html
67
68
17
Req. Spec. Draft meetings
• Drafts are due in hard copy at the
Engineering Communication Centre Tuesday,
September 26th by 3 p.m.
• Hand in Tutor Comment Form with the
draft!
• When you hand in your draft, sign up for a
meeting when whole group can attend
• On the draft, write down meeting letter and
time, e.g. Group L, Tuesday October 4, 3:30
p.m.
• Write meeting time in your calendars!
Purpose of meetings
• Feedback to help revision and editing
processes
• Questions to help you clarify your ideas
• Corrections to note patterns of error
69
3 Key Problems to Anticipate as
you prepare the Draft
1. Principle: Context before detail
• Problems
•
•
70
3 Key Problems to Anticipate as
you prepare the Draft
2. Principle: Justify claims
• Problems
No overview of system or project is
provided
Launch into details without context
•
•
71
Lack of clear, measurable quantitative
objectives
Lack of “proof” for process
72
18
3 Key Problems to Anticipate as
you prepare the Draft
3. Principle: Make LOGICAL transitions
• Problems:
•
Final Thought: How to make
Documentation “Value Added”
• Req. Spec. requires clear thinking early
– Value is in the thinking
Lack of connection from objectives to
design to verification
• Req. Spec. includes analysis of
“precedents” or alternative solutions
– Three months in the lab can save you three
days in the library
73
74
75
76
19