TN0005 - Requirements Traceability through OpenERP Communication - Towards Automatizing...

TPR-PROJECT-17September2015-AlexandreTriay-1-1

Project name (and logo if any)

Ref: TPR-Project-17September2015-AlexandreTriay-1-1

Requirements Traceability throughOpenERP Communication: Towards

Automatizing Documentation

Technical Note

Requirements Traceability through OpenERPCommunication: Towards Automatizing Documentation

Internal reference

Neuroelectrics Barcelona S.L.U.Avda. Tibidabo, 47bis

08035 Barcelona, Spainhttp://www.neuroelectrics.com

The copyright in this document is vested in Neuroelectrics Barcelona S.L.U. This document may only be reproduced in whole or inpart, or stored in a retrieval system, or transmitted in any form (electronic, mechanical, photocopying or otherwise), only with the

prior written permission of Neuroelectrics Barcelona SLU.

Commercial in Confidence

Main Author Project Manager Collaborators Approved by

Table of Contents1 Introduction and Set-up................................................................................................................................. 4

1.1 Doxygen Documentation Software.......................................................................................................51.2 LaTeX................................................................................................................................................... 51.3 Qt/C++: IDE and MinGW Compiler.......................................................................................................6

2 Building Odoo Traceability Module...............................................................................................................72.1 Odoo as a Database............................................................................................................................. 72.2 Traceability Module Structure...............................................................................................................72.3 Beyond Variables: Table Methods.......................................................................................................10

3 Generating Specification Documents (SRS, SDIS, HLDF): Retrieving data from Odoo..............................123.1 Types of Specification Documents......................................................................................................123.2 Specification Documents Generator...................................................................................................14

3.2.1 Technical information................................................................................................................... 154 Joining Doxygen/C++ Source Code with Odoo...........................................................................................16

4.1 Doxygen Configuration File................................................................................................................. 174.2 Custom Made Program ...................................................................................................................... 18

4.2.1 Creating the Traceability Matrix...................................................................................................184.2.2 Building the LaTeX Table.............................................................................................................19

4.3 Integrating the Steps in the Qt Building Process.................................................................................204.3.1 Doxygen Build Step..................................................................................................................... 204.3.2 Custom-made Application Build Step...........................................................................................21

4.4 Compile LaTeX Output........................................................................................................................ 21 ................................................................................................................................................................. 22

5 Full Traceability Table Generation: Requirements Validation......................................................................236 References................................................................................................................................................. 257 Appendix (C script)..................................................................................................................................... 27

Index of Figures

Figure 1: MiKTeX Portable Edition....................................................................................................................6Figure 2: Odoo Tables....................................................................................................................................... 8Figure 3: Requirement creation options............................................................................................................8Figure 4: Requirement class in Python file: fields definitions ...........................................................................9Figure 5: Requirement form in XML file: fields display......................................................................................9Figure 6: Example of a table function: “name_get” method override..............................................................10Figure 7: Example of a table function: “create” method override.....................................................................11Figure 8: Kanban view of requirement table in Odoo......................................................................................11

Figure 9: SRS document: requirements list by sections..................................................................................12Figure 10: SDIS document: design inputs list by sections..............................................................................13Figure 11: SDIS document: traceability table..................................................................................................13Figure 12: HLDF document: compliance table................................................................................................14Figure 13: GUI of Specification Documents Generator...................................................................................14Figure 14: Traceability Command................................................................................................................... 16Figure 15: Traceability Table from previous figure command..........................................................................16Figure 16: New Chapter Created ................................................................................................................... 17Figure 17: New Section Created .................................................................................................................... 18Figure 18: Doxygen Configuration in Qt Creator.............................................................................................20Figure 19: Custom-made Application Configuration in Qt Creator..................................................................21Figure 20: Full Traceability Table Generator...................................................................................................23Figure 21: Full Traceability Table.................................................................................................................... 24

Index of Tables

1 Introduction and Set-up

The following two paragraphs definition was extracted from Wikipedia:

“Requirements traceability is a sub-discipline of requirements management within software developmentand systems engineering. Requirements come from different sources, like the business person ordering theproduct, the marketing manager and the actual user. These people all have different requirements on theproduct. Using requirements traceability, an implemented feature can be traced back to the person or groupthat wanted it during the requirements elicitation. This can be used during the development process toprioritize the requirement, determining how valuable the requirement is to a specific user. It can also be usedafter the deployment when user studies show that a feature is not used, to see why it was required in the firstplace.

