________________________________________________________________________________________________________________ |
|
|
|
|
From the Edit menu, users are able to access the
Parent-Dependent Relationships dialog. (1) The Parent-Dependent Relationships dialog provides users with the ability to create and remove parent-dependent relationships among requirements. These relationships exist at a higher level than that of relationships among entities. By selecting a requirement and choosing Show Dependents, the user is able to see requirements that have a dependency on the selected requirement. If the user is considering editing or deleting a requirement, and would like to know what other requirements may be affected, selecting Show Dependents will display those requirements for further analysis.
(2) Delete. When selecting a requirement to delete and choosing the Delete button in Requirements Central, Leap SE detects if the requirement is the parent of any dependent requirements and, if so, presents a Delete confirmation dialog listing of the requirements that will be affected by the deletion. By presenting this dialog and listing dependent requirements, the user is able to cancel or continue with the delete operation, fully aware of the impact.
|
|
|
Leap SE’s implementation of version control ensures that each
requirement is tracked from inception through its lifecycle of content edits.
When a requirement is created and saved, it is established as version 1, and its
Original Requirement Number attribute is populated with its assigned Requirement
Number. If the content—i.e., the wording—of the requirement needs to be changed
in any way, the user can open the requirement from
Requirements Central by selecting the requirement and choosing Edit.
This displays the requirement (in the source form used to create it) in Edit
Mode. Once the user has made the desired edits and saved, the new version is
incremented to 2 and assigned a new Requirement Number, while its Original
Requirement Number is populated with the previous version’s Original
Requirement Number. Since the current version of the requirement is the desired one, the older version is automatically deleted, yet maintained in the requirements database for historical purposes. Every requirement in Leap SE is date-stamped when saved, content-edited, or deleted; and deleted requirements are not included in the object model database (once regenerated). To support version control, a Version query is provided in Requirements Central. By selecting a requirement that has undergone one or more revisions and choosing the Version button, the user is able to display the complete lifecycle of the requirement, including the date that changes were made, and the unique text of each version. |
|
|
Leap SE detects whenever a requirement has been content-edited or
deleted and prompts the user to regenerate at the appropriate time. Prior
to Header File generation, Data Model generation, and prior to closing your .lpp
file or the application itself, if one or more files have been content-edited or
deleted, Leap SE displays the
Regenerate Object Model Database dialog.
You can choose not to regenerate, although doing so will leave your object model database out of sync with your requirements repository. Regenerating is necessary if you want to produce an up-to-date directory of header files or an up-to-date .sql file. It is also necessary if you want an up-to-date Systems Entities pick-list, System Entities dialog, or an updated display of any of the Object Model dialogs available from the Inspect menu. Lack of synchronization does not affect your requirements repository in any way, and does not affect the integrity of your requirement data. It does, however, compromise the effectiveness of the composition and analysis aids that Leap SE provides. Regeneration can be done at any time from the Regenerate Object Model Database dialog available from the Utilities menu. |
|
The following attributes are associated with every
requirement created in Leap SE.
Attribute Definitions
Integration into Templates, Builder, and Technical Composer All the Leap SE templates, as well as the Requirement Builder and Technical Composer, include the attributes: Category, Priority, and Release, which may be designated at the time of composition. Version, Original Requirement Number, and Date Saved are automatically assigned on Save, both when the requirement is created and edited. Comments may be added through the Requirement Attributes dialog. |
|
|
The Requirement Attributes dialog provides the user with the ability to set or change the Paragraph Number, Category, Priority, Release, and Comments of a requirement. Changes to these attributes are not considered “content” edits, and therefore do not result in an update to the requirement’s Version or Date Saved. This enables the user to freely alter these attributes without performing a version upgrade. If the user did want to the changes to result in a version upgrade, the user could open the requirement in Edit Mode from Requirements Central, make the attribute changes, and Save.
|
|
Leap SE provides full display configurability for the
following 11 fields in Requirements Central, all of which may be set through the
Display menu. Settings are retained between all types of queries. In
addition, settings are stored for future use, so that the last settings applied
are recalled whenever the .lpp file is reopened. Leap SE also supports
sort-order reversal. By simply clicking on a column heading in Requirements
Central, requirements are reorganized in Ascending/Descending order based on the
column data.
|
|
|
The key to a cohesive object model is to re-use system
entities whenever possible. To this end, Leap SE has integrated a pick-list
into its templates to display the currently known system entities. This
convenient pick-list appears wherever the “what entity?” field occurs in the
sequence of template fields. To enter an entity not appearing in the
pick-list, simply type it in the field provided.
|
|
|
While the integration of “system entity pick-lists” into Leap
SE’s templates is convenient for recalling and re-using entities during
requirement composition, what about the attributes, types, and parts associated
with those entities? Not only is entity re-use important for a cohesive object
model, so are attribute, type, and part re-use. The System Entities button,
available from all templates and the Requirement Builder, provides access to the
modeless System Entities viewer. From this modeless viewer, the user can see all
the attributes, types, and parts associated with both system entities and
types of system entities. Use this invaluable resource to assist in the
requirement composition process.
|
|
|
From Requirements Central,
the user can open a requirement for editing or re-use (Edit
or Re-use). Opening a requirement in Edit Mode results in the display of “EDIT
MODE” in highlighted text near the form’s Save button. This highlighted text
reminds the user that the requirement was opened in Edit Mode, and that saving
will result in automatic versioning of the original requirement. See Version. Re-use opens the selected requirement in the template, Builder, or Technical Composer used to create it. Once opened, the user can craft a new requirement by tailoring the existing words to express the new feature, constraint, or functionality. This is a great way to maximize your productivity.
|
|
|
Leap SE includes a
predefined Access®
query and report for printing your system requirements. You are free to
customize these items to meet your specific needs, although it is recommended
that you modify renamed copies to retain the integrity of the originals. In
your <SystemName>ReqDB.mdb database, you will find a System Requirements query
under the Queries tab, and a System Requirements report under the Reports tab.
The report is drawn directly from the query. Sort Order can be freely modified from
within the Design View of the report. Here is an example of the predefined, System Requirements report.
|
|
|
You can
input your
entire Interface Control Documents (ICDs) in Leap SE along with your system requirements. Use this structural template to define an external message and its fields. Structural
Template #22 allows designation of the field’s position in the message; its data
type as Alpha, Alphanumeric, or Numeric; and either a range of values or a set
of possible values (optional).
|
|
