|
|
|
|
|
--------------------------------------------- "Leap SE is a requirements engineering CASE tool that produces object and data models directly from your system requirements repository, or SRS. Translating business rules from English into logical models for software development, Leap SE achieves RAD from the source."---------------------------------------------
------------------------------------------
|
Requirements Central Template Navigators Templates Requirement Builder Pricing Home Leap SE is a CASE tool specifically designed to convert system-level requirements into logical models of your system. The product not only acts as a repository for “shall” statements that comprise a System Requirements Specification (SRS), it also provides a means of generating object-oriented header files directly from those requirements. An SQL file is also created for producing entity-relationship diagrams (ERDs). In support of Extreme Programming (XP) and Agile development, Leap SE enables both object and data models to grow with every saved requirement, and with every new release. Why Use It?Leap SE provides a way to “leap over” a substantial part of the Systems Engineering (SE) effort so critical to the execution of any software development project. By translating the written word into a cohesive set of classes, attributes, methods, relationships, and inheritance hierarchies, Leap SE enables software development to get a much-needed head start on design and implementation. Is it just another RAD Tool?Yes and no. Yes, in that it’s intended to speed up the application development process, and no because it’s unique among the few products available today that attempt to assist software development from such a fundamental level. To understand how Leap SE works, it’s important to understand the methodology behind the tool, called Deterministic Phraseology (DP). Where does it fit in the SDLC? Leap SE fits well into the “best-of-breed” approach to software development, where best-of-breed means choosing the most effective applications for specific phases of the systems development lifecycle (SDLC) and coordinating their interoperability. When subscribing to this approach, it's important to understand the benefits of different toolsets, as well as their limitations. CASE tools, in general, are designed for well-defined niches in the SDLC, although makers of such products often seek to extend their products’ usefulness into other areas—areas where other applications are obviously better suited. Leap SE is specifically geared toward a crucial “weak-link” in the SDLC, namely requirements definition and systems analysis (see the Standish Group’s CHAOS report for statistics on how IT projects suffer—and fail—due to poor requirements definition). At its core, Leap SE is a natural-language processor based on established UML principles. While its user interface is designed for quick and unambiguous requirement composition, its business rules engine is based on DP—a unique methodology that automatically generates logical models from your requirements repository. Leap SE's place in enterprise development is at the beginning—during business rule definition, requirements development, and systems analysis. This is where the greatest opportunity for rapid application development (RAD) lies today. Having completed project planning, analysts begin their business modeling and business rule specifications in the form of natural English statements. From these “shall” statements, the application automatically derives the system’s domain objects, business logic and relationships without requiring any additional work beyond specifying requirements. For Business Rules and Modeling Using plain English, Leap SE translates business rules into logical models for software development. By capturing business processes, relationships, and domain entities in a natural, unfettered way, Leap SE is able to enhance an engineer’s productivity. There are virtually no constraints on vocabulary, only on sentence structure and phrasing, and these “structural” constraints are not only desirable for ensuring proper composition, but are essentially transparent to the user. The result is a consistent set of build-able and testable requirements that can be easily understood by stakeholders at all levels of enterprise engineering. Unlike other products, Leap SE does not dictate a methodology that must be adhered to throughout subsequent phases of the SDLC; it is intended to complement widely regarded “best practices” in systems engineering, software development, and data modeling.
Leap SE’s logical object model is generated in the form of C++ header files. To produce class diagrams, these files can be imported into virtually any reverse-engineering tool. The logical data model generated by Leap SE is rendered in the form of an SQL file. To produce entity-relationship diagrams, the SQL file can be readily run in an RDBMS (e.g., in an MS Access module). Deterministic PhraseologyLeap SE uses Deterministic Phraseology (DP), an emerging methodology in the requirements engineering community. DP provides both a primary and secondary purpose with respect to requirements development. The primary goal of DP is to turn a sentence, written in English, into an objected-oriented abstraction; that is, to turn “shall” statements into class definitions and inter-class relationships. To accomplish this, the greatest obstacles have always been the grammatical nuances and context-specific underpinnings of human language, and English certainly has its share. It’s not only the syntax (punctuation and structure) of English that presents such a formidable challenge; it’s the usage, the array of different meanings of words and phrases used in different combinations. The secondary goal of DP is to provide a natural means of composition. For any tool to accurately derive meaning from sentences for the purpose of software development—and that’s precisely the function of Leap SE—the tool must impose some order, some constraints on the diversity and freedom of expression inherent in human language. Fortunately, many of those who write system specifications already use proper phrasing techniques and know the importance of producing quality requirements. They know, for instance, that a system requirement should be specific, non-ambiguous, scoped to a single function, and testable whenever possible. For those users, DP will make sense, and use of the tool should be second nature. Others, however, who may not have sufficient training, or who may not consistently follow sound composition practices, will benefit from the convenient framework imposed by the tool. So while the primary goal of DP is to transform a collection of sentences into a logical object model, the secondary goal—only slightly less important—is to provide a natural means of composition, to facilitate requirement creation so that adhering to the methodology is virtually transparent to the user. This is the role of the Leap SE templates and Requirement Builder. Requirements EngineeringMore medium-to-large scale software development projects are delayed, derailed, or outright canceled due to poor requirements definition than those that are not. And as any software engineer knows, garbage in equals garbage out. So it’s imperative to craft quality requirements, otherwise we begin building our system on inadequate—or worse yet, misleading—requirements. Leap SE enables a systems engineer to avoid the various pitfalls and traps so often encountered when striving to express a system requirement. Ideally, engineers and domain experts should use Leap SE to create an SRS; but that doesn’t mean an existing SRS cannot be worked into the Leap SE application. Using the 21 available templates and Requirement Builder, users can input an SRS to identify deficiencies, expose ambiguity, and purge the document of subjective, general, and non-testable requirements. Every time a new requirement is saved, Leap SE’s object model database is updated to reflect the new entities, attributes, methods and associations; and an updated directory of header files can be generated at any time. Once header files have been generated, it’s just one small step to importing them into a CASE tool (such as Rational Rose® Analyzer) to produce a host of informative, graphical models. Without question, the single, most important investment a project management team can make—early on—is to invest in the development of a set of quality system requirements. With Leap SE, this has never been more possible. Software DevelopmentOne question that often arises is: "Can the header files produced by Leap SE be used for software development?" The header files can be used for software development, and there is no reason why they couldn’t be built upon; but the true purpose of Leap SE is to produce an accurate logical model of the target system as expressed by your domain-specific system requirements. In the future, with the evolution of DP and Leap SE, it may be possible to go directly from a set of well-phrased system requirements to actual software constructs. Use with Microsoft AccessLeap SE is a database application that uses two (or more) .mdb files compatible with Microsoft® Access versions 97 or later, with data access based on the ODBC standard. In future releases, other relational database file formats (such as Oracle or DB/2) may be supported. During the installation of Leap SE, the application determines the latest version of Microsoft® Access installed on the host computer and ensures that the appropriate AppDB.mdb and ReqDB.mdb files are identified for use. The AppDB.mdb file contains over 70 template examples, while the ReqDB.mdb file contains the schema used by Leap SE. When a new Leap SE file is created (e.g., Acme.lpp), the application creates a companion database file based on the system-supplied <SystemName>ReqDB.mdb file. This new .mdb file, e.g., AcmeReqDB.mdb, becomes your formal repository of system requirements, as well as your dynamically updated object model database. Leap SE draws from the object model database to produce header files that serve as the logical model of your subject system. The philosophy of Leap SE has always been to leverage off of an established RDBMS for comprehensive querying and reporting features. Leap SE does, however, provide a set of queries considered important to the management of an SRS. Requirements CategorizationVarious systems engineering philosophies categorize requirements in different ways, and Leap SE is no different. In Leap SE, a functional requirement is a requirement that expresses a capability or behavior of the system; a structural requirement is the explicit definition of an attribute, entity, or whole-part relationship among entities; and a technical requirement is the specification of a performance or capacity-related criterion, environmental parameter, business objective, etc. that the system must meet or accommodate for sell-off. Consider the following examples: The system shall provide the capability to broadcast departure times every 25 minutes. A storage facility shall include 8 locking doors. Technical Requirement |
|
| Leap SE. . . rapid application develop- ment from the source. | "Capture your business rules and software requirements with Leap SE—the CASE tool that allows you to automatically generate object models and “leap over” systems engineering." | |
|
Copyright © 2007, Leap Systems. |
For product information and sales: sales@leapse.com |