The following two requirements were removed ahead of the OFT API design:

From the spec

Plain Text Report Options

req~reporting.plain-text.report-options~1

The following parts of the plain text reports can be switched on and off:

• Summary
• Overview per defect specification item
• Overview per clean specification item
• Source file name and line
• Specification item description

Covers:

• featplain-text-report1

Needs: dsn

Default Plain Text Report

req~reporting.plain-text.default-report-options~1

The following options are set by default in the plain text report unless options are specified by the user:

• Summary
• Overview per defect specification item
• Source file name and line

Covers:

• featplain-text-report1

Needs: dsn

From the design

Plain Text Report Options

dsn~reporting.plain-text.report-options~1

The following parts of the plain text reports can be switched on and off:

• Summary
• Overview per defect specification item
• Overview per clean specification item
• Source file name and line
• Specification item description

Covers:

• req~reporting.plain-text.report-options~1

Needs: impl, utest

Default Plain Text Report

dsn~reporting.plain-text.default-report-options~1

The following options are set by default in the plain text report unless options are specified by the user:

• Summary
• Overview per defect specification item
• Source file name and line

Covers:

• req~reporting.plain-text.default-report-options~1

Needs: impl, utest

Situation

During a system test with existing legacy MD files, imports were missing. Looks like that the format used in the field has additional syntax elements that OFT is not yet compatible with.

Acceptance Criteria

• OFT successfully imports existing legacy MD files.

I searched an easy way to see a resulting report of OFT.

Situation

New lines (especially after empty lines) are not treated correctly in the MarkdownImporter and PlainTextReport

Acceptance criteria

1. New lines in multi-line comments are preserved

As a developer
I want to see all links from and to a specification item including the link status
so that I can fix issues as fast as possible.

Acceptance Criteria

• Plain text report displays links from and to an item
• Links are labeld with the link status

As a developer
I want a tracing report that is easy to ready
so that I can identify and fix gaps and errors in the tracing easily.

As a quality engineer
I want a report that I can view in a browser
so that I don't have to install any special tools on my machine when auditing a project.

As a customer
I want a report that I can understand and archive
so that I get a solid view of whether the team working for me does a good job.

Acceptance Criteria

• OFT can produce an HTML report from a trace
• The HTML report contains everything relevant for quality assurance

As a user
I want OFT to only import new or changed artifacts for my project
in order to speed up the import process.

Acceptance Criteria

1. OFT remembers input artifacts across tracing runs and only re-imports those that are new or have changed.

OFT is a requirement tracer so "openfasttrace" fits much better than "openfasttrack".

Acceptance Criteria

• All instances of the name OpenFastTrack renamed to OpenFastTrace
• Package root renamed to org.itsallcode.openfasttrace

As a software developer,
I want to OFT to automatically determine the artifact type of the file I am putting coverage tags in,
in order to save time and reduce the chance to make mistakes in configuration.

Acceptance Criteria

1. The TagImporter recognizes code files by file type extension.
2. The TagImporter uses Java path and file naming conventions to tell tests and implementation apart.
3. The TagImporter uses a mechanism that can be extended for other programming languages in the same way as for Java.

As a software developer
I want to filter specification items by tags before tracing or converting
so that I can concentrate on implementing and tracing those that concern me.

As a quality engineer
I want OFT to automatically select the correct importer
in order to import multiple files without selecting an importer explicitly.

Acceptance criteria

• OFT selects the matching importer for a given file extension
• Architecture allows adding additional importers

Situation

If a specification item claims to cover another specification item that does not exist, this case is currently not recorded.

The reason is that in

void openfasttrack.core.Linker.linkIgnoringRevision(LinkedSpecificationItem item,
    SpecificationItemId id)

the special case that no matches for the claimed coverage are found (even ignoring the revision) is not handled.

Expected Behavior

Linker detects and records coverage link to non-existing specification item.

Actual Behavior

Case is silently ignored.

Situation

Instead of tracing, the CLI command "trace" feeds an unlinked Stream of LinkedSpecificationItems to the Tracer.

Acceptance Criteria

1. "trace" command invokes item linker
2. Importer feeds plain SpecificationItems to CLI commands

Situation

If requirements are linked in a ring, OFT runs into an endless recursion and terminates with a stack overflow exception.

Acceptance Criteria

1. OFT detects a link ring during tracing
2. OFT issues a warning
3. OFT stops tracing in the ring and continues with the next requirement
4. OFT sets the tracing result status to "not OK"

As a Quality Engineer
I want the list of input files and directories to consist of individual unnamed parameters
in order to easily append the list to the command in scripts.

Acceptance criteria

1. Each input file and directory is an unnamed parameter
2. The inputs are expected after the command parameter (e.g. "trace")

Examples

oft trace doc/spec.md doc/design.md src/main/java
oft trace --verbosity-level=failures doc/spec.md doc/design.md src/main/java
oft --verbosity-level=failures trace doc/spec.md doc/design.md src/main/java

As a quality engineer
I want to run OFT on a list of files / and or directories (including their sub-directories)
in order to check requirement coverage over a whole project.

Acceptance criteria

1. OFT accepts a list of input files as parameter
2. OFT accepts a list of input directories as parameter
3. OFT scans a files given directly and which are below a given input directory
4. OFT scans each file only once

TagImporter shall create spec items with a generated ID and covers attribute set correctly.

See #49 for urther improvements.

Situation

Lets face it. Plain HTML rendered from Markdown is not optically appealing. To fix this we need a CSS stylesheet for our specification documents.

Acceptance Criteria

1. CSS stylesheet is used in rendered specifications of OFT

Situation

As per GNU convention the following is equivalent:

