[IGSTK-Developers] Re: Extracting requirements from the bug tracker to latex file
David Gobbi
dgobbi at atamai.com
Tue Jun 21 15:47:50 EDT 2005
Oops, I see that you already thought of special characters... apologies.
David Gobbi wrote:
> 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
>>
>>
>
> _______________________________________________
> IGSTK-Developers mailing list
> IGSTK-Developers at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>
More information about the IGSTK-Developers
mailing list