Release 3.0 – Estimates

Owned by Adrien Ragot
Last updated: Apr 04, 2023 by Mileva Briand
4 min read

Migration task for Requirement Yogi 3.0

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 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 was a technical limitation, don't ask, it's solved),

Please see Migration to RY 3.0: FAQ for all 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... for example to perform an estimation of your project:

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:

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 properties

  • 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.

 

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 this improvement is immense.

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

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. It 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.

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