Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Tip
titleMigration task for Requirement Yogi 3.0

In When installing, an upgrade task will appear and migrate your data to Requirement Yogi 3.0.

This migration task takes 1 minute per 1000 requirements in average (in our tests, we have changed the data model. were closer to 7k requirements per minute). Customers with a million requirements should have all their data migrated in half a day.

The new data model:

  • Supports external properties,
  • Supports better management of dependencies and versioning,
  • Ensures no customer will reach the maximum of database IDs (It 's was a technical limitation, don't worryask, it's solved),

The migration task will deactivate the app during the migration, and it should take in average 1 minute per 1000 requirements. See Please see Migration to RY 3.0: FAQ for more informationall the details.

Estimates!

This is the main visible feature for version 3.0. You can define external properties for requirements, and manage them using the "Estimates" tab...

-- TODO

...

for example to perform an estimation of your project:

Image Added

Notice the footer of the table: You can define operations such as sum, min, max, average and count, and they are updated when you fill in the values.

Hijack the estimates to build your own testing solution!

Although our primary example of external properties is for estimates, you can extend your own properties.

Here is an example of using external properties (checkbox and comments) to tick requirements which have been tested:

Image Added

Notice how the left handside of the matrix is the traceability matrix: You can retrieve as many columns as desired, to bring up the context that is necessary to fulfill your task.

Administering the external propertie

  • As opposed to inline properties, external properties are not visible in the original page, so you can edit them without disturbing the author of the requirements,
  • They are displayed in the requirement popup, identified with a little asterisk (*),
  • They can be used in the traceability matrix,
  • They can be modified by anyone with edit permissions on the space,
  • Two "estimate" matrices with the same property will display the same value, since the value is attached to the requirement.

Image Added


Visual changes for the dependencies

  • We don't call dependencies "TO" and "FROM" anymore, but "Parent" and "Children". The icon has also changed, and our user experiments tell us that it is more intuitive.
  • We properly manage dependencies across baselines. Before 3.0, on a requirement in a baseline, we would only show the children dependencies, now we also show the parents.
  • We don't tout it for now, but the this improvement is immense.

...

Requirement keys are not limited to latin characters anymore: Welcome to UTF-8

...

This has been in alpha-release for a long time, so we are publishing it now. Please be aware that this is still in Beta.

It is possible to create requirement keys using, for example, Chinese characters.

  • The only forbidden signs are / and \,
  • The inline replacement doesn't work well with enlarged UTF-8 names,
  • UPPERCASE(ü) isn't always equal to Ü, depending on the database collation. Therefore, it will often be possible to create both keys Aü-001 and AÜ-001,
  • In the editor, the macro (the gray box) will print "%" instead of UTF-8 characters. Not nice, but expectableIt hurts the eye, but nothing else.

After a long alpha release, this is now in beta and public by default. You can disable this feature if you are unhappy with it, instructions are on the issue RY-834.

Usage metrics

You can now see a summary of your own statistics:

...

We don't send this data back to us, obviously.

Data model changes

As explained on Migration to RY 3.0: FAQ, the data model has changed, which allows us to support customers who have a large history of requirements (more than 2 billion properties historically created).

This datamodel also allows us to better track dependencies across versions, everything is explained on the migration page.

Deprecated behaviors

We are not going to support "live" macros in the future, ie macros which can change the contents of pages after leaving the editor. Requirements should be defined on normal pages and always be rendered the same way as soon as the page is displayed. It means we won't support:

  • Page generators such as Scaffolding,
  • Dropdowns where the status can be selected, unless they modify the actual storage format of the page,
  • Macros which retrieve the status from another system.

Concerning Comala workflowsWorkflows, we may publish a separate tool to write the Comala status inside an external property on macros.

...

Other details

  • RY-818 The "status" criteria in the search, is replaced with internal_status, because customers were confused about it.
  • RY-871 Adjustment to index the Scaffolding macros
  • RY-890 Clicking on "Raise a support request" now prefills the fields

...