Brian BerenbachGeorgia Institute of Technology | GT · Professional Education
Brian Berenbach
MS Thermodynamics, ESEP Certification
About
82
Publications
47,258
Reads
How we measure 'reads'
A 'read' is counted each time someone views a publication summary (such as the title, abstract, and list of authors), clicks on a figure, or views or downloads the full-text. Learn more
1,124
Citations
Introduction
I am currently mentoring in the graduate systems engineering program at the Georgia Institute of Technology.
I retired from Siemens after many years where i was a senior systems engineer, and part time adjunct professor.
Additional affiliations
September 2000 - August 2013
Siemens Corporate Technology
Position
- Senior Systems Engineer
Description
- Conducted research in the following areas: Automated V&V of System Design Visual Languages for the elicitation and analysis of requirements (see papers on the URML) Techniques for predicting inventory requirements
Publications
Publications (82)
The Professional Masters in Applied Systems Engineering (PMASE) program provides students with practical and academic material in a setting like a typical work environment. This paper describes the first course in the two‐year program from the perspective of how a “high touch” course provides learning depth. It describes the approach used to provid...
Systems engineering is a bit different from other engineering disciplines in that students from many disciplines are enrolled in the program. Therefore, the objective is not to teach a simulation subject in depth, but rather to introduce the students to different techniques so that they can work with and manage simulation staff on a project. Howeve...
A method for performing automatic trace retrieval includes receiving a first and second model for a system or service (S10). The first model includes a first plurality of model artifacts at least partially represented by a first semantic style and the second model includes a second plurality of artifacts at least partially represented by a second s...
The U.S. Nuclear Regulatory Commission mandates the use of a replica power plant simulator for the training of operators and conducting of “what if” studies. While nuclear power plants are desirable because of their lack of carbon emission, the potential severity of an accident is devastating (e.g. Fukushima, Chernobyl). Consequently the licensing...
This workshop presentation is primarily for practitioners but also for starting academics who would like to increase their chances of having their conference paper submissions accepted. It describes the process of writing a paper, and goes into detail on mistakes that novices tend to make. It is given from the perspective of someone who has been on...
Technical Debt" is a term first used by Ward Cunningham in an experience report in 1992. 1 The term refers to the accruing debt or downstream cost that happens when short term priorities trump long term lifecycle costs. The term, when introduced, was used in the context of the development of software systems. However, since 1992, the field of syste...
Since 2005, the international organization for standardization (ISO) has published a wealth of standards and reports that deal with requirements engineering for systems. ISO/IEC/IEEE 24765 defines a standard vocabulary for systems and software engineering. ISO/IEC 24766 defines requirements for requirements engineering tools. ISO/IEC/IEEE 29148 des...
This paper gives an overview of the Unified Requirements Modeling Language (URMLTM) and shows how it integrates concepts from the hazard analysis, product line modeling, and goal modeling domains. The meta-model is explained by example diagrams showing the concepts and notation of the language. The notation is explained and its major icons are pres...
Early modeling languages have focused on the analysis and the design of systems under construction, but not on requirements elicitation. Consequently, a wide variety of approaches exists for the early phases of requirements engineering, modeling various concepts as stakeholders, goals, features, product lines, systems, processes, risks, and require...
Attempts to utilize information retrieval techniques to fully automate the creation of traceability links have been hindered by terminology mismatches between source and target artifacts. Therefore, current trace retrieval algorithms tend to produce imprecise and incomplete results. In this paper we address this mismatch by proposing an expert syst...
The Unified Requirements Modeling Language (URML) was created to support
early systems engineering; permitting the capture of process, potential variation points,
hazards, threats and mitigations during the elicitation process. It has been used on Siemens
projects, but to date they have been proprietary, precluding public exposure and limiting the...
The current implementation of the SysML tends to be design-centric with minimal support for activities upstream of design such as product line engineering, goal conflict resolution and hazard/threat modeling. Furthermore, currently provided extensions, such as those for business modeling, tend to be narrowly focused. This paper describes ongoing re...
During model-driven requirements elicitation sessions for several commercial products, weaknesses were identified with available modeling languages such as UML and SysML. Continued frustration when attempting to use the UML for requirements capture eventually resulted in collaboration between Siemens and Technische Universität München (TUM) to defi...
Effective traceability can be very costly and difficult to achieve in mechatronics systems due to their overall size and complexity. Such systems are often specified and designed in terms of software, electrical, mechanical, and thermodynamic elements, and associated models are represented and stored in various formats and locations. Traceability i...
While many engineers are familiar with Model-Driven design and architecture, Model-Driven Requirements Engineering is still, for a variety of reasons, not widely accepted. Although introduced formally at the First International Workshop on Model-Driven Requirements Engineering (MDRE) in San Diego in 2001, the value proposition is still not clear, t...
The present invention provides a graphical user interface for presentation, exploration and verification of patient information. In various embodiments, a method is provided for browsing mined patient information. The method includes selecting patient information to view, at least some of the patient information being probabilistic, presenting the...
[Context & motivation] Large contractual projects often have to comply against government regulations and standards. [Question/problem] In such a context, the contractual document can be voluminous, and there can be a large number of standards and regulations to follow. These documents typically form a complex interrelationship network. This means...
A system for hazards analysis includes: a memory device for storing a program; a processor in communication with the memory device, the processor operative with the program to: access the memory device to obtain information specifying a system to be analyzed; build functional block diagrams using the information specifying the system to be analyzed...
In contractual systems engineering projects, the developing organization is often required to demonstrate compliance of the system’s requirements against a myriad of engineering standards and government regulations. In order to satisfy this goal, the project requirements imposed by standards and regulations through the contract need to be traceable...
As standards and regulatory codes are issued by third party organizations and committees, the project organization can neither control the content of all standards that the projects should adhere to, nor negotiate or make changes to them that can make the project development easier. Moreover, large infrastructure projects require compliance with hu...
Requirements elicitation and management for contract based projects is significantly more complex than for product or product line development. For example, many practitioners are unaware of the fact that the traditional “V” model for requirements tracing does not work where there is a legal contract describing project deliverables; nearly every as...
Requirements engineering processes in the large are very different from those on small to medium size systems. Most texts on requirements engineering, for example tend to describe small or medium scale systems (up to about 5K requirements), or if the systems are large, describe the processes associated with product development and product lines. In...
This panel discussion will explore aspects of systems engineering where some engineers fear to tread. Some of the topics explored will include:
Should there be requirements engineers at all on systems development projects?
Can any systems engineer do requirements engineering (RE) well? If not, what additional training would be most useful?
Is RE re...
A method for modeling requirements of a product includes defining an abstract use case for each feature of said product, hierarchically decomposing each abstract use case until concrete use cases are specified for each feature, depicting every actor who would use the product as communicating with a concrete use case through a boundary, and programm...
The challenges of implementing successful and cost-effective traceability have created a compelling research agenda that has addressed a broad range of traceability related issues, ranging from qualitative studies of traceability users in industry to very technical and quantitative studies. Unfortunately, advances are hampered by the significant ti...
[Context & motivation] Growing software companies with increasing product complexity face the issue of how to scale up their
Requirements Engineering (RE) practices. In market-driven requirements engineering, release planning and scoping decisions
are increasingly challenging as the size and complexity increases. [Problem] This paper presents initi...
Context & motivation] Growing software companies with increasing product complexity face the issue of how to scale up their Requirements Engineering (RE) practices. In market-driven requirements engineering, release planning and scoping decisions are increasingly challenging as the size and complexity increases. [Problem] This paper presents initia...
Requirements engineering (RE) for complex industrial systems can defy traditional processes and tooling. Some topics, such as managing requirements for contract based and regulated systems are rarely mentioned in the literature. Market forces such as increased staff turnover and reduced development times are changing the way products and services a...
The authors have observed that traditional requirements engineering practices are inadequate to support large projects that are defined by a contract. Unlike a product development effort, contract requirements are not at a uniform level so the typical “V” model for tracing does not work well. Other important attributes of contracts such as penalty...
Requirements engineering for complex systems often requires inter-disciplinary collaboration between domain experts who might not have software or systems engineering background. Existing requirements modeling languages unfortunately do not support this scenario well. First, the visual notation of languages like UML or SysML does not follow scienti...
Requirements engineering processes in the large are very different from those on small to medium size systems. Most texts on requirements engineering, for example tend to describe small or medium scale systems (up to about 5K requirements), or if the systems are large, describe the processes associated with product development and product lines. In...
Requirements elicitation and management for contract based projects is significantly more complex than for product or product line development. For example, many practitioners are unaware of the fact that the traditional “V” model for requirements tracing does not work where there is a legal contract describing project deliverables; nearly every as...
Students in a computers-and-society course learning ethics were given a test to measure the test taker's ethicality both before and after learning ethics. The data show that learning ethics had no effect on the student's ethicality. In some ways, the students were actually slightly more expedient after learning ethics.
This is a report of a workshop on Leadership and Management in Software Architecture held at ICSE on May 19, 2009.
Software architecture, in education and practice, is primarily concerned with technical issues associated with the quality of software architecture and design. However, as project size increases, leadership, management skills, and the organizational context of the architect become more important, to the point where the non-technical duties of the p...
The authors identify, categorize, and name nine specific ethical and professional dilemmas in software engineering, placing them in the context of the IEEE code of conduct, with the hope that giving such behavior a name will increase awareness and decrease the frequency with which these dilemmas occur.
A method for extracting requirements of an architectural software model comprises providing a use case model as a directed graph of the architectural software model comprising nodes corresponding to use cases and relations between nodes, and creating, automatically, a tree comprising a root node corresponding to an abstract use case and at least on...
A research has studied different views of suppliers and customers have of solution projects that include both provided goods and rendered services. The goal of the research is to help the suppliers and customers to understand each other better, and therefore make solution projects more profitable for the suppliers and be more effective for the cust...
Successful software development involves the elicitation, implementation, and management of critical systemic requirements related to qualities such as security, usability, and performance. Unfortunately, even when such qualities are carefully incorporated into the initial design and implemented code, there are no guarantees that they will be consi...
In 2003, the Software & Engineering department (S&E) at Siemens Corporate Research (SCR) initiated the training of Siemens employees worldwide in requirements engineering (RE). The first courses taught were customized for the target audience and taught onsite. In 2005, a standardized foundation course was created; the first course in a suite of off...
Industrial training imposes some unique restrictions on pedagogical methods, both in terms of ascertaining retention, fostering class participation, and reinforcement. The reinforcement pedagogical pattern has now been used successfully in training courses and workshops at Siemens AG with positive results. This brief paper describing the reinforcem...
This is a report of the Leadership and Management in Software Architecture workshop that took place at ICSE 2008. The workshop focused on the non-technical aspects of software architecture. In particular, it focused on the skills that a software architect should have as well as the type of support an organization should provide for the architect.
The skills that are taught to the software architect in academic programs often leave him or her completely unprepared to assume the role of solution architect on a project with more than four or five developers. Furthermore, the globalization of software development has created a need for architects that can effectively manage multiple teams at mu...
Finite state machines are a widely used concept for specifying the behavior of reactive systems. Numerous graphical notations based on finite state machines have been developed and are commonly used today, such as state transition diagrams, Harel statecharts, and Unified Modeling Language (UML) state machine diagrams. While not as widely used, tabu...
Software architecture, in education and practice, is primarily concerned with technical issues associated with the quality of software architecture and design. However, as project size increases, leadership, management skills, and the organizational context of the architect become more important, to the point where the non-technical duties of the p...
Empirical studies have shown that the use of a product line approach to software development can result in shorter time to market and improved productivity. Outsourcing and distributed development has added a new dimension to product management, exacerbating problems associated with transitioning from marketing studies to product definition to anal...
In global development projects, different modeling techniques are used to create and manage the requirements, analyze the problem domain, identify potential hazards and develop the system design. For each modeling technique, separate tools (e.g. UML case tool, requirements database, Word) are used. Each tool comes with its own meta-model, which hin...
Traceability helps determine that researchers have refined requirements into lower-level design components, built them into the executable system, and tested them effectively. It further helps analysts understand the implications of a proposed change and ensures that no extraneous code exists. Unfortunately, many organizations fail to implement eff...
Models are frequently used for illustrations in software design documents. Commonly they are used to show static structure and less often, external dynamic behavior. However, in software engineering, the lack of conceptual models often inhibits creativity and understanding, which may in turn lead to incomplete or poor design. This paper describes o...
This is an invited talk that was given at the 14th International IEEE Requirements Engineering Conference in 2006. It describes the presenters frustration with the then current state of the art and practitioner skill level in a humorous way, while presenting some of the colossal failures that have resulted from poor RE practices.
Eliciting complete and correct requirements is a major challenge in software engineering and incorrect requirements are a constant source of defects. It often happens that requirements are either recorded only partially or not at all. Also, commonly, the rationale behind the requirements is not recorded or may be recorded, but is not accessible for...
One of the problem areas in requirements engineering has been the integration of functional and nonfunctional requirements and use cases. Current practice is to partition functional and nonfunctional requirements such that they are often defined by different teams. Functional requirements are defined by writing text-based use cases or, less frequen...
Poirot is a Web-based tool supporting traceability of distributed heterogeneous software artifacts. A probabilistic network model is used to generate traces between requirements, design elements, code and other artifacts stored in distributed 3rd party case tools such as DOORS, rational rose, and source code repositories. The tool is designed with...
Summary form only given. This talk describes experiences and lessons learned while defining product requirements for small and large companies over a thirty-year period. From 1969 to the present the author has assisted or led teams in the definition of requirements for a wide variety of products and systems, including music information, produce del...
The CMMI defines two process areas associated with requirements elicitation: Requirements Development (RD) and Requirements Management (REQM). The Measurements and Analysis process area (MA) requires measurements and quantitative objectives for RD and REQM, but nowhere does it state what those measurements are. Furthermore, in order to extract meas...
The requirements engineering program at Siemens Corporate Research has been involved with process improvement, training and project execution across many of the Siemens operating companies. We have been able to observe and assist with process improvement in mainly global software development efforts. Other researchers have reported extensively on v...
Requirements elicitation and management has become ever more important as products become more complex and time to market is shortened and the definitions of product lines has significantly increased project complexity. Outsourcing has added a new dimension to requirements management, exacerbating problems associated with transitioning from analysi...
Automated analysis of object-oriented design models can provide insight into the quality of a given software design. Data
obtained from automated analysis, however, is often too complex to be easily understood by a designer. This paper examines
the use of an automated analysis tool on industrial software UML class models, where one set of models wa...
There appears to be a real dichotomy in the use of the UML vs. text based Use Case development for requirements elicitation and documentation, that is, on those projects where use cases are work products. Not only are there different processes in place for text and graphical use case modeling, but also there are a variety of approaches and philosop...
This paper describes techniques for analyzing largeUML models. The first part of the paper describesheuristics and processes for creating semantically correctUML analysis and design models. The second part of thepaper briefly describes the internal DesignAdvisorresearch tool that was used to analyze Siemens models.The results are presented and some...
One of the problem areas in requirements engineering has been the integration of functional and non-functional requirements and use cases. Current practice is to partition functional and non-functional requirements such that they are often defined by different teams. Functional requirements are defined by writing text-based use cases or, less frequ...
We have observed that often there is a disconnect between a UML model and the requirements of the modeled processes. This gap tends to widen as models become more complex and the extraction of detailed requirements becomes more difficult. The process by which detailed requirements are extracted from a model is fairly straightforward. Not only can t...
Many Siemens operating companies build software products or products with a high software content (e.g. embedded software). Siemens Corporate Research has had the unique opportunity over the last few years to look at the analysis models from which the software products were derived, analyze them, and recommend changes. All the models investigated d...
The recent redesign/upgrade of ABB's CETRAN simulation environment coincided with major changes in the approach to software engineering of complex, real-time, computer-based systems. The latest version of CETRAN was constructed incorporating elements of both distributed and object-oriented programming (OOP) models. The man-machine interface, or ins...
A real-time simulator was developed using FORTRAN 77. A generic operating system interface library (GOSIL) was used to isolate machine specific system services and simplify the simulator software design. The GOSIL was implemented on several other minicomputers with radically different architecture from VAX/VMS and the simulator was then ported with...
A major cost component in the life of a nuclear or fossil power plant training simulator is the one associated with the development, modification and maintenance of the simulated plant models. Therefore, as computer and simulator technology evolved over the years, considerable emphasis was placed on the development of software tools and methodologi...
Building environmentally friendly software and hardware systems is about understanding and respecting the requirements that are imposed by climate change or regulation. This is especially true, as those systems often require inter-disciplinary collaboration between domain experts who might not have a software or systems engineering background. Exis...
This ICB Research Report constitutes the proceedings of the following events which were held during the Requirements Engineering: Foundation for Software Quality (REFSQ) conference 2011 in Essen, Germany. Requirements Engineering Efficiency Workshop (REEW). Requirements Prioritization for customer-oriented Software-Development (RePriCo). Workshop o...
An engineering or science education at the university/college level should be sufficient for the new graduate to successfully integrate into the workplace. Unfortunately, the requirements engineering subject area is not part of the core curriculum at most universities and colleges. When technical staff does not have an elementary understanding of r...
Thesis (M.S.)--Emory University, 1967, Dept. of Chemistry, Dr. H. Lawrence Clever. Typewritten. Bibliography: l. 29.
The surface tension of p-difluorobenzene and hexafluorobenzene was measured between 25° and 45°C. by the maximum bubble pressure method. The surface tension and density of eight p-difluorobenzene-p-xylene mixtures were measured at 30°C. Both the excess volume and excess surface tension of the solutions show a change in sign near 0.8 mole fraction p...