Real-time oversight for requirements engineering
How many requirements are still in the pipeline?
How many have been implemented?
Which requirements have test cases?
objectiF RM gives you tools to easily answer these questions:
- pre-configured and user-defined real-time queries for the results of requirements engineering
- specific views for things like the requirements history
- configurable dashboards with modifiable status indicators of ongoing work
Configurable dashboards can be used to create real-time overviews of the status of requirements engineering in your projects.
Automatic versioning of requirements according to your needs
Have you just changed a requirement at the request of a stakeholder and now they want to take the changes back? Do you need to be able to provide evidence of all changes a requirement has gone through in the case of an audit? In such cases you can use the history of objectiF RM.
Artifacts, diagrams, files and documents are version-controlled in objectiF RM. In the settings, you can ensure that a review is automatically created when a result changes state. Would you like to make a version of a partial state? Then explicitly generate a revision in a few clicks.
This way you can:
- Trace changes at any time thanks to the automatic history,
- Compare two revisions with each other,
- Undo changes and return to a previous state.
Comparing two versions of a requirement: The name and description (right) as well as custom attributes (left) have changed. Apart from this, a review is created for a requirement which can be seen in the listing. By the way: The first three reviews have been automatically generated at a state change, the last have been explicitly created.
Establishing baselines
Whether a milestone has been reached, an audit is coming up or a requirement needs to be given to another team, it makes sense to keep all the common development states of requirements or groups of requirements engineering artifacts. objectiF RM offers the option of defining configurations and establishing baselines for this.
To define a configuration, create an element group and reference all the requirements, use cases, test cases, etc., as well as diagrams, files, documents whose development state you want to record. Establishing a baseline means generating a revision of an element group.
Here a baseline is established for the results of a stakeholder analysis. An element group is created for this. Many different sorts of results will be referenced here. Establishing a baseline means generating a revision group with a few clicks.
Project-specific requirement properties and forms
An important decision in regards to requirements management is the question of the properties to describe a project with. objectiF RM provides an extensive form for recording and editing requirements for this. But what can you do if specific properties are missing from this form? And what should you do if, on the contrary, if the standard form contains far too much information?
objectiF RM has a solution for both problems. You can:
- Expand requirements and all requirements engineering artifacts with custom properties,
- Add new properties into existing editing forms,
- Design custom forms for editing artifacts with the integrated form designer,
- Use your own form as an alternative to the available ones.
This means that with objectiF RM, you can specify the methodical procedure specifically for your organization.
The integrated form designer in objectiF RM: this is how you can define your own forms for specific methodical steps and workflows in requirements engineering
Defining requirements for variants
Many development projects are facing a growing challenge these days: how to handle variability. The ability to create variants of a system or a software product by using variable components is in high demand in businesses today and no longer only limited to software product line development and the automotive sector.
At the beginning of requirements analysis, you should specify the variability properties that the solution should have. To do this, you must answer questions like “What changes?” and “How?”objectiF RM helps you to record the answers: for properties that can vary, variation points can be created. In what way a property varies, is described with values, i.e., variations of a variation point.
Creating variations and variation points provides a foundation for dealing with variability. When developing requirements, you have to answer the question “Does a requirement apply to one or more variants?” If so, allocate the requirement its corresponding variations. “Or does a requirement not apply to the requirement, but to the test cases of the corresponding variation?” In this case, don’t allocate a requirement, instead allocate the test cases of the relevant variation.
This is how you specify the variation(s) of a requirement.
What does this allocation provide? A range of evaluation options and automatization options. So, for example, test management for variations is simplified and accelerated through automatic collection of test cases for tests with a pre-defined variation selection.