Requirements Traceability is concerned with documenting the relationships between requirements andother development artefacts. Its purpose is to facilitate: the overall quality of the product(s) underdevelopment; the understanding of product under development and its artefact; and the ability to managechange. Not only the requirements themselves should be traced but also the requirements relationship withall the artefacts associated with it, such as models, analysis results, test cases, test procedures, test resultsand documentation of all kinds.”

In a few words, requirements traceability is a fundamental step in software development, since it givesevery piece of source code a reason for existence. However, properly documenting the source code withassociated requirements and keeping this relation up-to-date can be a very tedious, delicate, prone to humanerrors step. Slightly modifying one requirement, as a project evolves, could already affect many pieces ofsource code and documentation changes. For this reason, it is almost necessary to develop a way of semi-automatizing the process.

There are several private software companies that are already offering solutions to this problem, but theyare usually very expensive and do not fully meet our needs. Thus, it's not reinventing the wheel, but lookingfor a cheap, company-specific solution within Neuroelectrics that allows for the same requirementstraceability. We hereby present a set of simple, economic and integrated tools that will save us from somework when developing software projects. It starts with defining and modifying the requirements on adatabase. Particularly, we will use Odoo (previous OpenERP). Not only the requirements will be specifiedthere, but all the artefacts associated, such as requirements' validation, project layers of software, designinputs and their associated tests and result, etc. After the database being filled with this information, differentdocuments might be generated from this relational structure: Software Requirements Specification (SRS),Software Design Inputs Specification (SDIS) or High Level Design File (HLDF). Then, while a softwaredeveloper or a software tester are working within a software project, they will only need to comment in thesource code consistently with the database records, and software documentation will be generatedaccordingly.

Now, there are several steps to consider when semi-automatizing such process, from documentationsoftware until output visualization. It is user's responsibility to know which programs are needed for each partof the process. For Odoo database managing there is no need of installing programs, to generatespecification documents it will be necessary to have a MikTeX compiler for LaTeX, and softwaredevelopers/testers will need all Qt/C++, Doxygen and MikTeX, with proper build steps configuration (thisconfiguration is aided in the following sections).

First of all, we need a documentation software which is able to detect a certain custom-defined string andproperly include it into the generated documentation. Since all used programs were open-source, the outputof the documentation software was not ideal by default. It was needed to take this output and modify itaccording to our expectations. Therefore, whenever some extra or complementary step was required, wedeveloped custom-made C++ code.

The machine used had Windows 7 installed. Needed open-source external programs can be downloadedfrom the Internet. The technical note is organized chronologically with the process steps, in which non-default or non-trivial information is included. Before that, set-up of used programs is aided.

1.1 Doxygen Documentation Software

Note: A doxygen version of 1.8.10 or higher is needed for our purpose.

A documentation program which is able to read certain user-defined commands from the sourcecode is the core basis of the process. We will use Doxygen, the most standard tool to generatedocumentation from source code. It is mainly used for C++ programming language. Documentation can becreated in multiple formats. We have used HTML, Rich Text Format (RTF) and LaTeX documentation so far,but we are specially interested in LaTeX this time. Whereas for HTML and RTF no additional steps arerequired, compilation has to be performed on generated LaTeX documentation (see Section 4.3.1).

Binary distribution of Doxygen for Windows can be found here. The self-installing archive isrecommended. It will be installed by default in C:\Program Files\doxygen and added to environment path (wewill benefit from this fact). Doxygen includes a front-end user-friendly GUI called Doxywizard (C:\ProgramFiles\doxygen\bin) to facilitate modifications on the configuration files.

We downloaded and executed the following file from the official site:

doxygen-{latest_version}-setup.exe (18.3MB) ( ftp | http )This is a self-installing archive that includes the HTML and compressed HTML versions of the manual and the GUI frontend. It bundles 32-bit and 64-bit versions of doxygen.exe, and will install the right one based on the OS.

1.2 LaTeX

Another basic tool we need is a LaTeX editor program, together with a LaTeX implementation.Whereas there is total flexibility about the editor you use (we used portable TexMaker), MiKTeX is stronglyrecommended when comes to the implementation. We used the MiKTeX portable edition for Windows 32-bitwhich can be downloaded from here.

Figure 1: MiKTeX Portable Edition

