Page Comparison

How do you write requirements with Requirement Yogi?

There are a couple of actions you can take key points that can help to write and structure your requirements:

...

Best Practice 1: Put your requirements in Tables

We recommend you to write your requirements in tables, this way you’ll Users should be able to assign properties and dependencies to your requirements, and have a clear traceability and readability of your specifications. You can use horizontal tables, and also vertical tables.

Writing requirements should be human friendly, the main focus of users must be the product to specify, and still allow you to be flexible over what you want to write. For you to keep a structured and clear readability of your requirements, we figured tables were the best way. Indeed, using rows for the listing of your requirements, and columns for categorization helps you and your users to access generated reports and look through all your specifications.

...

Best practice 2: Defining your key patterns

focus on their product, and writing quality requirements, and not so much on the tool they are using and the structure it must follow. The best compromise we found to help you accomplish that, and not lose sight of your data is: Tables.

1. 1 Row = 1 requirement

2. 1 Column = 1 data type, also called properties.

3. This will allow us to read and interpret your data, to give you:

   1. Structured requirements

   2. Reporting

   3. Easy Navigation and lecture

...

Best practice 2: Define your key patterns

Each requirement key is unique, and the key pattern will help you identify and organize the types of requirements you are creating. You’ll be able to use the search, and filter your traceability matrices based on the key. Once your key patterns are created, it will also ease the flow of creation as we’ll be able to autosuggest the next requirements.

• For example, business requirements, functional requirements and technical requirements: PRODUCT-BR-001, PRODUCT-FN-001 , PRODUCT-TECH-001.

We recommend to keep your requirement keys concise, but you are rather free in terms of format. You can use:

...

However, do not use % , / or \.

In terms of prefix, and what patterns you should use, we recommend to group your requirements per type. This prefix will allow you to look for all similar requirements, and will also allow us to autosuggest the next requirements you want to create.

...

.

For the numbering, we recommend to put an extra 0 depending on the number of requirements you plan to have. This will simply help us to keep the order in the search and traceability, making sure number 10 will be put correctly in order after the number 09.

Best Practice 3: Ways to add

...

requirements

There are more than one way to create new requirements.

• I am writing my requirements one by one, as I create my specifications

  • Use the /req shortcut to add our macros. You’ll be able to write your requirement key and insert it.

• Inserting the requirement macro individually takes me too much time, I want to generate my requirements

  • Use the Transformation wizard in your table and select the rule ‘Generate keys’. Find out more in the documentation.

• I already have my requirement keys written in text, how can I transform the requirements?

  • Same as the point above, use the Transformation wizard and choose the rule ‘Transform text in keys’.

  • 💡 You can also do the same with requirement links, and transform mentions of existing requirement definitions. Read the docs.

• I want to ease the writing for my users, and create templates

  • Using the requirement types, you can create templates of pages that will help to fluidify the writing process of your users, making sure the requirements have the correct properties. See more in the next Best Practice.

Best Practice 4: Organize your requirements per type

...