myprogram --verbose --recursive
myprogram -verbose -recursive
myprogram -v -r
myprogram -vr

Acceptance criteria

1. Multi-character argument names are led in by double dash or single dash
2. Single-character argument names are led in by single dash
3. Single-character argument names for arguments without values can be chained after a single dash
4. Multi-word argument names are lowercase and separated with dash (e.g. --output-dir)

See Also

http://www.gnu.org/software/libc/manual/html_node/Getopt-Long-Options.html

As a software integrator
I want OFT to reflect the tracing result in the exit status
in order to fail builds if tracing is broken.

Acceptance Criteria

1. OFT sets the exit status to "OK" when the trace is "OK" and to "not OK" otherwise.

As a developer
I want to be able to tell from the requirement ID, what a specification item is good for,
so that I can correlate sources with specification faster.

Acceptance Criteria

1. The requirement ID generated by the TagImporter reflects the covered requirement name.

As a user
I want OFT to import coverage tags from my source code
in order to trace requirements to source code level.

Acceptance criteria

1. OFT contains an importer that reads arbitrary source files and imports coverage tags.

As a software architect
I want to have a shortcut for passing down system requirements directly to the detailed design
so that I can efficiently forward all requirements that are not relevant in the system architecture - typically requirements that effect only a single component.

Example

# Passed down requirements
* `req~display_remaining_inactivity_time~1 -> dsn`

Test testTraceWithReportVerbosityMinimal fails because it expects fileContent(this.outputFile), equalTo("not ok\n") but get on windows for fileContent(this.outputFile) "not ok\r\n"

As a developer
I want to build OpenFastTrack with Eclipse and Maven
in order to be fast and not have to manage the dependencies by hand.

As a user
I want OFT to run on all processor cores of my machine
in order to get requirement coverage feedback as fast as possible.

Acceptance criteria

1. Requirement import runs on multiple processor cores in parallel.

Situation

• Status, tags and title and location are missing in SpecObject export

Acceptance Criteria

• Export status, tags, title and location to ReqM2 files.

As a software integrator
I want to integrate requirement tracing into my build chain from scripts
so that I can run it automatically as a part of my build.

As a configuration manager
I want to see a master branch containing only releases of the project
in order have a clean and simple release history in the repository.

Acceptance criteria

1. A new branch "develop" is created
2. The branch is protected against accidental deletion
3. Branch "develop" is promoted to default branch

Acceptance Criteria

1. System requirements are up-to-date.

This simplifies adding tags to source code, where a common prefix is used for all tags in a sub-project.

Called command:

• java -jar openfasttrace-0.4.0.jar convert req.md

Expected behavoir:

• Default exporter output format shall be "specobject"

Observed behavoir:

• Exception in thread "main" org.itsallcode.openfasttrace.exporter.ExporterException: Found no matching exporter for output format 'null'

Stacktrace:

Exception in thread "main" org.itsallcode.openfasttrace.exporter.ExporterException: Found no matching exporter for output format 'null'
at org.itsallcode.openfasttrace.exporter.ExporterFactoryLoader.getExporterFactory(ExporterFactoryLoader.java:70)
at org.itsallcode.openfasttrace.exporter.ExporterService.exportFile(ExporterService.java:65)
at org.itsallcode.openfasttrace.mode.ConvertMode.convertToFileInFormat(ConvertMode.java:38)
at org.itsallcode.openfasttrace.cli.commands.ConvertCommand.convert(ConvertCommand.java:70)
at org.itsallcode.openfasttrace.cli.commands.ConvertCommand.run(ConvertCommand.java:54)
at org.itsallcode.openfasttrace.cli.CliStarter.run(CliStarter.java:68)
at org.itsallcode.openfasttrace.cli.CliStarter.main(CliStarter.java:45)

Situation

The Markdown importer does not realize required coverage if only one artifact type is listed in the "needs" section. From two on it works though.

Acceptance criteria

1. The markdown importer recognizes single artifact type in as required coverage.

Avoid flooding the log with warning caused by unknown XML elements by using a white list of root element names.

• Add location (file name, file path and line number) to SpecificationItem
• Set location during import

See #66

As a quality engineer
I want to know the requirement coverage of my project
in order to get gaps closed and over-covered requirments investigated.

Acceptance criteria

1. The basic report contains the count of
   • total specification items
   • uncovered specification items (if any)
   • over-covered specification items (if any)
2. The basic report contains a list of IDs of
   • uncovered specification items
   • over-covered specification items

Situation

Integration test should be runnable in a separate test phase.

The fail save plug-in established the standard naming convention for integration tests:
https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#includes

Acceptance Criteria

1. Integration test filenames start with "ITest..."

Situation

Status, tags and title are missing from both ".xml" / ".oreqm" import. Location is missing from ".oreqm".

Acceptance Criteria

1. Import status, tags, title and location from ReqM2 files.

Situation

At the moment isOk() only considers coverage.

Acceptance Criteria

1. isOk() also considers broken and unwanted links

Fix Sonar Findings on 0.4.0

As a developer
I want to add tags to implementation and tests
so that a coverage trace tells me whether I forgot anything.

Acceptance Criteria

1. Implementation is covered (impl)
2. Test is covered (utest, itest)

As a software developer
I want to see the number of broken links and duplicates per specification item
in order to fix the issues faster.

Acceptance Criteria

Per specification item

1. ... the number of broken incoming links is displayed
2. ... the number of broken outgoing links is displayed
3. ... the number of duplicates is displayed

As a document author
I want that ignoring an artifact type ignores outgoing links from a specification item
so that I can completely focus on the tracing for the requirement types I am interested in.

As an OFT user
I need a handbook
in order to quickly find out what OFT can do for me and how to use it.

Use an xml parser supported by Android