Now, Doxygen will use MiKTeX functionalities when generating its LaTeX output. Therefore, we needto add miktex/bin folder to the environment path when running Doxygen. Usually, MiKTeX already caresabout that and does it automatically, but sometimes it is done incorrectly or not done at all. For the portableversion, we will need to execute miktex-portable.cmd in the installation folder.

Note: We had an issue here with paths. For the portable version we installed, the folder added topath was ..\miktex-portable\miktex/bin, which is incorrect since the last separator has to be a backslash andnot a slash. Doxygen did not recognize this as a valid folder and threw an error. You can see if the path hasbeen added correctly by executing

>> PATH

in a command prompt. Whenever a problem happens, add the folder manually to path. Open acommand prompt and type

>> PATH={yourInstallationFolder}\miktex-portable\miktex\bin;%PATH%

It is also important for the editor to be able to find the MiKTeX installation path. If added permanently(Control Panel\System and Security\System and then Change Settings > Advanced > EnvironmentVariables) you will not have a problem again. If done like above mentioned, you will need to do it each timeyou restart the computer. However, it is not recommended to add variables to path permanently unlessnecessary.

1.3 Qt/C++: IDE and MinGW Compiler

We will need a software development interface for C++. Qt with Qt Creator is encouraged, since ithas an easy way to add build steps which we will use later in the process. By adding the proper build steps,when building the software project we will have already generated the software documentation andtraceability tables (all gathered in .tex files), and we will only be one simple step away from having the PDFdocumentation.

Free version of Qt can be found here. This corresponds to the “Community” version, where nolicense fees apply. Select the recommended download for each specific computer. An out-of-the-box Qtinstallation will already provide with all needed tools for the process, user-friendly notepad included. Sincewe will be creating custom-made C code apart from the project we want to document, the MinGW Qtcompiler will do.

2 Building Odoo Traceability Module

2.1 Odoo as a Database

Odoo is a suite of open-source enterprise management applications (OpenERP). Choosing Odoo as thedatabase to use was mainly because Neuroelectrics already had experience with it, and was using it foraccounting, resource planning, tasks and employees management, etc. Also, because it is open-source andvery modular, which allows for an inexperienced programmer to quickly get familiar with its structure.Together with its fabulous documentation and community of users, we were able to develop a module called“Traceability” from scratch.

Odoo modules are written in both object-oriented Python language (where class definitions and methodsare defined) and XML (which allow for views definition). Each Python class corresponds to a table of objectsin the database server and has its own XML views. The full code can be seen in the supplementary files, buta brief description of the module follows.

2.2 Traceability Module Structure

The Traceability module inherits the Odoo Project module, in which projects such as MatNIC or NICHomeare defined. Each project will have a set of requirements to be accomplished. This requirements are definedwithin sections (eg. External Interface Requirements section, Functional Requirements – Device connectionand management section, etc.). Each requirement is associated to one or more design inputs, which wouldbe more technical and thus concrete specification of these requirements. The design inputs, at the sametime, are also divided in sections and belong to a software layer (what we call subsystem). Each design inputcan have one or more associated tests along with their log of results. Finally, the requirements can bevalidated anytime.

Attending to the last structuring, a total of 7 relevant Python classes (database tables) were defined, thatcan be seen ordered in the next figure, as displayed on the database server:

• Requirements

• Requirement Sections

• Requirement Validations

• Design Inputs

• Design Inputs Sections

• Design Inputs Subsystems

• Design Inputs Tests

Figure 2: Odoo Tables

A requirement can be easily created with the “Create” button. Several options enabled for modification:

Figure 3: Requirement creation options

Each of these options correspond to a variable defined in the requirement Python class, with name“traceability.requirement” (“module.class”) and are coherently displayed with the order we've specified in theXML view. Variables are declared in the _columns property of the class, with their field type (integer, text,relational field...) and default options. After, the proper way to display them is specified in the XML file, as thefollowing figures show.

Figure 4: Requirement class in Python file: fields definitions

Figure 5: Requirement form in XML file: fields display

2.3 Beyond Variables: Table Methods

