Docstoc

High Level reqts Task Force

Document Sample
High Level reqts Task Force Powered By Docstoc
					High Level System Requirements Task Force Meeting: Summary of June 27, 2005, Discussion     Chris Hill opens meeting; thanks all for participating Round table introductions James Pol and Paul Pisano address group, thanking them for participation and reinforce need for critical stakeholder input Meeting strategy is to provide overview of process, then go through document page by page and gather comments (compile comments and document dispositions)

Process Overview  “High level requirements” defined as description of capabilities & attributes of system, specific to system as a whole, measurable quantitatively & qualitatively, achievable, & focused on outcomes o High level requirements may imply constraints on each other; conflict o Provide flexibility in design (as much as possible) o Testable only through child requirement o Not limited by time or funding o Subject to program constraints

High Level System Requirements in Context of Design Process: o Data Acquisition: What data? Where? How often? o Product: Who gets it? How used? How disseminated? How packaged? o Operations Management/Administration: Who operates and manages? What standards? What constraints? NOTE: During this meeting, participants should not dwell on how Clarus is to accomplish any of these goals; participants should focus on how to define/refine Clarus function & application.  Basis for Requirements: ConOps (May05 version), design contract, existing meteorological network experience, transportation standards (ITS Standards), meteorological standards, IT standards, & contractor experience Requirements vs. Design o Requirements precede design o Specify what is to be done o Specifies how its is done o Design ideas hiding in requirements may constraint or misdirect the final design; need to sift through to remove constraints/misdirection o Design has been generally been removed from the requirements by abstraction



Monday, June 27, 2005

1

General Comments         COMMENT: No weather service provider comments at table; no transportation-specific weather folks – do we have comments from these experts? RESPONSE: Document available to weather experts, not yet received comments COMMENT: Are we not focusing on specific design at this time? RESPONSE: Rather limit discussion to high level, but feel free to make comments COMMENT: A great deal of time spent on discussion specific req’ts during ConOps RESPONSE: The challenge now is to create a functioning system; to focus where we should spend energies COMMENT: Expedited timeline requires getting in the weeds quickly RESPONSE: Right now need agree on the higher view

Page 1  1.2 “enhance and extend”, never explain how – assumption that this document will not be read independently of the ConOps; refer back to the ConOps but ConOps not specific either; specificity should be refined through this meeting o ACTIONS: should include specific citations from reference document; still need to know how to distinguish between good and bad data (weather) 1.2 very highway oriented, missing other modes; very general/broad content overall o ACTIONS: use a generic word for pathway or guideway 1.2 very clear; provides enough focus, specify later, opening page is a guide 1.2 “expand” not creating new platforms; need to having growing coalition of participation in Clarus; VII considered a new platform, an expansion – distinction needs to be made; enhancing data sets only by quality control, not expanding surface collective o ACTIONS: need a statement of inclusion for state DOTs (need buy in from all communities; need to expand surface transportation first, weather community second) – also needs to be captured in the ConOps (check 6/24/05 version) 2



 

Monday, June 27, 2005



1.2. “real time responses to observed weather” – needs clarification; however, scope of Clarus very narrow; gut reaction to include discussion of needs of surface transportation weather information providers In general, no discussion regarding ownership of data; by model of having DOTs provide data to a service provider who provides it back to the submitter for a fee troubling; need to clarify the term “weather service provider” – data sharing agreement model in Canada, started out w/template, each province negotiating, requiring minor changes to template document 1.2 bullet 3; boundary layer extremely important; o ACTIONS: change “national” to “nationwide” 1.2 bullet 2; “national collection” perhaps better conveyed as “integration”; “observed weather” perhaps better conveyed by omitting “observed”; o ACTIONS: needs to be re-written for clarification – ConOps relays Clarus as “collection”, if there is a forecasting model needed, best know now – new forecasting tools would be a third-party opportunity Clarus not the first integration system; o ACTIONS: Revise to make very clear the difference between Clarus and current integration efforts “Hydrologic (water level)” or just “hydrologic” for various implications? -Fear of being to broad o ACTIONS: best to settle after ESS survey results are final and available; perhaps categorize hydrologic data



 





Page 2  2nd bullet; we are not developing models o ACTIONS: should be revised to reflect business decision support systems Second set of bullets; change 1st bullet change o ACTIONS: Revise to be more inclusive; revise to “state and local agencies and jurisdictions” Third set of bullets, 1st bullet; “Internet portal” – are we or are we not giving back data to state agencies? Clarify “subscribe” – design detail we are trying to keep away from in this discussion; Internet jargon; needs to be deferred



 

Monday, June 27, 2005

3

Page 3  ACTIONS: Update ConOps citation

Page 4  ACTIONS: 1.5 Provide specific IEEE citation

Page 5   2.1 “data” is plural o ACTIONS: need to use consistently 2.1, 2nd Paragraph, sentence 1 & 2: definition of “autonomous layer” does not reflect ConOps o ACTIONS: make consistent with final ConOps 2.1, 2nd paragraph: “collection” inaccurate word o ACTIONS: revise 2.1 3rd paragraph: o ACTIONS: need register symbols for search engines; change “initiative” to “system” 2.1 3rd paragraph: “quality tags” -- to what does this refer? Change to “quality assessments”? defines how good data is compared to other existing data o ACTIONS: add footnote, referring to ConOps

 



