|
|
| System Requirements: As Important as Ever Back | |
|
System requirements are the bedrock upon which a software development project is built. Their importance is far-reaching and critical to the design of the software that will run the system. They take center stage at both the beginning and end of a project, as well as during sell-off. They define the scope of the system and typically accompany a Statement of Work (SOW) as part of a project’s contractual documentation. During acceptance testing, they are used to validate the finished product and serve as criteria to ensure that the new system meets specifications. Given the importance of system requirements, it is imperative that they be complete and of the highest quality (within reason, of course). Completeness is essential for several reasons. If the necessary system functionality is not sufficiently defined, how will software developers know what to build? Contrary to what some may believe, most software engineers are not endowed with psychic powers. Should they improvise? To some extent they always will. But a program lacking system requirements often falls into the “bring me a rock” approach to software development, the dysfunctional, seemingly endless cycle of trial and error that balloons program cost and schedule. With inadequate requirements, engineers are forced to “figure it out as they go”. They find themselves hounding the customer for badly needed, last-minute system definition that may come from different departments or functional areas and ultimately lead to a tangential body of requirements that conflict with overall business and operational objectives. If requirements are vague, general, or worse yet ambiguous, odds are good that the wrong capabilities will be built, capabilities that fall short of—or wholly miss—end user needs. This is the quality dimension. Poorly written requirements require clarification from the customer; they’re difficult to build to and test; they’re often subject to interpretation and wind up dependent on informal agreements regarding “what’s needed to pass the requirement”. This is where sell-off can become ugly, where pass/fail criteria can be as stable as Jell-O. |
|
| Desperately Seeking RAD | |
|
So what can be done in the space of requirements engineering to set a project firmly on the road to success? How can a project develop a complete set of quality requirements that speeds up the systems development lifecycle instead of setting it off on a floundering course toward budget overrun? Assuming contributors in the authoring process are competent, what methodologies can they follow to quickly develop a set of comprehensive system requirements? The Zachman framework comes to mind, which emphasizes the unique perspectives and interests of diverse groups in an enterprise. Another alternative is the Object Management Group’s (OMG’s) Model-Driven Architecture (MDA), which models domain requirements in an abstract manner that provides a pathway to yet other Unifier Modeling Language (UML)-style, physical models. A third approach is Deterministic Phraseology from Leap Systems, which provides a grammatical interpretation strategy for translating system-level requirements directly into UML-based header files. Each has a fundamental philosophy that governs its framework and offers distinct advantages. |
|
| MDA | |
|
MDA, much like the Zachman framework, is intended to encompass the entire systems software development effort as a complete enterprise solution. For the systems engineer using MDA, there are a host of terms, concepts, models and acronyms to become familiar with, such as Business Process Models, Business Domain Models, Computation Independent Models, a Platform Independent Component View, and—most importantly—the Platform Independent Model (PIM). According to Michael Brassard and Mario Cardinal, “When creating MDA-based applications, the first step is to create a PIM, which you should express in UML. MDA uses the PIM to represent the logical view in which the composition and behavior of all components (but not their implementation) are fully specified.” (Software Developer, “Addressing Problems with Model Driven Architecture”, 5/14/02) Systems engineering with MDA is rooted in model creation, where UML dictates the modeling process and engineering artifacts (contrast this with the Entity-Relationship Diagram-based techniques that Zachman enthusiasts seem to favor). The strength of MDA lies in its ability to map the transition from logical models to physical models across various platforms and technologies. The refinement process, from PIMs to Platform-Specific Models (PSMs), enables MDA to incorporate many facets of an enterprise’s rules and architecture. In addition, MDA supports UML’s Object Constraint Language (OCL) for defining preconditions and post-condition, interfaces and parameter specifications. In this way, MDA acts as an abstract-to-concrete coordination framework for system definition and traceability. And like the Zachman framework, it considers the different viewpoints of stakeholders throughout the organization. MDA, however, is rather rich in its proliferation of process artifacts. An analyst joining an MDA project can expect to speak in terms of shared patterns, refinements, realizations, mappings, transformations, Domain Task Forces, viewpoints, pervasive services, MOF, CWM, DTC, OCL, IDL, etc. To quote the OMG specification: “In MDA, one of the key features of the whole approach is the notion of mapping. A mapping is a set of rules and techniques used to modify one model in order to get another model. Mappings are used for transforming… (and) all these artifacts are traced and versioned.” One cannot help but think that MDA might be overdoing a good thing (namely UML), and that the maintenance of such a volume of interrelated models—drawn from different viewpoints and levels of abstraction in the model hierarchy—would be a configuration management (CM) nightmare in practice. The PIM, at MDA’s core, is essentially a UML diagram. As the specification states: “The first step when constructing an MDA-based application is to create a PIM of the application expressed in UML using the appropriate UML profile.” Assembling, transforming, mapping, and refining these PIMs for use in the MDA framework is what MDA offers systems engineers. And yet as Brassard and Cardinal assert in their Software Developer article: “MDA has no significant impact during the Requirement and Analysis phase.” In some respects, the breadth of the methodology rings of enterprise resource planning (as does Zachman’s framework). Without question, a program choosing MDA needs to be wholly committed to the methodology, should allow for a learning curve, and will need to institute an elaborate CM process. |
|
| The Zachman Framework | |
|
In contrast, the Zachman framework is much less prescriptive regarding which methods and models to use when approaching a system-definition task. Zachman’s greatest contribution to the problem of enterprise analysis is his characterization of distinct “views” maintained by different technical and business-domain stakeholders in both the creation and use of the system. In Zachman’s framework, the organizational structure and business locations of an enterprise are added to the equation, for instance. His matrix highlights different perspectives from key “roles” in the IT-business environment (rows of the matrix) distributed over the major “areas of consideration” (columns). Exposure of these roles and focus areas becomes a guide to those who can identify with a particular view. If I am a programmer, for instance, I can focus on the Builder View to understand what I need to address in my areas of concern (the cells within my row). This contribution from Zachman gives us a way to ensure we have covered all the bases in our planning, analysis, design, development, and integration efforts. Not only does Zachman refrain from prescribing a set of models or tools for a particular cell in his matrix, he concedes that there may not be any CASE tools or well-defined techniques available for addressing certain cells. What does this mean to the requirements engineer? While the Zachman framework identifies key areas for consideration in its Planner’s View and Owner’s View, it does not offer any kind of substantial RAD solution. It is much like an elaborate checklist that illuminates the complete dimensions and depth of enterprise operation and development. In a sense, MDA can be seen to share Zachman’s vision. By “zooming out” to abstract UML diagrams and then relying on patterns and mappings to bring it all together, MDA seeks to satisfy many of the cells of Zachman’s matrix. Tools for implementing MDA are available, but the burden of conceptualizing the necessary logical models is still there…and the burden rests firmly on the analyst’s shoulders. |
|
| Deterministic Phraseology | |
|
Unlike the Zachman framework and MDA, Deterministic Phraseology (DP) is focused on how to achieve RAD from a requirements base, and its solution is drawn directly from the requirements themselves. DP shares a natural compatibility with MDA in that its header file output is based on UML. It also fits well into the Zachman matrix, playing a role in both the Data and Function columns of the Planner, Owner, and Design Views. Developed by Leap Systems in 2003, DP is at the heart of the company’s Leap SE application, a CASE tool that offers templates and a requirement builder for creating requirements consistent with the methodology. Unlike the MDA and the Zachman “enterprise” methodologies, DP operates on English exclusively to perform analysis of the problem domain. Knowledge of OOA and relational modeling is useful, but not necessary. The user does need to know what an attribute is, however, as well as the difference between an entity, a type and a part. A requirement composed in Leap SE is split up among fields that combine to form a sentence that, when saved, is added to an object model database. From this object model database, a directory of header files is produced that serves as the logical object model of the subject system, a logical object model gleaned directly from the domain-specific system requirements. This allows the user to focus on requirement expression and accuracy rather than on how modeling should be done, thereby removing much of the analysis burden. In this way, Leap SE enforces the crafting of both build-able and testable requirements that are, in the end, consistent with the DP methodology. Although all three can be said to be RAD methodologies in that they “speed up the software development process under some circumstances”, DP makes the greatest claim to RAD by automating a significant part of the analysis effort. DP-validated requirements read like any other system requirement written in English and can be readily understood by stakeholders at all levels of technical proficiency, from end user to executive. Unlike the MDA methodology, the learning curve to creating requirements with DP is trivial, due in large part to features of Leap SE that guide the user to proper composition. Moreover, the header files generated by Leap SE can be imported into virtually any reverse-engineering tool that supports OO languages to produce class diagrams. The next article in this series, “Systems Analysis and RAD: Interpreting Grammar” will focus on the challenges of interpreting English grammar for the purpose of systems analysis and high-level software design. Author Information:
|
|