Not only variables can be defined in the .py (Python file), but also functions. The functions can be verydiverse and may communicate with other tables. For example, in the requirements class, we've defined afunction that renames the requirement to a code, the code being SECTION_CODE-SEQUENCE_NUMBER.The sequence number is a unique integer among the project and is retrieved from the project module (whichkeeps count of how many requirements are there). The section code is an abbreviation of the section towhich the requirement belongs. For example, a requirement belonging to the section External InterfaceRequirements (EXT-INT for short) and being the first one to be defined in a project (sequence number = 1)would be renamed to EXT-INT-1. The default function naming the requirement is “name_get”, so we rewritethis function according to our needs. Final function is displayed in the following figure.

Figure 6: Example of a table function: “name_get” method override

Another default functions that may be overwritten are “create” or “copy” (duplicate button in Odoo), inorder to fulfil our needs. For example, when creating a requirement, we need to query the associated projectto retrieve the unique sequence number that will be associated to that particular requirement. In order to dothis, we use “self.pool.get()” function to query the project table. The sequence number of the project is not adefault variable of the Odoo Project module, but we inherited the project.project class and added newvariables to it, such as a project colour (for a much clearer visualization in the kanban view) or the sequencenumber itself. An example overriding the “create” function in the requirement class follows.

Figure 7: Example of a table function: “create” method override

Now, there are different type of views, among which we have used the most basic two: form and tree orlist view. These views enable the user to visualize the data records in the Odoo database server, and modifythem. One can visualize a list of records with their most important attributes (tree view) or visualize a singlerecord with a much broader set of variables (form view). We added an additional view called kanban and,although more complex to design, it allows for better visualization. This way, a kind of traceability tablestructure (requirements together with design inputs, ordered by section tabs) can already be seen from theOdoo database server:

Figure 8: Kanban view of requirement table in Odoo

2.4 Information for IT Support: User Permissions

An user that needs to work with the Traceability module needs to have the following permissions to work properly:

Module\Permissions Read Write Create Delete

project.project X X X X

traceability.requirement X X X X

traceability.designinput X X X X

traceability.section X X X X

traceability.sectiondi X X X X

traceability.testfunction X X X X

traceability.subsystem X X X X

traceability.reqvalidation X X X X

The programs that retrieve information and write to the database need to have the following permissions to work properly:

Module\Permissions Read Write Create Delete

project.project X X X X

traceability.requirement X X X X

traceability.designinput X X X X

traceability.section X X X X

traceability.sectiondi X X X X

traceability.testfunction X X X X

traceability.subsystem X X X X

traceability.reqvalidation X X X X

res.users X X X X

3 Generating Specification Documents (SRS, SDIS, HLDF): Retrieving data from Odoo

3.1 Types of Specification Documents

After having filled in the Odoo Traceability module with all requirements and their relations, there aresome ways of representing these relations, each one defining a type of specification document:

• Software Requirements' Specification (SRS). This document has a list of requirements bysections, together with the requirements' description. The document is general to the projectbecause it specifies the general requirements to be accomplished with the project. An example of anSRS can be found in the Supplementary Material, but the main part that might be under changes isrepresented below.

Figure 9: SRS document: requirements list by sections

• Software Design Inputs' Specification (SDIS). This document is not general to the project butthere is one of these documents for each layer of software. Design inputs belong to a certainsubsystem and describe technical features of their associated subsystem. Please find an example ofan SDIS document in the Supplementary Material. The SDIS document has two main parts thatmight be subject to changes: a list of design inputs by section, and a Traceability table that relatesdesign inputs of a certain subsystem or layer with their associated, more general requirements.These parts are represented below.

Figure 10: SDIS document: design inputs list by sections

Figure 11: SDIS document: traceability table

• High Level Design File (HLDF). There is only one document of these for each project. It relatesrequirements with layers of software. It indicates if a particular requirement is tackled in a particularlayer of software. To better visualize this relation, the HLDF document usually includes what we calla Compliance table. Please find an example of HLDF in the Supplementary Material. A Compliancetable is included below as an example.

Figure 12: HLDF document: compliance table

3.2 Specification Documents Generator

It becomes clear that we'll need to retrieve database records in order to build these type ofdocumentation. We have built a program that easily does that for us. Here there is its Graphical UserInterface (GUI):

Figure 13: GUI of Specification Documents Generator

It can easily be seen from the GUI how it works, but here there is a brief explanation just in case. It takesa header LaTeX file and optionally a footer LaTeX file. Please find an example of header and footer LaTeXfiles in the Supplementary Material. The output file, which will be saved in the header file directory, can begiven an arbitrary filename. After that, a project from Odoo Project module needs to be selected from the GUIdrop-down list. After, the type of output file needs to be selected. While SRS and HLDF do not need furtherinformation, since they are generally associated to a project, SDIS needs the subsystem (software layer)specification.

