Leap SE's FAQ Forum

Requirements Central      Template Navigators      Templates      Requirement Builder      Pricing      Home

DISCLAIMER

All questions and comments are reviewed for suitability and etiquette before posting. Leap Systems reserves the right to post submissions in part based on content, and will edit material as necessary to improve quality. It is not the intension of Leap Systems to alter or distort the meaning of comments in any way, but to simply maintain a professional site. Note: As of May 2004, contributor names and salutations have been omitted to give the forum more of FAQ look-and-feel.

SUBMISSION GUIDELINES

To submit a comment or question, please send your input to techsupport@leapse.com.

How do I know if I'm using the right template, or which template to use?

###

Whatever template fits your composition needs is the 'right' template to use. It's that simple. Leap SE comes with 22 templates, a Technical Composer, and Requirement Builder. Of the 22 predefined templates, 18 are functional and 4 structural. A structural template is purely used to define a system component and not system behavior. The definition of behavior is accomplished with Leap SE's functional templates. The Requirement Builder offers more flexibility than Leap SE's functional templates, but is slower to use, and should only be utilized when none of the 18 functional templates will accommodate the requirement you are trying to express. In practice, the Builder is used about 5% of the time, but plays an important role in meeting your composition needs. The Technical Composer is a "catch-all" mechanism for capturing requirements that do not directly affect software design and code generation, e.g., "the system shall include dual-redundant servers". Whenever possible, use templates and clone existing templates (and then modify) using the Re-use function. This will maximize your productivity.

Regarding which template to use: Before using Leap SE, it is necessary to take a few minutes to acquaint yourself with the templates at your disposal. This is analogous to knowing what tools you have in your tool chest before beginning a construction project. You will notice that several of the functional templates have the same sequence of fields, or clauses, inside them. This is intentional, and a great benefit. Including these clauses gives you enormous flexibility and the freedom to express your requirements with additional detail. When drafting a requirement, either in one of Leap SE's "Compose Requirement" scratch-pad fields, in an actual template, or in your head, you should ask yourself some fundamental questions, such as: "Is there an event driving this requirement? Are two or more entities interacting to achieve the behavior? Is the behavior temporal? Does the behavior depend on a condition that must hold true? Does the behavior depend on the spatial relationship between two or more entities? Does the behavior involve an external system?" and so on. Leap SE's templates are built around the answers to these questions. In a short time, thinking in this way will become second nature, and you'll be on your way to developing a superior set of system requirements.

What are Leap SE’s Requirements Management and Change Control capabilities?

###

for Requirements Management, Leap SE:

1. generates a Requirement Number for every saved requirement
2. allows input of Paragraph Number, Priority, Release, Category, and Comments to associate with each requirement
3. automatically creates an MS Access database file (.mdb) that serves as your requirements repository
4. provides several query features, including queries by:
     (a) Requirement Type (Functional, Structural, Technical, or All)
     (b) Requirement Number
     (c) Paragraph Number
     (d) Entity
     (e) Version
     (f) Template
5. allows “cloning” of requirements, including deleted requirements, for producing new requirements
6. retains deleted requirements for historical purposes, and does not include deleted requirements in model generation
7. includes automatic version control
8. allows definition of parent-dependent relationships
9. notifies the user before continuing with the deletion of a parent requirement that has 1 or more dependents
10. includes all the query and reporting features of MS Access

for Change Control (Configuration Management):

Requirements deleted in Leap SE are time-stamped with the date of deletion. In keeping with the contractual nature of system requirements, a saved requirement cannot be edited in Leap SE. It must be deleted, after which a new requirement can be “cloned” from the deleted requirement and altered as necessary. It should be noted, however, that any requirement can be edited through direct manipulation in your MS Access database. Process guidelines should be established for your systems engineering team before the onset of a project.

Can Leap SE be integrated with DOORS?

###