Page 6     Figure 1: showing linkages, not flow o ACTIONS: needs to be consistent with spec on p. 24 (Andy Stern) Replace “initiative” with “system”? network? Depending on reference to Clarus Will Clarus be using satellite data? Data image products? -- straying from topic 2.1 : o ACTIONS: Add after “climatological investigators” the words “and researchers”

Monday, June 27, 2005

4



2.1 Final paragraph: need to differentiate between “data record” and “data archive” – could affect quality assurance step o ACTIONS: Revise 2.1 In reference to “decentralized architectures”, o ACTIONS: Common ETL techniques need to be crafted (parking lot topic)



Page 7  2.2 Figure 2: each ellipse in an object is doing something; gray inside Clarus system, white are not – not a data flow diagram – very difficult to understand outside explanation o ACTIONS: add description of how figure works and provide examples; will revisit after revisions; perhaps investigate using an IDEF approach/figure (drill down concept easier to conceive for non-designers) 2.2 1st paragraph: “volume of data very large” – overstated; don’t want to see system take in too much information; initially, data volume will not be large o ACTIONS: Revise to be more specific in describing initial steps, leading to potential (VII) 2.2 1st paragraph: use of the word ”store” problematic due to orders of magnitude o ACTIONS: Revise Document in general: o ACTIONS: Tone language down and be more precise 2.2 ESS means “Environmental Sensor Station” o ACTIONS: Revise





 

Page 8  2.2 Table 1: Fixed and mobile ESS data -- do they collect pavement treatment information? It is in the standards as a capability; shows what the system should be capable of handling 2.2 Table 1: Should we be able to collect more roadway data? Currently, Andy Stern putting together template. Need to help educate to get States on board so others may use their data; there needs to process; metadata needs to be available with all data



Monday, June 27, 2005

5



2.2 Table 1: Pavement Sensor data: Snow depth (off roadway) – why? Sensors needs to be placed off the road; considered valuable data; realtime capability o ACTIONS: Revise to read as “on and off roadway”

Page 9   2.2 2nd bullet: ESS means “Environmental Sensor Station” o ACTIONS: Revise Time ranges: realistic estimates; recognize there will be some latencies (data access and data processing; unknowns are amount of data coming and number of cross-checks needed); some cases there will be built in latencies; currently reflects ConOps but may need to up time differentials

Page 10  2.3: o ACTIONS: Make same revisions to stakeholder list as indicated in 1.2, p. 2

Page 12  2.3 “Quality assurance” an institutional measurement; “quality control” more automated – do we really mean “quality assessment process”? Can’t “quality control” weather but we can qualify data through assessment; What does NCDC use? Regardless of the terms used, they must be defined by an authority – will check NCDC and PMI. o ACTIONS: Review definitions from NCDC and PMI; revise accordingly Are we looking at airport surfaces? Yes, if owned by State DOTs. Same with ferries – if a DOT puts a sensor on it, we want the data Homeland Security & EOCs: how would these work within Clarus? Another committee is dealing with this issue Figure 5 has Research and data archive as separate entities; why is this not reflected in the test on p. 13? o ACTIONS: Revise

  

Monday, June 27, 2005

6

Page 13  Transit is a two-way Clarus entity as shown in Figure 5, p. 12 – text needs to reflect this data share and usage o ACTIONS: Revise Document in general o ACTIONS: Clean up quality of figures



Page 14  2.4 prescriptive standards (Federal) on what is “critical”; can DOTs and weather services function without Clarus? Yes! Clarus is not critical; need to describe future applications of Clarus (potential) which would make system “critical”; mission vs. business critical – what level are we going to design to? “mission critical” would requires securing all of the assets; “business critical” status easier to justify but more complex for design o ACTIONS: Need to redefine “critical”, add column to requirements pages and define whether or not a requirement is critical to Clarus operation – revise to specify that is neither mission or business critical as defined by federal standards 2.4 final paragraph: not “desirable” but a must; o ACTIONS: Revise to read “shall” 2.5 1st paragraph, 2nd sentence: why only NWS data? o ACTIONS: Delete 2.5 2nd paragraph, 2nd sentence: o ACTIONS: replace “no” with “limited”

  

Page 15  2.5 1st full paragraph: add disclaimer to Internet portal? -- we want to develop and use a system no one wants to be accountable for? Appearance is everything – transportation liability is huge; Canada admits disclaiming quality tags, as well; Is this allowable under the model data sharing agreement, can we add it there? Value added to add question to ESS survey – who do you share with? Do you have a use-at-own-risk disclaimer?

Monday, June 27, 2005

7



2.5 2nd paragraph; “regional boundaries”: better to define by geospatial boundaries and then overlap regions? Problem in defining regions (ITS deployment, for example), user-defined product; this tactic may encourage state DOTs to sign the model data sharing agreements 2.5 4th paragraph: UTC does not stand for “Universal Time Code”; o ACTIONS: revise 2.5 Last sentence: new layer of requirements will show up here in the Detailed Req’ts phase; more constraints will be identified; software will be written to the standards for the interface o ACTIONS: Revise to read as “data base tools”

 

NOTE: Paul Pisano provided update on weather and ITS standards; TMDD.52 (1.0, new version) reference will need to be updated in document Session ends 5:15pm

Monday, June 27, 2005

8


				
DOCUMENT INFO
Shared By:
Stats:
views:17
posted:11/27/2009
language:English
pages:8
Description: High Level reqts Task Force