Daniel M. Berry
University of Waterloo
Network
Latest external collaboration on country level. Dive into details by clicking on the dots.
Publication
Featured researches published by Daniel M. Berry.
IEEE Transactions on Software Engineering | 1991
Yoelle Maarek; Daniel M. Berry; Gail E. Kaiser
A technology for automatically assembling large software libraries which promote software reuse by helping the user locate the components closest to her/his needs is described. Software libraries are automatically assembled from a set of unorganized components by using information retrieval techniques. The construction of the library is done in two steps. First, attributes are automatically extracted from natural language documentation by using an indexing scheme based on the notions of lexical affinities and quantity of information. Then a hierarchy for browsing is automatically generated using a clustering technique which draws only on the information provided by the attributes. Due to the free-text indexing scheme, tools following this approach can accept free-style natural language queries. >
automated software engineering | 1997
Leah Goldin; Daniel M. Berry
Abstraction identification is named as a key problem in requirements analysis. Typically, the abstrac-tions must be found among the large mass of natural language text collected from the clients and users. This paper motivates and describes a new approach, based on traditional signal processing methods. for finding abstractions in natural language text and offers a new tool, AbstFinder as an implementation of this approach. The advantages and disadvantages of the approach and the design of the tool are discussed in detail. Various scenarios for use of the tool are offered. Some of these scenarios were used in case study of the effectiveness of rhe tool on an industrial-strength example of finding abstractions in a request for proposals.
ieee symposium on security and privacy | 2003
Christian Denger; Daniel M. Berry; Erik Kamsties
In most current industrial software engineering projects, the majority of requirements documents are written almost entirely in natural language. However, specifying the requirements in natural language has one major drawback, namely the inherent imprecision, i.e., ambiguity, incompleteness, and inaccuracy, of natural language. Since the requirements document forms the basis of the whole development process, such defects can have severe consequences for the whole project. Therefore, it is important to deal with these defects in a requirements specification right from the start. We present an approach for reducing the problem of imprecision in natural language requirements specifications with the use of natural language patterns, which allow formulating requirements sentences in a less ambiguous, more complete, and more accurate way. To ensure the applicability of our approach we based our patterns on a metamodel for requirements statements for embedded systems. With this metamodel, we ensure that all forms of requirements statements are described with the patterns. We validated the effectiveness of the patterns by using them to rewrite a substantial, previously written, requirements specification to eliminate its imprecisions.
Requirements Engineering | 2008
Nadzeya Kiyavitskaya; Nicola Zeni; Luisa Mich; Daniel M. Berry
This paper proposes a two-step approach to identifying ambiguities in natural language (NL) requirements specifications (RSs). In the first step, a tool would apply a set of ambiguity measures to a RS in order to identify potentially ambiguous sentences in the RS. In the second step, another tool would show what specifically is potentially ambiguous about each potentially ambiguous sentence. The final decision of ambiguity remains with the human users of the tools. The paper describes several requirements-identification experiments with several small NL RSs using four prototypes of the first tool based on linguistic instruments and resources of different complexity and a manual mock-up of the second tool.
ACM Transactions on Programming Languages and Systems | 1985
Shaula Yemini; Daniel M. Berry
This paper presents a new model for exception handling, called the replacement model. The replacement model, in contrast to other exception-handling proposals, supports all the handler responses of resumption, termination, retry, and exception propagation, within both statements and expressions, in a modular, simple, and uniform fashion. The model can be embedded in any expression-oriented language and can also be adapted to languages which are not expression oriented with almost all the above advantages. This paper presents the syntactic extensions for embedding the replacement model into Algol 68 and its operational semantics. An axiomatic semantic definition for the model can be found in [27].
Archive | 2004
Daniel M. Berry; Erik Kamsties
This chapter identifies the problem of ambiguity in natural language requirements specifications. After observing that ambiguity in natural language specifications is inescapable when producing computer-based system specifications, a dictionary, linguistic, and software engineering definitions of ambiguity are given. The chapter describes a full range of techniques and tools for avoiding and detecting ambiguity.
Science of Computer Programming | 2002
Daniel M. Berry
Abstract The paper defines formal methods (FMs) and describes economic issues involved in their application. From these considerations and the concepts implicit in “No Silver Bullet”, it becomes clear that FMs are best applied during requirements engineering. A explanation of why FMs work when they work is offered and it is suggested that FMs help the most when the applier is most ignorant about the problem domain.
Journal of Systems and Software | 1995
Daniel M. Berry
This paper examines a number of successful requirements engineering efforts carried out by the author and determines that a critical element in the success of these efforts was the authors ignorance of the clients domain
Innovations for Requirement Analysis. From Stakeholders' Needs to Formal Designs | 2008
Daniel Popescu; Spencer Rugaber; Nenad Medvidovic; Daniel M. Berry
In industry, reviews and inspections are the primary methods to identify ambiguities, inconsistencies, and under specifications in natural language (NL) software requirements specifications (SRSs). However, humans have difficulties identifying ambiguities and tend to overlook inconsistencies in a large NL SRS. This paper presents a three-step, semi-automatic method, supported by a prototype tool, for identifying inconsistencies and ambiguities in NL SRSs. The method combines the strengths of automation and human reasoning to overcome difficulties with reviews and inspections. First, the tool parses a NL SRS according to a constraining grammar. Second, from relationships exposed in the parse, the tool creates the classes, methods, variables, and associations of an object-oriented analysis model of the specified system. Third, the model is diagrammed so that a human reviewer can use the model to detect ambiguities and inconsistencies. Since a human finds the problems, the tool has to have neither perfect recall nor perfect precision. The effectiveness of the approach is demonstrated by applying it and the tool to a widely published example NL SRS. A separate study evaluates the tools domain-specific term detection.
requirements engineering foundation for software quality | 2012
Daniel M. Berry; Ricardo Gacitua; Peter Sawyer; Sri Fatimah Tjong
[Context and Motivation] This paper notes the advanced state of the natural language (NL) processing art and considers four broad categories of tools for processing NL requirements documents. These tools are used in a variety of scenarios. The strength of a tool for a NL processing task is measured by its recall and precision. [Question/Problem] In some scenarios, for some tasks, any tool with less than 100% recall is not helpful and the user may be better off doing the task entirely manually. [Principal Ideas/Results] The paper suggests that perhaps a dumb tool doing an identifiable part of such a task may be better than an intelligent tool trying but failing in unidentifiable ways to do the entire task. [Contribution] Perhaps a new direction is needed in research for RE tools.