View Single Post
  #3   Spotlight this post!  
Unread 09-03-2006, 15:10
KenWittlief KenWittlief is offline
.
no team
Team Role: Engineer
 
Join Date: Mar 2003
Location: Rochester, NY
Posts: 4,213
KenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond repute
Re: FIRST Engineering Principles

you are off to a good start. What you are really trying to do is impose requirements on your design team.

To make things more clear, and to help sort out your thoughts, do two things:

1. Change 'will' to 'shall'. Each shall denotes a requirement.

2. Now take each requirement and decide what test you are going to use at the end of the year to determine if your team has meet the requirements? Some things will start to jump out at you, for example: how do you test for 'early' or 'robust' ? People like to toss squishy words into requirements, but then how do you know if you succeeded? For example: we will make it better. How do you test for 'better' ? When you figure out what 'better' really means, put that down instead - be specific.

Once you have decided what you want your requirements to be, then the more difficult part comes, you must figure out how your team will do those things? You must come up with a design process that makes those things possible, otherwise all you have is a wish list, with no plan of action.

Last edited by KenWittlief : 09-03-2006 at 15:13.