[Mep-dev] OHL and informal requirements review

Michelle w5nyv@yahoo.com
Wed, 10 Dec 2008 08:41:37 -0800 (PST)


--0-449849765-1228927297=:91239
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

First, Thank you for being part of MEP! I'm highly optimistic about the pro=
ject and greatly enjoy working on it.=0A=0ASecond, there has been some inte=
resting activity on the hpsdr list, and I thought I'd highlight what I thin=
k might be=A0pertinent to MEP. HPSDR (High Performance Software Defined Rad=
io)=A0is a narrowband SDR project from=A0Tuscon Amateur Packet Radio=A0(TAP=
R). =0A=0ATAPR's Open Hardware License is what we've adopted=A0as our hardw=
are license for MEP.=0A=0AFind the full text on the=A0TAPR OHL website (htt=
p://www.tapr.org/ohl.html)=0A=0AFollowing the discussions on the hpsdr list=
 got me thinking about how teams manage to get things done. While we'd like=
 for it to be an exact science, getting things done often has to resort to=
=A0what might be described as an ad-hoc process. =0A=0AAny group that tries=
 to do something has to be able to get from choices to decisions to accompl=
ishments. A choice is an intention to do something. A=A0decision is a choic=
e with a plan and someone responsible for doing it. An accomplishment is wh=
at's produced from completing the plan. Things that work are what we want. =
Things that don't work will teach us what not to do. =0A=0AThe exploratory =
phase (what we're doing right now)=A0is mainly about choices. We are going =
to be moving towards decisions, which=A0means making some sort of commitmen=
t=A0of time. =0A=0AIt goes without saying, which usually means that it shou=
ld be said more often: =0AYour time and talent are greatly valued. Any amou=
nt of time is appreciated, and I will do all that I can to make sure that i=
t counts.=0A=0AWhat are the requirements we've come up with so far? This is=
 an informal check-up of our discussions so far. I'd like to update the req=
uirements list and project description for the project overview at http://w=
ww.delmarnorth.com/microwave/overview/MicrowaveEngineeringProjectOverview.p=
df=A0=0A=0AMEP:=0ATransmits duplex data=0ASupports a 10MHz bandwidth=0AOper=
ates as a fully functional IP network=0AOperates as a fully functional Ethe=
rnet node=0AProvides point-to-(multipoint) and multiple access communicatio=
ns=0AUses existing protocols and hardware whenever possible=0AComplies with=
 a fully specified air interface=0ASupports discovery functions=0AIs capabl=
e of=A0satellite simulation=0ACan=A0operate as a satellite ground station=
=0ASupports experimentation=0AIs portable=0A=0AAre these requirements valid=
?=0AWhat=A0major requirements=A0are we=A0missing?=0A=0AThe goal of=A0explor=
ation=A0is to produce a set of requirements that we believe to the best of =
our knowledge=A0cover the project. We then analyze those requirements with =
more emphasis on what particular resources are needed to fulfill the requir=
ements and start to commit to particular paths. If we find we've been incom=
plete about defining the requirements, then we cycle back through by adding=
 the requirement, analyzing=A0it with particular respect to what other requ=
irements are affected, and then=A0proceeding to design. =0A=0AMore soon,=0A=
-Michelle
--0-449849765-1228927297=:91239
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><DIV>First, Thank you for being part of MEP! I'm highly optimistic about the project and greatly enjoy working on it.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Second, there has been some interesting activity on the hpsdr list, and I thought I'd highlight what I think might be&nbsp;pertinent to MEP. HPSDR (High Performance Software Defined Radio)&nbsp;is a narrowband SDR project from&nbsp;Tuscon Amateur Packet Radio&nbsp;(TAPR). 
<DIV>&nbsp;</DIV>
<DIV>TAPR's Open Hardware License is what we've adopted&nbsp;as our hardware license for MEP.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Find the full text on the&nbsp;TAPR OHL website (<A href="http://www.tapr.org/ohl.html"><FONT color=#810081>http://www.tapr.org/ohl.html</FONT></A>)</DIV>
<DIV>&nbsp;</DIV>
<DIV>Following the discussions on the hpsdr list got me thinking about how teams manage to get things done. While we'd like for it to be an exact science, getting things done often has to resort to&nbsp;what might be described as an ad-hoc process. </DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV>Any group that tries to do something has to be able to get from choices to decisions to accomplishments. A choice is an intention to do something. A&nbsp;decision is a choice with a plan and someone responsible for doing it. An accomplishment is what's produced from completing the plan. Things that work are what we want. Things that don't work will teach us what not to do. </DIV>
<DIV>&nbsp;</DIV>
<DIV>The exploratory phase (what we're doing right now)&nbsp;is mainly about choices. We are going to be moving towards decisions, which&nbsp;means making some sort of commitment&nbsp;of time. </DIV>
<DIV>&nbsp;</DIV>
<DIV>It goes without saying, which usually means that it should be said more often: </DIV>
<DIV>Your time and talent are greatly valued. Any amount of time is appreciated, and I will do all that I can to make sure that it counts.</DIV>
<DIV>&nbsp;</DIV>
<DIV>What are the requirements we've come up with so far? This is an informal check-up of our discussions so far. I'd like to update the requirements list and project description for the project overview at <A href="http://www.delmarnorth.com/microwave/overview/MicrowaveEngineeringProjectOverview.pdf">http://www.delmarnorth.com/microwave/overview/MicrowaveEngineeringProjectOverview.pdf</A>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>MEP:</DIV>
<DIV>Transmits duplex data</DIV>
<DIV>Supports a 10MHz bandwidth</DIV>
<DIV>Operates as a fully functional IP network</DIV>
<DIV>Operates as a fully functional Ethernet node</DIV>
<DIV>Provides point-to-(multipoint) and multiple access communications</DIV>
<DIV>Uses existing protocols and hardware whenever possible</DIV>
<DIV>Complies with a fully specified air interface</DIV>
<DIV>Supports discovery functions</DIV>
<DIV>Is capable of&nbsp;satellite simulation</DIV>
<DIV>Can&nbsp;operate as a satellite ground station</DIV>
<DIV>Supports experimentation</DIV>
<DIV>Is portable</DIV>
<DIV>&nbsp;</DIV>
<DIV>Are these requirements valid?</DIV>
<DIV>What&nbsp;major requirements&nbsp;are we&nbsp;missing?</DIV>
<DIV>&nbsp;</DIV>
<DIV>The goal of&nbsp;exploration&nbsp;is to produce a set of requirements that we believe to the best of our knowledge&nbsp;cover the project. We then analyze those requirements with more emphasis on what particular resources are needed to fulfill the requirements and start to commit to particular paths. If we find we've been incomplete about defining the requirements, then we cycle back through by adding the requirement, analyzing&nbsp;it with particular respect to what other requirements are affected, and then&nbsp;proceeding to design. </DIV>
<DIV>&nbsp;</DIV>
<DIV>More soon,</DIV>
<DIV>-Michelle</DIV></div></body></html>
--0-449849765-1228927297=:91239--