Categorizing requirements based upon their aspects and stakeholder intent can help requirements engineers and other developers to group and retrieve the requirements for analyzing the aspects of concern. The analysis is essential for project planning, system verification and validation, and integration coordination. For software requirements, researchers and practitioners have identified a set of categories, such as functional, performance, safety, to categorize a requirement. In a large systems engineering and integration project comprised of not only software but also hardware and activities in other disciplines (e.g., electrical, civil engineering), we encountered many additional, different aspects of the system that need to be analyzed and thus the requirements need to be categorized for those aspects. This experience report describes the lessons learnt in categorizing requirements in this project. The report provides insights for the practical issues of the categorization and our research on how more effectively the categorization could be done.

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 customers. We are involved in an infrastructure improvement project that shares many characteristics of a solution project. Our early experience suggests introducing a contractor view that is different from the supplier and customer views. Our experience also indicates that effective requirements engineering, under the constraint of lengthy and complex contractual requirements is of great importance for the project success.

Employing a software platform is an approach to achieve a higher degree of software reuse since multiple software products can share the platform-provided services. However, the platform development usually involves stakeholders from different application domains. Their application situations vary widely and thus Non-Functional Requirements (NFRs) for the software platforms must address a wider range of needs than those for a single product. This paper describes our practical experiences in developing NFRs for a large software platform, the challenging issues we faced, and the techniques we used to address those issues. Our pragmatic techniques helped with NFR reconciliation and management, and improved the quality of the NFR definitions. The quality of the NFR specifications has permitted automation of the platform performance testing for the past two years.

Healthcare software systems are becoming more and more complex since they will be highly integrated to support a wide variety of healthcare workflows (e.g., financial, administration, diagnosis, and treatment). In addition, healthcare software systems will be more safety-critical as they will provide medical decision support for doctors. All of those require systematic and thorough testing of the systems before they are put into use or upgraded. Model-Based Testing (MBT) is an approach to apply formal, explicit system use-models to generate the test cases for testing the system behaviors under different input data sets. This paper describes our experiences in applying this approach to testing some Siemens healthcare software systems. We will report the benefits and challenges in using MBT for testing healthcare software systems.

Developing and using a software platform is an approach to achieve a higher degree of software reuse and to reduce the software development cost. Because of the advantages of the service oriented architecture (SOA), many software platforms are built with SOA. This paper describes, based upon our experiences, the most challenging issues in developing non-functional requirements for such platforms.

Medical informatics and software engineering researchers have studied how to use software technologies to define, analyze, automate, and provide decision support for healthcare workflows. We, as the requirements engineering and prototyping group of the Siemens R&D center, have been involved in the research and development of both financial and clinical healthcare workflows. During interactions with the workflow users (e.g. physicians, nurses), researchers and software developers, we found significant confusion about the terminologies and the purposes of supporting different healthcare workflows. Thus, we are motivated to classify computer-aided healthcare workflows, including their approaches, goals, and major characteristics. This paper also discusses workflow application issues and software challenges based upon our experiences and research.

Over the years, medical informatics researchers have studied how to use software technologies to provide decision support for using evidence-based medical procedures. Software professionals have investigated how to support hospital administration, therapy and laboratory workflows. For many of these efforts, managing the exceptions in the workflows is a key issue since the medical workflows must cope with a wide variety of patient medical situations as well as those of the healthcare environments. This paper presents an analysis of past research in managing medical workflow exceptions, and proposes future research that would benefit the medical applications. The paper is focused on three topics: representing, handling and analyzing exceptions. Based upon our analysis, we believe that techniques for verifying exception management models and for handling dynamic exceptions should be useful and possibly essential for developing large scale, practical medical workflow systems.

Medical informatics and software engineering researchers have studied how to use software technologies to define, analyze, automate, and provide decision support for healthcare workflows. We, as the requirement engineering and prototyping group of the Siemens R&D center, have been involved in the research and development of healthcare workflows. During interactions with the workflow users and developers, we found significant confusion about the terminologies and the purposes of supporting different healthcare workflows. Thus, we are motivated to classify computer-aided healthcare workflows, including their approaches, goals, and major characteristics. This paper also discusses workflow application issues and software challenges based upon our experiences and research.

In this paper, we consider a supply chain with one supplier and two retailers, where the supplier offers the Group Buying Auction (GBA), a novel pricing mechanism, to attract the small-sized retailers who cannot enjoy the low price in the traditional quantity discount. We deal with the situation where the market demand for each retailer is random and independent, and the retailers are noncooperative in placing their orders. By applying the noncooperative game theory, we derive the retailers' optimal strategies and show that the retailers will get more profits under the GBA than those under the traditional quantity discount mechanism.

This paper defines a highly concurrent, yet integrated software prototyping process for defining requirements. The process is particularly aimed at developing user-interface intensive, workflow-centered software. The Software Engineering Department and User Interface Design Center at Siemens Corporate Research (SCR) have successfully practiced this process in prototyping a healthcare information system over the last year to identify a set of preliminary functional requirements for the corresponding product. The prototype developed is intended to be of high quality, customizable and thus it can aid the communication between a company's marketing team and Siemens customers to further refine the product requirements. Our experience with this process demonstrates that it is feasible and effective to carry out the requirements definition and prototyping in a highly concurrent fashion given stable prototype software architecture and the readily available domain knowledge.

The group-buying auction is a new kind of dynamic pricing mechanism on the Internet. It is a variant of the sellers' price double auction, which makes the bidders as a group through Internet to get the volume discounts, i.e., the more bidders bid, the lower the price of the object being auctioned becomes. In this paper, we analyze the group-buying auction under some assumptions, such as that the independent private values (IPVs) model applies and bidders are risk neutral and symmetric, etc., and build an incomplete information dynamic game model to illustrate the bidders' bidding process. It proves that for the bidders there exists a weakly dominant strategy S, i.e., no matter when a bidder arrives at the auction and what the bidding history is, the highest permitted bid price that is no greater than his value to the object is always his optimal bid price but may not be the unique one.

Using systematic development processes is an important characteristic of any mature engineering discipline. In current software practice, software design methodologies (SDMs) are intended to be used to help design software more systematically. This paper shows, however, that one well-known example of such an SDM, Booch Object-Oriented Design (BOOD), as described in the literature is too imprecise and incomplete to be considered as a fully systematic process for specific projects. To provide more effective and appropriate guidance and control in software design processes, we applied the process programming concept to the design process. Given two different sets of plausible design process requirements, we elaborated two more detailed and precise design processes that are responsive to these requirements. We have also implemented, experimented with, and evaluated a prototype (called Debus-Booch) that supports the execution of these detailed processes.

Introduces a systematic and defined process called "comparison of design methodologies" (CDM) for objectively comparing software design methodologies (SDMs). We believe that using CDM will lead to detailed, traceable, and objective comparisons. CDM uses process modeling techniques to model SDMs, classify their components, and analyze their procedural aspects. Modeling the SDMs entails decomposing their methods into components and analyzing the structure and functioning of the components. The classification of the components illustrates which components address similar design issues and/or have similar structures. Similar components then may be further modeled to aid in more precisely understanding their similarities and differences. The models of the SDMs are also used as the bases for conjectures and analyses about the differences between the SDMs. This paper describes three experiments that we carried out in evaluating CDM. The first uses CDM to compare Jackson System Development (JSD) and Booch's (1986) object-oriented design. The second uses CDM to compare two other pairs of SDMs. The last one compares some of our comparisons with other comparisons done in the past using different approaches. The results of these experiments demonstrate that process modeling is valuable as a powerful tool in analysis of software development approaches.>