Yes. Actually, it's the MS Access database file--created as a companion to your .lpp file--that would be integrated with DOORS. I have spoken with DOORS representatives, and, as it turns out, their greatest competitor is (get this) MS Excel. I couldn't believe it, but apparently many small-to-medium size companies, and even large companies, use spreadsheets for their requirements repository. As you know, an Access file can be readily exported to a MS Excel file, so you could alternatively import a spreadsheet version of your MASTER_REQ table into DOORS.

Do you provide a way to export requirements from Leap SE into a Word document? Cut and paste does not work that well when you have several hundred requirements.

 ###

You've got a variety of options on how to export and manipulate the requirements you've composed with Leap SE, and they all start from the Access database file that Leap SE creates for you. If your using the Demo, open up your ExamplesReqDB.mdb file (should be at the path c:\Program Files\Leap Systems\Leap SE\User Files\Leap SE Databases\). A great feature of Leap SE is that it uses an Access database for your requirements repository. This ensures a wide variety of export mechanisms. Typically, a System Requirements Specification (SRS) is maintained in a spreadsheet (e.g., MS Excel) or in a database (such as Access or Oracle), or in a much more expensive product (such as DOORS or RTM) that has its own relational or flat-file database underneath. Table format is normally desired because of the "other" information that goes along with a requirement, such as its Paragraph Number, Priority, Classification, etc. But to answer your question, here's what I would do to get my requirements into a Word document. In your System database file (or the ExamplesReqDB.mdb file), open up the MASTER_REQ table. Go to the File- >Save As/Export… menu item. You'll find a Save As Type: drop-down list. Now you have several options. Saving to Rich Text Format is you're best option for going directly to a Word document. Alternatively, you could save to MS Excel, and then paste from Excel to Word, which is what I recommend. Hope this helps. Keep in mind that most people are going the other way-- from a Word document to a spreadsheet or database--for greater querying power over their requirements.

This sounds like a CASE tool we could really use on our program…we can’t EVER seem to get past analysis. Couple of quick questions, though: Can you edit requirements after they’ve been saved? And, can you open requirements with the Builder, just like you can with templates? The demo doesn’t allow saving with the Builder, so I can’t tell.

###

For configuration management (CM) purposes, Leap SE automatically versions requirements by creating new versions and deleting old ones for a complete, query-able history. Because a requirements repository is typically a contractual collection of system specifications subject to strict CM control, Leap SE tracks every requirement change with a separate requirement number and an Original Requirement Number that provides traceability to the earliest version. In this way, the complete history of a requirement is maintained in Leap SE's database and can be easily queried via the Version button in Requirements Central on any version of the requirement in its history. When a requirement is opened—whether existing or deleted—it is displayed in the template used to create it. This is ideal for creating new requirements that differ only slightly from existing or deleted requirements, in which case you can use the existing or deleted requirements as pre-populated templates to create a host of new requirements, saving yourself from typing the same phrases, and speeding-up your requirement definition process.

Regarding the Requirement Builder, yes, requirements created in the Builder are opened in the Builder just like they are for templates.

I see you use an underscore ( _ ) for inheritance as part of your class naming convention. Do you capture other UML relationships, such as association, aggregation, and composition?

###

Hi Song,

Yes. Consistent with mainstream C++ and Java programming, Leap SE models association relationships via a pointer ( * ) from the class that "does" the referencing to the class that is referenced. You can find these object pointers in the private section of the class. Leap SE does not make a distinction between aggregation and composition, however; a whole-part relationship is by default modeled as composition. Because it is virtually impossible to discern this subtle distinction from system requirements expressed in English, the developers at Leap Systems settled on composition. For logical modeling, this is really a convenience and not a shortcoming. Composition is also found in the private section of the "whole" class that references the "part" class. To distinguish between association and composition, a reference ( & ) is used instead of a pointer for "part" object variables in the private section of the "whole" class. Hope this helps. You might want to open your <SystemName>Req.mdb file (read-only is recommended) to see how these relationships are managed in a relational form.