Demo Data from EDBT 2026 / reviewers in the wild / expert
Linda H. Rosenberg
dblp:45/883
· DBLP profile ↗
3ranked-venue papers
0as first author
0since 2021 · last 1997
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 3
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Software engineering, system software, and programming languages
2 papers |
Requirements engineering and software design · 60% Software testing · 20% Empirical software engineering · 20% |
Topics — the 5 heaviest of 5, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Requirements engineering and software design › requirements analysis
natural language requirements analysis |
0.0 | 1 | 1997 | Automated Analysis of Requirement Specifications · ICSE 1997 |
Requirements engineering and software design
requirements analysis |
0.0 | 1 | 1997 | Automated Analysis of Requirement Specifications · ICSE 1997 |
Software testing › specification-based testing
requirements-based testing |
0.0 | 1 | 1997 | Measuring Requirements Testing · ICSE 1997 |
Requirements engineering and software design › requirements quality
requirements quality assessment |
0.0 | 1 | 1997 | Automated Analysis of Requirement Specifications · ICSE 1997 |
Empirical software engineering
software metrics |
0.0 | 1 | 1997 | Measuring Requirements Testing · ICSE 1997 |
Methods — techniques the papers use, named apart from their topics
project data analysis · 0.0natural language processing · 0.0metrics · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 1997 | Measuring Requirements TestingabstractRequirements are written to specify the functionality of a completed software system.Software systems are often released in segments called builds, each one adding new functionality and satisfying an additional set of requirements.New software requirements tools are allowing quality assurance engineers to develop and use new metrics to assist them in evaluating the relationships of requirements to tests, thus ensuring the required functionality in the new system.NASA's Goddard Space Flight Center is applying new tools and technology to measure the effectiveness of requirements testing.This paper discusses an effort that uses project data to demonstrate metrics effectiveness. Theodore Hammer, Linda H. Rosenberg, Lenore Huffman, Lawrence E. Hyatt |
ICSE | 2 |
| 1997 | Automated Analysis of Requirement SpecificationsabstractIt is generally accepted that poorly written requirements can result in software with the wrong ftmctionality.The Goddard Space Flight Center's (GSFC) Software Assurance Technology Center (SATC) has developed .anearly life cycle tool for assessing requirements that are specified in natural language.The tool searches the document for terms the SATC has identified as quality indicators, e.g.weak phrases.The reports produced by the tool are used to identify specification statements and structural areas of the requirements specification document that need to be improved.The metrics are used by project managers to recognize and preclude potential areas of risk. William M. Wilson, Linda H. Rosenberg, Lawrence E. Hyatt |
ICSE | 2 |
| 1997 | Requirements Metrics - Value AddedabstractSummary form only given. Actions in the requirements phase can directly impact the success or failure of a project. It is critical that project management utilize all available tools to identify potential problems and risks as early in the development as possible, especially in the requirements phase. The Software Assurance Technology Center (GSFC) and the Quality Assurance Division at NASA Goddard Space Flight Center are working on developing and applying metrics from the onset of project development, starting in the requirements phase. This talk will discuss the results of a metrics effort on a real, large system development at GSFC and lessons learned from this experience. The development effort for this project uses an automated tool to manage requirements decomposition. This report focuses on the metrics used to assess the requirement decomposition effort and to identify potential risks. The report discusses how metric analysis in the requirements phase can be accomplished on any government or industry project. The use of an automated tool to manage requirement development facilitation of metrics for improved insight into development and risk assessment will also be expanded. Theodore Hammer, Linda H. Rosenberg, Lenore Huffman, Lawrence E. Hyatt |
RE | 2 |