From this program, a specification document will be generated. It is recommended to generate thespecification documents all at once after writing all the project records in the Odoo database server. Also, it isrecommended to have a MikTeX compiler for LaTeX installed before using the program.

3.2.1 Technical information

We have used Qt5/C++ to build this program, together with libmaia, an open-source C++ library that isable to communicate using the XML-RPC procedure, which is the one used by Odoo (see this). Thefull project source code is included in the Supplementary Material, but a brief explanation may berequired.

The program uses a class called OpenERP that holds information about database records. We havecreated a parent class called Module that absorbs all tables (requirements table, design inputs table,subsystems table, etc.). Module has an own variable “id”, which is the database object uniqueidentification, and child or inheriting classes add their own variables.

4 Joining Doxygen/C++ Source Code with Odoo

We hereby present a way to semi-automatize the documentation process, by just commenting on thesource code. The technique presented is quite powerful because building the software project or running atest project will already provide its correspondent documentation, along with the traceability table.

The general desired idea is being able to obtain a LaTeX traceability table where for all design inputs orrequirements of the project there are some user-defined classes/methods which tackle those inputs. Thistraceability table would ideally be generated by inserting a comment next to the correspondent class/method.The comment would include the Odoo design input code (eg. L1-DEV-FUN-2) which is addressed in that partof the source code. For example, adding the marked command in the following figure:

Figure 14: Traceability Command

should generate a table similar to the next one, with the design input number, its description and itsassociated function(s):

Figure 15: Traceability Table from previous figure command

Examples above are designed for a software tester, but for a software developer works in a similar way.Another program has been developed that, together with Doxygen compilation, is capable of generating thistype of tables. The mentioned program was designed specifically for compilation-time as a build step of Qt.The following sections try to aid in the configuration process. First we need to install and configure aDoxygen file (also called Doxyfile), then we need to configure some build steps in the Qt project we areworking on.

4.1 Doxygen Configuration File

If you still do not have a Doxygen configuration file in your software project folder, open Doxywizardand write your software project directory in “Step 1: …”. Then, File > Save. You are ready to go.

The most important part when configuring the Doxyfile for our purpose is to set up an alias. You canget familiar with aliases here. A complex alias can use other Doxygen custom commands or take arguments.Aliases can be changed in Doxywizard, Expert > Project > ALIASES tag. We have written and added

DI{1}=\xrefitem req \"Design Inputs" \"Design Inputs" Design Input \1

This alias, called DI, uses the Doxygen command \xrefitem and takes one argument ({1}),which is included at the very last (\1). You can get familiar with \xrefitem command here.

\xrefitem <key> "(heading)" "(list title)" { text }

This command is usually used in combination with an alias in order not to write the full line everytime you write the command. What it basically does is to cross-reference the commented item(class/member/variable/...) with a custom object list. When generating the documentation, we'll see a newchapter with a list of classes/members and their associated requirements (Figure 16).

Figure 16: New Chapter Created

Also, inside every cross-referenced function we will see a new section in the detailed description,listing the requirements associated (Figure 17). We can already see where the arguments of \xrefitem(heading, list, title) will end up in the documentation.

Figure 17: New Section Created

Now, this could be the end of the process, since for every specified class/method we get the designinputs associated. However, we would like to have it in the opposite way: for every design input, having allthe associated classes/members. This does not mean we have to start over. In fact, what we have done untilnow will be of extreme importance when comes to generating the traceability table in our desired way.

Important: Save the Doxyfile (in Doxywizard, File > Save) in the software project folder, just wherethe .pro file is placed.

4.2 Custom Made Program

We need to complement the Doxygen software in order to generate the traceability table we want. Inour case, we used C++ programming language but the steps are explained in detail in case you were notcomfortable with it. See the Appendix to see the full code and orientate yourself.

From a mathematical point of view, we could imagine that Doxygen generates a boolean two-dimensional matrix in which for every row (classes/members) there are several “true” columns (designinputs). For our purpose, we would like to have a two-dimensional matrix in which for every design input wehave several classes/members associated. This is, we would like to have the transpose matrix. Theapproach we take in here is to build the Doxygen traceability matrix and then transpose it. Then we build aLaTeX format .tex document where the traceability table is written according to the transpose matrixobtained.

