Requirements definition
The definition of the documentary requirements is articulated through the three main
data entities that are requirement sets, requirements, and documents. The maintenance of these three data entities can be performed from the following
locations: Users can configure most of their documentary requirements by using the forms available
from these two points. However, some advanced capabilities should be enabled to take
additional steps that are described in the following sections. The Requirements Portal helps users to maintain the requirement sets, requirements,
and documents. The requirement sets and requirements are implemented in the system as rules that must be
associated with a specific application, ruleset, ruleset version, and class. At run
time, these values are determined by the configuration loaded through
D_ReqConfiguration. Use the available extension point LoadConfiguration_Ext to set the
correct values. Ruleset, where the new and updated rules are stored For example, UPlusRequirements. Ruleset version, where new and updated rules are stored If you want to create or modify the rules, unblock the ruleset
version.the ruleset. For example, 01-01-01. Name of the application that belongs to the ruleset For example, uPlus. The requirements application by default uses the
PegaReq-Data-ReqVerify- class. If you want to use a different class, set its class name in this
property The second stage in the processing of a requirement is data capture. In that stage,
the user performs two basic operations. The first operation confirms that the collected
document is in good order, and the second captures the date that the document might require
according to its type. The definition of the attributes required for each specific document type is done in two
different places. After completing the changes, the new section appears in the data-capture stage for the
documents of the selected type. The defined attributes are captured through that section
and automatically stored along with the document. The information is stored in two
different places: The activity opens the definition of the document identified by
DocId and invoke SetDocAttributeRelevance
to register the attributes. While the persistence of attributes in the document metadata table is essential for the
good behavior of the functionality, the attributes indexes are not currently in use. If
your organization is not planning to implement any functionality based on this table, it
can be disabled and, that way, reduce the overall database footprint. The following when
rules can be used to disable the functionality. IndexDocAttributes IndexComplexDocAttributes If, on the contrary, you want to use the index of the attribute, but you also would like
to make changes in the way the index is generated, you can make some adjustments. PopulateDocAttributeList_ExtConfiguring ruleset and base class for the portal
Property Description pyRuleSet pyRuleSetVersion pySelectedApplicationName RequirementAssetsConfigurationClass Defining document extended attributes
Rule name Rule type Usage When Set the when rules to false to disable the declare-index and
avoid the generation of entries in the attributes index
table. Rule name Rule type Usage Data transform Extension point for consuming applications to define
application-specific logic to extract Name
value pairs from DocAttributePage and populate
Attribute list, which is used for indexing attributes
Previous topic Requirements and document collection introduction Next topic Synchronization engine