In this paper we identify the fundamental differences between webbased and conventional software engineering. We express our views about why we think requirements engineering for web-based application development should be easier than requirements engineering for conventional software development. We will examine the consequences of holding such a position and propose a more effective process model for web-based application development. Given that we hold such view, we believe that we can do a better job of requirements engineering than is currently being practiced in web-based application development. We conclude by showing why we believe this is a promising area for investing research efforts.

Abstract not found

Abstract. We present a model-based methodology for requirements traceability proposed in the framework of the MeMVaTEx project. The methodology relies on the EAST-ADL language and the two UML 2.0 profiles: MARTE for real-time embedded systems, and SysML for system requirements modeling. Along the paper, we illustrate the proposed methodology by an automotive case study, namely a knock controller, focusing on the time aspects of the requirements specified with the MARTE UML 2.0 profile. We explain how to define the requirements according to a proposed classification, and we present the tracing mechanisms based on the SysML UML 2.0 profile. Finally, we describe the proposed MeM-VaTEx methodology which extends the EAST-ADL methodology in order to take into consideration the expression of requirements, and their traceability along the life cycle.

In this paper we present components of a newly developed software process improvement model that aims to represent key practices in requirements engineering (RE). Our model is developed in response to practitioner needs highlighted in our empirical work with UK software development companies. We have now reached the stage in model development where we need some independent feedback as to how well our model meets our objectives. We perform this validation through involving a group of software process improvement and RE experts in examining our RE model components and completing a detailed questionnaire. A major part of this paper is devoted to explaining our validation methodology. There is very little in the literature that directly relates to how process models have been validated, therefore providing this transparency will benefit both the research community and practitioners. The validation methodology and the model itself contribute towards a better understanding of modelling RE processes.

Formal specifications are becoming more widely used in developing computer systems. They are gaining acceptance as an important component of methods for developing high-quality software. Data modelling at the conceptual level has always been a major part of database design of information systems in general. A data model is a set of conceptual tools for describing relevant properties of the system under consideration, and it consists of three distinct, yet closely interrelated parts: the data structure description, a set of operations for data update and retrieval and a set of constraints that data values must satisfy in order to be considered valid. The relational model, first introduced by Codd in 1970, has undergone a certain amount of revision and refinement since its original definition. The last version of it, RM/V2, was defined by Codd in 1990 by preserving all existing features of ... The formal notation that we use is Z, a model-oriented specification which is widely used in industry as part of the software development process.

Abstract. In this manuscript, we discuss several challenges for analyzing qualitative data in a study composed of an international research project team. The subject of the study is an exploratory examination of requirements engineering in an international and cross-cultural work environment. In undertaking this study, we have recognized that an important challenge in our study’s methodology, analysis of qualitative interviews, is that the members of the research team live in different countries, rely on different languages and originate from different cultures. Interestingly, we also recognize that these challenges are in many ways analogues to those inherent in the subject we are researching, requirements engineering. To explore these issues, we begin the paper by discussing requirements engineering and the challenges of working across distance, languages and cultures. We then discuss similar challenges for our analyzing the qualitative research data we plan to collect. Next are presented the research method and strategy we are developing to overcome these challenges. 1.

Software development efforts result in the delivery of a software product which satisfies user requirements. Accordingly, the software product must change or evolve. Once in

Incorrect requirement specifications are widely recognized as the major cause of information system failures. In order to improve the correctness of requirement specifications, various requirement specification techniques such as Data Flow Diagram, and Object Model, have been invented to help information analysts capture, understand, and represent information requirements. However, information analysts ’ cognitive abilities are still the most important determinant for the correctness of requirement specifications. Empirical studies have showed that novice information analysts cannot use requirement specification techniques effectively; and hence their performance of specifying information requirements is significantly lower than that of expert information analysts. Self-questioning has long been recognized in the field of learning research as a strategy that can improve students ’ cognitive abilities on reading comprehension and problem solving. In order to improve the cognitive abilities of novice information analysts, this research argued that novice information analysts should be trained to incorporate self-questioning mechanism into their requirement specification process. On the basis of the theories on human cognition, this research also proposed several design strategies for self-asking questions that can guide novice information analysts to make more effective model-based reasoning and hence to achieve a higher correctness of requirement specifications.

This paper divides the software requirements analysis phase into the activities of gathering and recording requirements, more commonly called analysis and specification, concentrating on the development and application of engineering principles and methods to the latter task. It is motivated by the proliferation of standards for writing a software requirements specification document (SRSD) published by various organisations. Our goal is to help other organisations evaluate, select and customise one of these standards and then use it in support of their individual projects and needs. In the following we will see that there is no overall winner in the standards arena, as the needs of organisations working on different projects can, and do, vary. Thus, selection and application of a documentation standard remains a challenging but, as we will also show, important task.

Various organisations have published proposals to prescribe the form and content of software requirements specification documents; the standards were designed to support the specific needs of these organisations and the intricacies of their development projects. To help third parties in taking advantage of this body of work, a set of criteria are proposed and discussed that can be used to evaluate such standards, according to the unique characteristics of specific combinations of organisations and software development projects, and then the question of how the criteria can be applied in an evaluation, selection and tailoring process, depending on the circumstances, is discussed. Finally, the criteria are demonstrated by applying them on some published standards, to help interested organisations to preselect those that seem most appropriate for their needs.