4.2.1 Creating the Traceability Matrix

The traceability matrix generated by Doxygen is NxR, where N is the number of classes/memberswith a design input associated and R the total number of design inputs. From running Doxygen, we noticed areq.tex is generated in the output. This file contains all needed information.

We initialize the traceability matrix with zeros. We open the “/latex/req.tex” file generated withDoxygen to read and search for classes/members (search for “\item” string) updating a counter every time.

Also search for “Requirement” or whatever you put in the second argument of \xrefitem. When found, useatoi(·) function to pass the design input number from string to integer. With the “\item” counter and thisinteger, fill in the correspondent matrix position with true. Iterate.

Transpose the created matrix and save it to a new variable. This step is quite straightforward (seeAppendix).

4.2.2 Building the LaTeX Table

If not familiarized with creating LaTeX tables, see here. We will need to write an algorithm togenerate a LaTeX traceability table from the transpose matrix created before. We will write the table in a newfile “./latex/new_table.tex”. We need to open “./latex/req.tex” at the same time to read the hyperlinkedclasses/members and include them into the traceability table.

Three main features are considered when building the table. First, it has to be able to be sequentiallywritten with an algorithm. Second, one cell may have multiple lines inside (one requirement can beassociated to several design inputs). Last but not least, the table may need to span several pages on thedocumentation and page break has to be done in an automatic way. The best approach is to use ltxtablepackage, which uses a combination of packages tabularx and longtable. As Doxygen will not include theseextra packages by default, we need to add them in the preamble of header.tex file. A header LaTeX file isincluded in the Supplementary Material as an example of packages needed.

Note: If you would like to use a header file, the header.tex needs to be created before runningDoxygen. To do so, open a Terminal, go to your software project directory (cd …) and write

>> doxygen -w latex header.tex footer.tex doxygen.sty

Then open your Doxyfile with Doxywizard, and in Expert > LaTeX browse for all three created files(header.tex, footer.tex, doxygen.sty) in the respective tags (LATEX_HEADER, LATEX_FOOTER andLATEX_EXTRA_STYLESHEET). If more information is needed about header, footer and style sheet files,see Technical Note “Drawing UML Diagrams with Doxygen”.

After that, open header.tex in the LaTeX editor and add in the preamble

\usepackage{ltxtable, tabularx, longtable}

to have full functionality of these additional packages.

4.3 Integrating the Steps in the Qt Building Process

Of course now we could (1) change the project source code in Qt and save changes, then (2) openDoxywizard GUI and run Doxygen from there, then (3) browse to the software project folder and executeyour custom-made application. However, this becomes tedious and the routine is prone to errors. A way tointegrate this three steps in the building process of Qt is explained. By just clicking the Qt build button, yourLaTeX documentation with your custom changes will be built. This way you'll keep your documentationupdated and you won't need to use third party programs every time you change the sources.

Qt Creator has a very easy way to add what they call “Build Steps”. You can add processes whichwill be executed immediately after building your software project. For our purpose, two additional build stepswill be required (one for running Doxygen and the other one for executing your compiled custom-madecode). In order to add them, go to Qt Creator's Projects tab. At Build & Run, you will find “General” at BuildSettings. Make sure “Shadow Build” is unchecked.

4.3.1 Doxygen Build Step

Still at Build Settings, at “Build Steps”, select “Add Build Step”. From the drop-down list select“Custom Process Step”. A new Build Step will open. Configure it like Figure 18 (since doxygen is added topath, just “doxygen” in “Command:” will do). From now on, Doxygen will run each time you build your project.

Figure 18: Doxygen Configuration in Qt Creator

4.3.2 Custom-made Application Build Step

Add another “Build Step” with the entire path (file and extension included) of your compiled custom-made code. It is illustrated in Figure 19. The program needs 5 arguments. The first argument is the title ofthe third column of the Traceability table that will be generated. The second argument is the first word ofeach row, first column of the Traceability table. The third argument is the name of the project in Odoodatabase server. The fourth argument is the subsystem code in Odoo database server. The fifth argument isthe program mode.

