Development of requirements

Documents and registry

You can conveniently work with requirements in the form of document, as well as in the form of arbitrary suite of atomic requirements (by means of registry or list of requirements). For example, TS or component TS may be formulated as a document. However, such documents turn out to be large and are not implemented completely. Registry allows to work only with the required subset of atomic requirements - estimate, plan, and control their implementation.

Documentary and list views of registry have the following pros and cons:

Pros Cons
Document with requirements

You can see interconnected document sections on one screen.

Comprehensive task description.

You can create/control requirements to completeness and consistency.

Convenient reconciliation.

You can create baselines and control their versions.

Complex systems contain thousands of requirements, and it's impossible to work on them using the document.

Iterative development assumes implementation of requirements in parts. Groups of requirements may consist of document areas located in its different parts, and it's not easy to manage all of these.

Registry (list) of requirements

There is no excess data (text of requirements) while working on requirement attributes and relationships.

You can quickly perform bulk operations: estimation, implementation.

You can easily control traces to source/derived requirements, and their covering artifacts: test documentation, tests, technical documentation, etc.

It's impossible to verify completeness, consistency, and integrity of documentation and product for an arbitrary requirement suite.

Usually, different requirements are semantically interconnected with each other. However, you cannot monitor that using only one requirement - you also need structural relationships from the documentary view.

To perform different documenting and control tasks, choose the most appropriate document view - Devprom ALM supports them all.

Import/Export and Print

Export your documents with requirements from MSWord, OpenDocument, or Excel files. The application will automatically parse them into sections according to structure defined in the document. To separate document into requirements, use header style layout (Title 1, Title 2, and so on).

Custom document layout

You can independently implement custom logic of transformation of imported document into requirements. To do that, use Automatic actions combined with automation scrips. During the import of each section, system executes your script that can analyze content of the section and parse requirements in it, classify them, create and add links to these requirements.

For example, to convert text that contains phrase "System requirement" into system requirements and store links to these requirements in the document section, you can create such a script:

As a result of the document import, system will create system requirements, and links to them will be placed in the requirement document:

Export to external formats

You can export an arbitrary requirement set, a document or several documents to external formats. If exporting to MSWord, you can specify a document template (sample) whose styles can be used during the export. This template can contain title pages, i.e. you can perform export to any place of the document. Using WYSIWYG editor macros, you can export attributes of document and particular requirements, e.g., export document title to a certain place in the template.

In "Export templates" module of project settings, you can find a list of previously used templates. "Development based on requirements" process contains an example of document export to the template based on GOST requirements. You can independently specify format of bulleted and numbered lists using the corresponding fields in Export template on Advanced tab.

To re-import documents changed by stakeholders outside the system, use export option "Export source code of UML models and formulasā€. Thus, after import these objects will become editable again, since they are transformed into the pictures during export.

To perform import, open a document and select the corresponding menu item in Actions menu.

If you need to print several sections or a whole document, you can use built-in print capabilities from browser:

Types of relationships

Requirements may be connected with other requirements or other project artifacts.

Link type Purpose
Structural, parent-child Complex requirement are conveniently decomposed to smaller elements. For use case, the following items can be nested requirements: UI layouts, expansion points (alternative scenarios or expanding scenarios), system requirements. Requirements can constitute a hierarchy, forming a document, a specification or a technical specification.
Causal In general, functional requirements are generated based on business requirements (e.g., in the form of use cases). System requirements are generated based on functional requirements. These are causal relationships allowing to monitor (trace) transition from one abstract level to another, and so on up to the source code.
Dependencies Some requirements may contain the content of other requirements, or refer to them. Such links are called "dependencies" and allow to identify requirements referred to by other requirements (before modification or removal).
Coverage Such type of connection is established between requirements and other project artifacts: test documentation and technical documentation (user manuals).

The links are generated transparently for user during the creation of project artifacts based on primary, business, or system requirements (e.g., by means of green buttons or menu items). You can edit links on Traces tab.

Links are visualized on the network chart (on Links tab):

Traceability between requirements (causal relationships) and between requirements and other project artifacts (coverage) is used in Devprom ALM as a tool for maintaining integrity of project documentation. When text of a source requirement is changed, system marks all derived requirements and coverages by Obsolete flag. Obsolete requirements and other artifacts can be easily found and updated to restore integrity of connection.

Templates

Requirement templates are the standard samples that can be used when documenting requirements. To insert a template, specify # symbol (hash sign). If a template is defined as the default template, this template will be inserted when creating the requirement. You can use different default templates for different requirement types. We have included some common templates into standard processes. However, you can remove them and use your own achievements.

In addition to page templates, you can form document templates. For example, this can be a standard document for creation of technical specification or specification using a sample adopted in your organization. To create a template, import your sample in Devprom ALM or construct its content using the application tools. In document view, select "New templateā€ in Actions menu. To create document based on a template, use buttons with the corresponding title:

Reuse

You can reuse requirements using several techniques.

Pick out common requirements and place them into the program of projects. You can refer these common requirements or detail them in subprojects.

To create a copy of document with requirements in another project, select "Duplicate" in Actions menu of document view.

If a requirement is reused in several documents, you can include this requirement into the required document section. You can use this operation from the requirement's context menu, it's also available as a bulk operation in the registry of requirements.

If text of some requirement should be repeated in the text of other requirements, use WYSIWYG editor feature to insert other project artifact's text into the requirement text. You can use this feature using the corresponding button in toolbox or the context menu in WYSIWYG editor.

To insert several requirements into another document, open the registry of requirements, mark them with ticks, then use bulk operations to add these requirements into a new or previously selected document.