[IGSTK-Developers] Re: Extracting requirements from the bug tracker to latex file

[David Gobbi]

Hi Andy,

The script will have to escape latex special characters, perhaps just 
escaping the latex comment character "%" will be good enough. The other 
common latex special characters are the backslash, curly braces, and 
square brackets.

- David

Andy Cedilnik wrote:

>Hi Again,
>
>And of course the attached file...
>
>       Andy
>
>Andy Cedilnik wrote:
>
>  
>
>>Hi All,
>>
>>Here is script that I can run every night. It produces the attached
>>file. Let me know if the format is ok.
>>
>>Current problems:
>>
>>* Handle special characters
>>* Do something with NEW_REQ_TEXT
>>
>>#!/usr/bin/env python
>>
>>import MySQLdb
>>import sys
>>
>>HOST      = '****'
>>DATABASE  = '****'
>>USER      = '****'
>>PASSWORD  = '****'
>>
>>
>>sql = MySQLdb.connect(db=DATABASE, host=HOST, user=USER, passwd=PASSWORD)
>>cursor = sql.cursor()
>>cursor.execute("SELECT bug_id, title, description FROM phpbt_bug WHERE
>>project_id = 10;")
>>
>>bugs = {}
>>comments = {}
>>
>>while 1:
>> res = cursor.fetchone()
>> if not res:
>>   break
>> if not bugs.has_key(res[1]):
>>   bugs[res[1]] = res
>> else:
>>   print "Problem!! Found two bugs with the same requirement:\n%s\n%s"
>>% (`res`, `bugs[res[1]]`)
>>   sys.exit(1)
>> comments[res[1]] = []
>>
>>ks = bugs.keys()
>>ks.sort()
>>
>>for a in ks:
>> if a.startswith("REQ"):
>>   bug = bugs[a]
>>   print "\section{%s - %d}" % (a, bug[0])
>>   print "%s" % bug[2]
>>   print ""
>>   cursor.execute("SELECT comment_text FROM phpbt_comment WHERE bug_id
>>= %d;" % bug[0])
>>   while 1:
>>     res = cursor.fetchone()
>>     if not res:
>>       break
>>     print res[0]
>>
>> 
>>
>>    
>>
>
>
>  
>
>------------------------------------------------------------------------
>
>\section{REQ 04.01.01 - 1068}
>IGSTK components shall execute a high-level task autonomously requiring minimal interaction.
>
>Discuss and verified this REQ on October 7.
>\section{REQ 04.01.02 - 1069}
>IGSTK components shall not expose underlying class structure in header files.
>
>Discussed and verified this requirement on 10/7/2004
>\section{REQ 04.02.01 - 1070}
>At a minimum, IGSTK shall support general components for tracker capabilities, viewer capabilities, segmentation, and registration.
>
>Discussed and verified this requirement on 10/7/2004.
>\section{REQ 04.02.02 - 1071}
>The IGSTK platform shall include a minimum of two application examples.
>
>Discussed and verified this requirement on 10/7/2004
>\section{REQ 05.01.01 - 1072}
>IGSTK components that manage events shall include threading capability.
>
>Discussed and verified this requirement on 10/7/2004.
>\section{REQ 05.02.01 - 1073}
>A test case shall be included for each IGSTK component.
>
>Discussed and verified this requirement on 10/7/2004.
>\section{REQ 05.02.02 - 1074}
>Each IGSTK components must have 100% testing coverage.
>
>Discussed and verified this requirement on 10/7/2004.
>\section{REQ 05.03.01 - 1075}
>IGSTK components shall enable compilation via CMake.
>
>Discussed and verified this requirement on 10/7/2004.
>\section{REQ 05.03.02 - 1076}
>Each IGSTK components shall be documented with corresponding DOxygen files.
>
>Discussed and verified this requirement on 10/7/2004.
>\section{REQ 05.04.01 - 1077}
>Each IGSTK component must be controlled by the IGSTK internal state machine code.
>
>Discussed and verified this requirement on 10/7/2004.
>\section{REQ 05.05.01 - 1078}
>Each configuration management action must be supported by a requirement number.
>
>Discussed and verified this requirement on 10/7/2004.
>\section{REQ 05.06.01 - 1246}
>The IGSTK platform shall contain a general communication component that acts as a proxy to all communication ports to and from the application such as the serial/parallel ports or wireless connectivity.
>
>Verified via discussions on October 26.
>\section{REQ 05.07.01 - 1247}
>The IGSTK platform shall contain a general logging capability that can encapsulate logging capabilities for all IGSTK components.
>
>NEW_REQ_TEXT: The IGSTK platform shall contain a general, centralized logging capability that can be used for all IGSTK components.
>Requirement verified at October 26th meeting.
>\section{REQ 05.07.02 - 1248}
>The logging capability shall support timestamps for the audited information.
>
>Requirement verified on October 26th meeting.
>\section{REQ 05.07.03 - 1249}
>The logging capability shall enable logging for multiple components concurrently and support auditing into multiple files.
>
>Requirement verified at October 26th meeting.
>\section{REQ 05.07.04 - 1900}
>Each IGSTK component should be enable with logging capability using the PrintSelf function
>
>\section{REQ 06.01.01 - 1082}
>The tracker component shall have the ability to initialize the tracker hardware.
>
>Additional comments
>Discussed and verified this requirement on 10/7/2004.
>\section{REQ 06.01.02 - 1083}
>The tracker component shall have the ability to reset the tracker hardware.
>
>Discussed and verified this requirement on 10/7/2004.
>\section{REQ 06.01.03 - 1084}
>The tracker component shall have the ability to start and stop tracking independent of the tracker hardware.
>
>Discussed and verified this requirement on 10/7/2004.
>\section{REQ 06.01.04 - 1085}
>The tracker component shall have the ability to restart the tracker hardware.
>
>Discussed and verified this requirement on 10/7/2004.
>\section{REQ 06.01.05 - 1086}
>The tracker shall incorporate a state machine that supports the following states: Tracker Off, Tracker On But Invalid (Not Initialized), Track Available But Tools Not Valid, Track Available With Valid Tools, Tracker Tracking.
>
>NEW_REQ_TEXT: The tracker shall incorporate a state machine that, at a minimum, supports the following states: IdleState, CommunicatingState, ToolsActiveState, TrackingState, SetUpCommunication, SetUpTools, StartTracking, UpdateToolsStatus, StopTrackingCommunicatingState.
>Discussed and verified this requirement on 10/7/2004. 
>1. The state machine transition methods need to be defined. 
>2. SetUpCommunication and SetUpTools methods should not be made available for use. Instead these functionalities should be made part of initialization.
>3. Access method for tool status should be made available.
>
>\section{REQ 06.02.01 - 1087}
>The tracker component shall have an integrated module to support logging that can be enables or disabled at initialization time.
>
>NEW_REQ_TEXT: The tracker component shall have an integrated module to support connectivity to the logging capability.
>Discussed and verified this requirement on 10/7/2004. 
>\section{REQ 06.02.02 - 1088}
>The tracker component shall have an integrated module to support the loading configuration files and the management of the configuration data.
>
>Discussed and verified this requirement on 10/7/2004. 
>\section{REQ 06.02.03 - 1089}
>The integrated configuration file management component must support configuration files in the Extensible Markup Language (XML).
>
>Discussed and verified this requirement on 10/7/2004. 
>\section{REQ 06.02.04 - 1091}
>The tracker component shall have a non-limiting design to support up to 10 tools connected to a specific tracker hardware.
>
>NEW_REQ_TEXT: The tracker component shall have a non-limiting design to support at least 4 tools connected to a specific tracker hardware. 
>Discussed and verified this requirement on 10/7/2004. 
>\section{REQ 06.02.05 - 1092}
>The tracker component must allow a tool refresh rate at initialization time which checks the status of the tool at the frequency of that rate. The default tool refresh rate will be the same refresh rate as the tool.
>
>NEW_REQ_TEXT: The tracker component will verify if the rate requested by the user is lower or equal than the rate supported by the tracker, if the requested rate is higher then the tracker component should create an exception.
>Discussed and verified this requirement on 10/7/2004. 
>\section{REQ 06.02.06 - 1093}
>The tracker component shall support diagnostic procedures that occur at the frequency of the tool refresh rate when a tool is substituted or disabled.
>
>NEW_REQ_TEXT: The tracker component shall support diagnostic procedures that occur at the frequency designated by the application developer to determine when a tool is substituted or disabled.
>Discussed and verified this requirement on 10/7/2004. 
>\section{REQ 06.02.07 - 1094}
>The tracker component shall have multiple levels of diagnostic support. At the highest level, a component and human diagnostic must be executed at the insertion of each new tool.
>
>NEW_REQ_TEXT: The tracker component shall have multiple levels of diagnostic support. At the highest level, a component and human diagnostic must be executed at configuration time.
>Discussed and verified this requirement on 10/7/2004. 
>\section{REQ 06.02.08 - 1095}
>The tracker component shall have an open interface to the viewing component using a universally-acceptable data structure.
>
>Discussed and verified this requirement on 10/7/2004. 
>\section{REQ 06.02.09 - 1096}
>The tracker component interface should send messages to that at a minimum contain position, orientation, quality (error), number of tools, and tool identification.
>
>NEW_REQ_TEXT: The tracker component interface should send messages at a minimum comprising position, orientation, quality (error), number of tools, and tool identification.
>Discussed and verified this requirement on 10/7/2004. 
>\section{REQ 06.02.10 - 1097}
>The tracker component shall report its refresh rate and time latency on demand.
>
>NEW_REQ_TEXT: The tracker component shall report the maximum refresh rate and time latency on demand.
>Discussed and verified this requirement on 10/7/2004. 
>\section{REQ 06.02.11 - 1098}
>The tracker component shall support a hot swapping routine that consists of ….
>
>NEW_REQ_TEXT: All tracker tools must be installed and verified at initialization time.   Tracker will only support hot swapping for tools that enable this capability.
>Discussed and verified this requirement on 10/7/2004. 
>\section{REQ 06.02.12 - 1099}
>The tracker component must confirm that the tools are at the same refresh rate as the tracker hardware.
>
>Discussed and verified this requirement on 10/7/2004. 
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>IGSTK-Developers mailing list
>IGSTK-Developers at public.kitware.com
>http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>  
>