There are two program modes: “none” and “test”. When “none” is selected, the documentation isgenerated assuming a software developer is using the program. When “test” is selected, the documentationis generated assuming a software tester is using the program. The “test” mode performs exactly the sameoperations as the “none” mode, but it adds an additional step: “test” mode writes the test results to thedatabase. It tries to find a file called “test_report_{subsystemcode}.xml” in the .pro directory and reads it,writing the test functions and their associated results to the database. The Odoo module keeps a log recordof test results along time, together with the version associated. This way, one can trace the test functionsalong time.

Figure 19: Custom-made Application Configuration in Qt Creator

4.4 Compile LaTeX Output

If a single pdf document wants to be generated from LaTeX files, go to “latex” output folder after building your software project. Open “refman.tex” with your LaTeX editor and compile it (PDFLaTeX option). The “refman.pdf” file, generated in the “latex” folder, will be your final fully hyperlinked documentation. With a bit of luck, you will find your traceability table inside.

There is an even more integrative way to compile LaTeX output. In Windows, you can add another

build step in Qt Creator which runs the make.bat file in the generated “latex” folder. In “Command:” of the build step, just browse to this file. “Arguments” and “Working Directory” are left as default. Then make a bat file with the command that follows to open the pdf in the Build Steps.

start "" /max "C:\Users\neuroelectrics\Documents\NICBenchmark2_nou\NICBenchmark2\latex\refman.pdf"

5 Full Traceability Table Generation: Requirements Validation

An additional feature added to the Odoo Traceability module was Requirements Validation, which can bedone any time. Then, a full Traceability table belonging to a particular version can be built accordingly. Aprogram was made for the occasion. The GUI can be seen below.

Figure 20: Full Traceability Table Generator

The project version has to be written as it is in module “project.issue.version” of Odoo database server. Thefull Traceability table generated is similar to the one below.

Figure 21: Full Traceability Table

6 References

This section contains the list of the supporting documentation such as technical notes (from vendors or Starlab), internal TPRs, published papers, books and any other source used in the design.

[1] Requirements Traceability. Wikipedia. (https://en.wikipedia.org/wiki/Requirements_traceability)

[2] Libmaia C++ library for XML-RPC communication. (https://github.com/wiedi/libmaia)

[3] Doxygen official site. (http://www.stack.nl/~dimitri/doxygen/index.html)

[4] MiKTeX official site, portable edition download. (http://miktex.org/portable)

[6] Doxygen Custom Commands: Aliases. (http://www.stack.nl/~dimitri/doxygen/manual/custcmd.html)

[7] Doxygen \xrefitem usage. (http://www.stack.nl/~dimitri/doxygen/manual/commands.html#cmdxrefitem)

[8] LaTeX/Tables. WikiBooks. (https://en.wikibooks.org/wiki/LaTeX/Tables)

[9] The tale of “aux.c”. (http://heirloom.sourceforge.net/mailx_aux_c.html)

[10]Doxygen: Documenting the code. (http://www.stack.nl/~dimitri/doxygen/manual/docblocks.html)

Change Record

Issue Date Changes made Author

TN0005 - Requirements Traceability through OpenERP Communication - Towards Automatizing...

Documents

OpenERP - Offshore with OpenERP

OpenERP - How to sell OpenERP

Key success factors selling OpenERP. François Pietquin, OpenERP

Presentation of the new OpenERP API. Raphael Collet, OpenERP

OpenERP Hotel by Opentia - Jornadas OpenERP 2011 Lugo

Présentation1 OpenERP

TALKING SOUNDSCAPES: AUTOMATIZING VOICE …

Openerp Book

Working with OpenERP - Packt Publishing with OpenERP. Working with OpenERP provides a comprehensive walkthrough for installing, configuring, and implementing OpenERP in real-world

Medical OpenERP

OpenERP for Accounting and Financial Managementmedia.readthedocs.org/pdf/openerp-61-documentation/latest/openerp... · OpenERP for Accounting and Financial Management, Release 1.0

OpenERP Construction

Hospedagem OpenERP

OpenERP - Sharing OpenERP content & New social features

Openerp Server

The OpenERP community organization explained by Olivier Dony, OpenERP

Openerp presentacion

OpenERP - Optimizing customer acquisition with OpenERP

TALKING SOUNDSCAPES: AUTOMATIZING VOICE TRANSFORMATIONS FOR …gerae101/pdf/talking... · 2013-02-18 · TALKING SOUNDSCAPES: AUTOMATIZING VOICE TRANSFORMATIONS FOR CROWD SIMULATION

Openerp Reference