My Professional Bibliography
Index of Contents:
Introduction to Requirements Engineering
1. [NE00] B. A. Nuseibeh and S. M. Easterbrook, "Requirements Engineering: A Roadmap," In A. C. W. Finkelstein (ed) The Future of Software Engineering. (Companion volume to the proceedings of the 22nd International Conference on Software Engineering, ICSE'00). IEEE Computer Society Press.
Keywords: requirements engineering, groundwork, change, validation, stakeholders
Abstract: This paper presents an overview of current research in Requirements Engineering (RE) focussing on the disciplines and background needed to begin effective RE process. Its main contribution is in providing a detailed account of the core activities of RE, namely, eliciting, modeling and analyzing, communicating, agreeing, and evolving requirements. Much importance is given to identifying core requirements in order to develop architectures that are stable in presence of change and can be customized and adapted to changing requirements. The paper focusses on the need for requirement traceability which makes it easy to read, query, navigate and change requirements documentation. The paper also poses a challenge in RE, which is to manage inconsistencies in requirements specifications as they evolve. There is a need to conduct more research in areas such as developing techniques for modeling and analyzing properties of the environment in a formal manner; bridging the gap between the approaches used for requirements elicitation based on contextual enquiry and more formal specification and analysis techniques; developing better models to capture and analyze non-functional requirements; understanding the impacts of a particular architecture on the ability to satisfy current and future requirements; reusing requirements models and providing multidisciplinary training to requirements practitioners so they can interact with technical and non-technical stakeholders
2. [Lam00] A. van Lamsweerde, "Requirements engineering in the year 00: a research perspective", Proceedings, 22nd International Conference on Software Engineering (ICSE'00), Limerick, Ireland, 5-9th June, 2000, pp5-19. IEEE Computer Society Press.
Keywords: requirements engineering, scenario, goals, context, modeling, agent, domain, specifications
Abstract: This paper outlines a brief history of 25 years of research efforts in Requirements Engineering (RE), exploring the main concepts and techniques, particularly with modeling, that have been developed so far to support this field. The main contribution is the positive emphasis laid on goal-oriented requirements engineering. Goals help develop systematic requirements and object models and provide rationale for requirements. However, in situations where they are hard to elicit, scenario based techniques are found useful to elicit and validate requirements. Thus, efforts are being directed to infer goals from scenarios to support more abstract goal based reasoning. Efforts are also made towards defining a framework that is consistent and reliable despite the inconsistencies that arise from multiple stakeholders during requirements elicitation. In order for RE to become a mature discipline, much work is needed to bridge the gap between research in RE and research in software architecture; to explore define-it-yourself approaches to support RE-in-small, where end users are the only stakeholders; to develop techniques for deriving architectural descriptions from requirements specifications and also to determine whether requirements reuse is a practical approach. Requirements reengineering is yet another area that needs investigation so that requirements documents are easier to work with during development and maintenance.
Questions: What is SADT, RML, KAOS and OMT. Additionally I could not understand what 'goal satisficing' meant.
Requirements and Requirements Engineering
1. [ZJ97] P. Zave and M. Jackson. Four Dark Corners of Requirements Engineering. ACM Transactions on Software Engineering and Methodology, 6(1), 1-30. ACM Press, 1997.
Keywords: domain knowledge, implementation bias, refinement of requirements, theory, verification, designation, definition, machine, environment, shared, unshared, environment-controlled, machine-controlled, specification, optative, indicative
Abstract: This paper presents the four dark corners of requirements engineering (RE) and reveals some possible problems and suggests solutions. The paper shows that the terminology used in RE should only relate to the environment; that the focus should not be on describing the machine but the environment with or without the machine; that a distinction needs to be made as to which actions are controlled by the environment and which by the machine; and lastly in order to have refined requirements, it is very important to have domain knowledge, which bridges the gap between requirements and specifications. Domain knowledge is crucial in the RE process but there is uncertainty as to what it is for, which leads to uncertainty as to how much of it to gather. This paper aims to evaluate the current situation of RE and proposes future approaches. It asserts that the use of designations and definitions can bring clarity to requirements and this is essential for its proper working. A large portion of the paper concentrates on explaining why some requirements are not directly implementable and what should be done to handle such requirements and situations. Emphasis is also laid on implementation bias. A model based approach is bound to run into a greater risk of implementation bias. However, using indicative and optative approaches in RE avoid the problem of implementation bias as no statements are made about the proposed machine. The main message this paper delivers is that requirements, specifications and domain knowledge always have the same relationship no matter which application one is developing. It seems to me that adequate research has been done to support the viewpoints of the paper. There were no specific areas I could find where this research could be further extended.
2. [Jac97] M. Jackson. The Meaning of Requirements. Annals of Software Engineering, Vol 3, pp. 5-21, Baltzer Science Publishers, 1997.
Keywords: requirements, environment, machine, functional, specifications, formal, optative, indicative, agent, designation, definition
Abstract: This paper outlines the differences between requirements and specifications and examines ways to formalize requirements so that they become explicit and easy to comprehend. The paper identifies a fundamental problem in requirements engineering (RE), namely, formalization. The consequences of misunderstood requirements can be life threatening in various situations. In order to provide a reliable interpretation of the description of the requirements and to bring formalization to requirements, this paper recommends the use of designation and definition. Designation is the informal explanation, both clear and precise, of the primitive term while definition is only a formal way of representing the same information. The main contribution of this paper is emphasizing the fact that paying careful attention to the meaning of requirement statements can lead to great improvements in RE. Another key thing the paper points out is that requirements are concerned with the environment, where we achieve our goals. The environment further interacts with the machine. However, the machine can affect and be affected by the environment in situations where they share some common event. An important distinction between those environment properties that are given (indicative) and those that much be achieved by the machine (optative) has also been clearly made in the paper. The paper seems adequate to me and I did not discover any more areas where this research could be further extended.
Basic Requirements Elicitation Techniques
1. [AK01] Allenby, K. and Kelly, T. (2001). Deriving Safety Requirements Using Scenarios. Proceedings, Fifth IEEE International Symposium on Requirements Engineering (RE'01), Toronto, Canada, pp. 228-235, 27-31 August 2001.
Keywords: safety, scenarios, use cases, failure identification, analysis, requirements
Abstract: This paper presents an overview of the relationship between safety and core requirements, and discusses the two techniques, FHA and HAZOP, used to identify hazards and to address the problems posed by hazard analysis. The paper also asserts that safety requirements need to be gathered at the start of the requirements elicitation process and that they should be treated as part of the core requirements of the system. The main contribution is the application of a scenario-based requirements approach to develop safety critical systems and identify failures. The FHA technique described in the paper does not consider multiple failure combinations or consistent failures across multiple similar systems. Work is needed to extend this technique to take these factors into consideration. Another feature that would increase the capabilities of this technique is the addition of combinations of use cases which would increase the visibility of the system structure. Although the two techniques to monitor hazard analysis have quite a bit of similarity, combining them to produce an effective technique could lead to better hazard identification.
2. [LRA02] Lloyd, W.J.; Rosson, M.B.; Arthur, J.D. (2002) Effectiveness of elicitation techniques in distributed requirements engineering. Proceedings of the IEEE Joint International Requirements Engineering Conference (RE'02), Essen, Germany, Pages: 311- 318, 9-13 September 2002.
Keywords: elicitation, distributed, requirements engineering, Software Requirement Specification(SRS), negotiation, software, quality, groupware, synchronous
Abstract: This paper outlines an experimental study conducted to assess the effectiveness of various techniques used to gather and refine requirements in a distributed setting. It also studies the effect of using groupware tools like Centra Symposium and MOOsburg on the quality of Software Requirements Specification (SRS) documents. This study was motivated by performance gains shown in previous studies due to the use of a distributed work model. The main contribution is a detailed survey of various factors effecting the quality of SRS documents. However, there is ambiguity in the study as to which factors truly represent the problems encountered in the experiment. Perhaps this experiment could be repeated with a larger group of people or more groups to iron out those factors. With advancements in the field of data communication, in terms of quality and reduced cost, efforts should be directed towards expanding distributed requirements engineering to areas like video conferencing. It is evident from the study that email and other asynchronous techniques do not work well in a distributed setting. But if the engineers and customers are located in different time zones, then this technique may be the norm. Hence research should be conducted to explore this area.
Question: The paper does not look very powerful to me. One of the goals of the paper was to study the effect of requirements elicitation techniques on the quality of SRS documents. However, towards the end of the paper, it says that such a result inconclusive. Is this normal to expect in a research paper?
Modeling Enterprises and Goals
1. [Lam01] A. van Lamsweerde. Goal-oriented requirements engineering: a guided tour. Proceedings, Fifth IEEE International Symposium on Requirements Engineering (RE'01), Toronto, Canada, pp. 249-262, 27-31 August 2001.
Keywords: goal, requirements engineering, agent, assumptions, eliciting, elaborating, structuring, specifying, analyzing, negotiating, documenting, modifying
Abstract:This paper assesses the research efforts undertaken to show how effective goal-oriented requirements engineering (RE) is for eliciting, elaborating, structuring, specifying, analyzing, negotiating, documenting, and modifying requirements. A case study is also discussed in this paper to support this view. The results of the study show that goals make requirements complete, pertinent and easy to read. Goals also provide rationale for requirements and help detect conflicts. It is also worth noting that higher level goals are identified by asking 'why' questions about the system and subgoals and requirements are obtained by asking 'how' questions about the goals already identified. Study has shown that goals along with scenarios lead up to the development of a systematic requirements elaboration process because they complement each other. The main contribution of this paper is the fact that instead of using a simple business application they use a real-time, complex and safety critical system to explain their study. The author's writing style is worth pointing out where he explicitly declares what he includes in the paper and makes an effort to convince the readers about his achievements. Over the last few years several projects used tools to conduct goal-oriented RE. The tool provided a graphical and a syntax-directed editor. Efforts should be made to expand this tool to support animators, model checkers, test data generators and formal verifications features. Work can be directed towards expanding functional and non-functional goals elaborated in RE to be used to refine architectures and to interpret design patterns. There is also need to perform a qualitative reasoning scheme to select an alternative goal refinement technique that best satisfies soft goals related to cost, reliability and performance.
2. [LDM95] A. van Lamsweerde, R. Darimont and P. Massonet. Goal-directed elaboration of requirements for a meeting scheduler: problems and lessons learnt. Proceedings, Second IEEE International Symposium on Requirements Engineering (RE'95), York, UK, pp194-203, 1995.
Keywords: goal, elaboration, requirements, meeting scheduler, domain, constraints, instance, meta, scenario, language, composite system, KAOS
Abstract: This papers evaluates the strengths and weaknesses of KAOS, a modelling language and requirements elaboration technique, which seems to adequately cover various aspects of requirements engineering (RE). In particular, this approach was used to assess requirements acquisition, specifications and evaluation. The paper focusses on the use of a goal-directed strategy where goals are identified; reduced to subgoals; conflicts are identified; informal definitions of goals are refined and finally the goals are formalized. Several problems were encountered in the study while formalizing goals. These were idealized goals, incomplete reduction of goals, conflicting goals, lack of notification when there is a change in goal definition and not knowing when to start formalizing goals. These issues are not specific to any one approach but need to be addressed for a strong goal structure. Additionally, scenarios proved useful to validate goal structure and to find new goals and constraints. The aim of this paper is to combine goal, scenario and viewpoint-directed approaches to produce an adequate, complete and consistent set of requirements. The main contribution of the paper is the choice of a distributed meeting scheduler system to conduct this study because it covered various aspects of RE, namely, functional requirements, real-time performace constraints, privacy concerns, concurrency and distribution aspects, optimization requirements, and non-functional requirements like reliablity, flexibility, changeability and transparency. One of the strengths of this paper is that it clearly indicates its purpose and on failure to achieve its intended goals, the paper points that out to its readers. In RE, certain actions assigned to agents often need to be decomposed further. There is a need to study criteria to decide the level of granularity considered most suitable in such situations. Research could also be done to study interfering objectives, automation alternatives and alternating patterns of communication and cooperation.
Questions: What does KAOS, VDM, ERA stand for ?
3. [AP98] A.I. Antón and C. Potts. The Use of Goals to Surface Requirements for Evolving Systems, International Conference on Software Engineering (ICSE `98), Kyoto, Japan, pp. 157-166, 19-25 April 1998.
Keywords: goals, requirements engineering, evolving, obstacles, scenarios, identifying, analysis, refinement, GBRAM
Abstract: This paper outlines the use of goal-oriented requirement engineering to redesign existing or legacy systems. The identification of high level goals is fundamental to requirements analysis specification process. This can be achieved by asking 'why' questions about the operational descriptions of the system available. Goals are important in the RE process because they bring completeness, pertinence and ease of readability to the requirements. They also provide rationale for requirements and help detect conflicts. Goals are classified according to their target conditions and subject matter. This classification bridges the gap between stakeholders and developers. This paper demonstrates the application of Goal-Based Requirements Analysis Method (GBRAM) to a real commercial project, called CommerceNet. The core techniques of GBRAM, namely, systematic application of heuristics and inquiry questions were used to analyze goals, scenarios and obstacles. The fact that this study was conducted on multiple stakeholders in a distributed setting makes this paper very interesting to read. The use of goal tables to explain the study proved very useful and meaningful to me. There is a need to study the interaction between goals and quantitative non-functional requirements such as performance and reliability.
4. [Yu97] E.S.K. Yu. Towards modelling and reasoning support for early-phase requirements engineering. Proceedings, Third IEEE International Symposium on Requirements Engineering (RE'97), Annapolis, USA, pp 226  235, 1997.
Keywords: modelling, requirements engineering, early-phase, late-phase, analysis, design, why, what, i*
Abstract:This paper presents reasons for having a separate model and support for the early-phase of requirements engineering (RE). Early-phase is a very interactive phase where the stakeholders are the main source of information and decision makers. The paper points out that initial requirements are generally ambiguous, incomplete, informal and inconsistent. In order to understand RE, emphasis should be put on the activities that precede the formulation of initial requirements. Such activities include concerns like 'why' the system is needed instead of ''what' the system should do. The answers to the 'why' questions not only help make a successful system but facilitate cooperation with other systems as well. The main contribution of this paper is the usage of the i* framework to illustrate the need for separate approaches for the early-phase of RE. The two models of i* framework, namely, The Strategic Dependency and The Strategic Rationale are evaluated. This paper emphasizes the importance of assessing how the system embeds itself into the organizational environment to develop a system that truly satisfies the needs of an organization. It seems to me that adequate research has been done to support the viewpoints of the paper. There were no specific areas I could find where this research could be further extended.
Privacy Policy Specification Languages: EPAL, P3P
1. [AHK02] Paul Ashley, Satoshi Hada, Günter Karjoth, Matthias Schunter. E-P3P privacy policies and privacy authorization, Proceeding of the ACM workshop on Privacy in the Electronic Society, November 2002.
2. [BBK04] M. Backes, W. Bagga, G. Karjoth, M. Schunter: Efficient Comparison of Enterprise Privacy Policies, to appear 19th ACM Symposium on Applied Computing, Special Track "Security", Nicosia, Cyprus, March 2004.
3. [PAS02] C. Powers, P. Ashley, and M. Schunter. Privacy promises, access control, and privacy management. enforcing privacy throughout an enterprise by extending access control. In Proceedings of the Third International Symposium on Electronic Commerce, pages 13–21, October 2002.
4. [SHW04] M. Schunter, E. V. Herreweghen, and M. Waidner. Translating epal to p3p - how to keep enterprise privacy promises in sync with the acutal practices. As Of 5-5-2004, http://www.w3.org/2003/p3p-ws/pp/ibm2.html.
5. [Sch03] M. Schunter. Enterprise privacy authorization language (epal 1.1). 2003, http://www.zurich.ibm.com/security/enterpriseprivacy/epal/Specification/index.html.
6. [Pre02] M. Presler-Marshall. The platform for privacy preferences 1.0 deployment guide. February 2002, http://www.w3.org/TR/2002/NOTE-p3pdeployment-20020211.
1. [JBC98] M. Jarke, T.X. Bui and J.M. Carrol. Scenario Management: An Interdisciplinary Approach, Requirements Engineering Journal, 3(4), pp. 155-173, 1998.
Keywords: scenario, goals, human-computer interaction, strategic management, system engineering, interdisciplinary, assumptions
Abstract: This paper aims to provide an interdisciplinary framework for scenario management that considers three major disciplines: strategic management, human-computer interaction, and software and systems engineering. It is, no doubt, very clear that scenarios are considered an essential tool to understand the interactions between various elements in a problem. They promote creativity and draw our attention on specific parts of the problem. From the study conducted, a major conclusion that was drawn was that scenarios are the means of communication among stakeholders. The main contribution of the paper is a comprehensive definition of scenarios which states " A scenario is a description of the world, in a context and for a purpose, focusing on task interaction. It is intended as a means of communication among stakeholders, and to constrain requirements engineering from one or more viewpoints (usually not complete, not consistent, and not formal)." One of the strengths of this paper is that it summarizes its findings in a very explicit manner. Before the study was conducted, there were some important concerns that were raised, namely, systematic capture and generation of scenarios, representational issues of individual scenarios, fitting scenarios to existing methods and scenario management in the large. However, the study helped a great deal in identifying factors promoting and inhibiting the creation of scenarios, benefits and weaknesses of using scenarios in specific development tasks, practical issues in developing scenarios and research constructs for designing and evaluating scenario and scenario management. To complement this paper, research could be conducted to find answers to important questions like how scenarios evolve, how they are related to each other, and how they are related to specifications.
1. [FK92] R.G. Fichman and C.F. Kemerer. Object-oriented and conventional analysis and design methodologies, IEEE Computer, 25(10), 22-39 October 1992.
Keywords: object-oriented, analysis, design, conventional, structured, information engineering
Abstract: This paper presents a comparative study of various methodologies used in object-oriented (OO) design and analysis versus conventional design and analysis methodologies. Object-orientation is based on a strong foundation of modularity, abstraction, encapsulation and reuse. One of the goals of the paper was to assess whether OO methodologies represent a radical or an incremental change over conventional methodologies. The study conducted in the paper concludes that it should be a radical change. The study also shows that complex data types and new forms of integrated systems seem to favor the object model over the conventional approaches. Even though their study did not provide any empirical evidence to support object-orientation, many leading practitioners and academics favor object-orientation as a better method for better software development. Those who can make this transition would definitely be at a more competitive edge. However, according to the study, not a single OO methodology can be recognized as a standard as is the case with conventional methodologies. But OO analysis and design methodologies will continue to evolve. Three areas were recognized where work could be conducted for the development of OO methods. Research could be done to study system partitioning where each component could be developed separately and later integrated. There is also a need for an end-to-end process model. Additionally, harvesting reuse in analysis, design and implementation is an important area to study both for OO methods as well as conventional approaches.
2. [Gli00] M. Glinz. Problems and Deficiencies of UML as a Requirements Specification Language. Proceedings of the 10th International Workshop on Software Specification and Design (IWSSD-10). San Diego, pp. 11-22, 2000.
Keywords: requirements specification, UML, deficiencies, language, model, use case, decomposition, subsytem
Abstract: This paper examines the inadequacies of Unified Modeling Language (UML), as a language for semiformal requirements specifications and evaluates possible solutions to overcome these deficiencies through the use of Teleservices and Remote Medical Care (TRMCS) case study. The intent of this paper is explicit and clear. The paper points out that UML was created to unify the good features of existing languages and hence creating an industry standard. However, there are many deficiencies with it namely, inability to specify an interaction between a system and the external actor, inability to model a rich system context because it forbids associations between actors, inability to express structure between use cases, inability to provide adequate means to deal with use case interaction, inability to accurately model state-dependent system behavior, obscurity in modeling information flow in a system consisting of subsystems, inability to model the behavior of high level system components, inability to decompose the structure of a distributed system like the TRMCS with its elements, and inability to model all aspects of a subsytem in a single view. The main contribution of this paper is the clarity with which the authors recognized the deficiencies of UML. Research can be done to explore alternative modeling languages for requirements specifications and also to find ways to extend UML so it can be used for the aforementioned purpose.
1. [HL96] M.P.E. Heimdahl and N.G. Leveson. Completeness and Consistency in Hierarchical State-Based Requirements, IEEE Transactions on Software Engineering, 22(6), June 1996.
Keywords: completeness, consistency, static analysis, reactive systems, state-based requirements, formal methods, semantics, RSML
Abstract: This paper presents a functional framework to automate the analysis of formal, state-based requirements specifications for completeness (a response is specified for every possible input and input sequence) and consistency (the specification is free from conflicting requirements and undesired nondeterminism). Requirements State Machine Language (RSML) was chosen as the desired framework for this purpose. The key factor which differentiates the approach used in this paper from the ones which have been studied before is the fact that RSML is viewed as a mathematical relation. This approach has many advantages namely, the analysis does not require generation of any part of the global reachability graph because the analysis is directly performed on high-level requirements, it enables incremental analysis of the requirements, it enables identifying parts of the requirements that need reanalysis after changes to the document have been made, and this approach guarantees that no d-incompleteness, inconsistency or nondeterminism will go undetected. The main contribution of this paper is that the feasibility of the analysis has been demonstrated by a real life example of an avionics system (TCAS II). The main strength of the paper is that it states the overall direction and approach the authors want to follow. It is important to devise methods and techniques to eliminate requirements-related errors as early as possible. Thus, the ultimate goal of the authors is to provide analysis tools to find wide variety of flaws in software requirements early in the development and eventually define all such properties in the RSML framework.
2. [GMB94] S. Greenspan, J. Mylopoulos and A. Borgida. On formal requirements modeling languages: RML revisited. Proceedings, 16th International Conference on Software Engineering (ICSE-16), pp135-147, 1994.
Keywords: requirements engineering, RML, modeling languages, specifications, formal
Abstract:This paper presents main ideas and research issues that have driven formal modeling languages, such as Requirements Modeling Language (RML) and Telos, evaluates them based on experience and recent developments and points out future direction for research in this area. The main strength of this paper is that it clearly states the intentions of the paper. The key function of a requirements engineering document is to support communication between various stakeholders. In order to achieve this goal, the paper proposes the use of modeling languages. The main advantage of a formalized modeling language is that it provides a well-defined semantics. One of the modeling languages discussed in this paper is RML, which is object-centered and supports three general kinds of objects such as activities, entities and assertions. However, these objects are built into the system instead of being dynamic. So other languages are also given consideration such as Telos, which is derived from RML but has an ability to extend to new ontologies and domains. The paper also discusses factors which are necessary to be considered while creating a good model. Those factors are the language, a framework reflecting an appropriate ontology for the domain, a methodology for elicitation and acquisition of models, analysis methods that help answer questions and resolve problems and tool support. The main contribution of this paper is the suggestion to include conceptual modeling as part of undergraduate curriculum. Research could be done to explore areas like knowledge respresentation to serve as basis for the design of modeling languages instead of looking into the traditional programming languages for modeling ideas. Efforts can also be directed towards studying a modeling language which is extensible but does not compromise efficiency.
1. [KR97] J. Karlsson and K. Ryan. A Cost-Value Approach for Prioritizing Requirements. IEEE Software, 14(5), pp. 67-74, Sept-Oct 1997.
Keywords: cost-value, stakeholders, requirements, prioritizing
Abstract: This paper outlines an analytical tool for prioritizing requirements. In a real world environment, there are usually more requirements than one can implement with the given constraints on time and resources. In such a situation, it becomes essential to prioritize requirements so that one can make acceptable tradeoffs among conflicting goals such as quality, cost and time-to-market. It also helps to allocate resources based on requirement's importance to the project on a whole. The paper presents a cost-value approach to achieve the above goals. This approach is easy to use, is fast and accurate, and produces trustworthy results. Hence, this approach can easily complement other analytical tools like the Win-Win system. However, the authors do recognize some of the weaknesses in this approach such as, pairwise comparisons are tedious, this approach does not take into account the interdependencies between requirements. Efforts are being directed towards analyzing the above problems and extending the cost-value approach to incorporate these features. The main contribution of the paper is the application of the cost-value approach to two commercial projects. This helps readers understand the approach better as they can see a pattern emerge in the graphs. Both case studies led to a conclusion that by not implementing the requirements that contribute little to stakeholder satisfaction, one can significantly reduce the cost and duration of development. The main strength of the paper is that it is easy to read and produces meaningful results. Besides the efforts that are underway, the paper seems complete in the ideas it presents.
2. [HCS02] J. Cleland-Huang, C.K. Chang, G. Sethi, K. Javvaji, H. Hu and J. Xia. Automating speculative queries through event-based requirements traceability. Proceedings of the IEEE Joint International Requirements Engineering Conference (RE'02), Essen, Germany, pp. 289- 296, 9-13 September 2002.
Keywords: automating, speculative, requirements, EBT, traceability, performance, contextual, functional
Abstract: This paper proposes a method to establish and use traceability links between requirements and performance models. Non-functional performance issues are often ignored until after the implementation. This tendency can have detrimental effects on the quality of the software system. In light of this, the paper assesses the impact of change on the performance requirements of a system prior to the implementation of that change. There are two types of changes that can affect a system. These are contextual changes, in which the quantitative value in the system is altered, and functional changes, in which the behavior of the system is altered. In order to evaluate the impact of change on performance requirements, the paper suggests the use of event-based traceability (EBT) approach. The case studies used in this paper demonstrate that EBT has the ability to correctly identify subscribed performance models, propagate data speculatively into those models, and re-execute them. This paper is hard to comprehend and does not convey a clear message. It seems that the examples used could be elaborated to provide a better understanding of the research involved in the paper. Efforts could be directed towards finding modeling environments where EBT can be applied in a meaningful manner producing some worthwhile results.
1. [Dav92] A. Davis. Operational Prototyping: A New Development Approach, IEEE Software, 9(5), pp. 70-78, September 1992.
Keywords: prototyping, operational, throwaway, evolutionary, requirements, well-understood, poorly-understood, configuration management, quality assurance
Abstract:This paper presents a new approach in development namely, operational prototyping. A prototype is a partial implementation of a system built to learn about a problem or a solution to a problem. Operational prototyping layers a rapid prototype on top of a rigid evolutionary base. Throwaway prototypes work very well in isolation for relatively small and static parts of complex problems, while evolutionary prototypes work well when most critical functions are well understood. Hence, designers only develop well understood requirements in building the evolutionary baseline, while using throwaway prototyping to experiment with the poorly understood requirements. This protects the companies from massive maintenance costs as well as the disaster of an unstable system. There are some management challenges with the use of operational prototyping. These are retaining quality prototypes, fighting the urge to keep throwaways in the field, fighting the urge to use patches in the next version, selecting a language and an architecture, working with widely dispersed personnel, and maintaining customer satisfaction. The main contribution of this paper is that it offers a real case study where it depicts the progress made over the years using various approaches. The main strength of the paper is that the author does not claim that his approach is the best. He says that this approach is better than the ones preceding it but in the years to come there will be better ones than this. It seems to me that adequate research has been done to support the viewpoints of the paper. There were no specific areas I could find where this research could be further extended. The case study used to in this paper helped the authors realize some key points namely, use throwaway prototyping when most requirements are poorly understood, use operational prototyping when requirements are well understood and stable, but there are more to come, consider rewriting the baseline from scratch every two to three years, and hire flexible top performers to serve as prototypers.
2. [ LSZ93] H. Lichter, M. Schneider-Hufschmidt and H. Zullighoven. Prototyping in industrial software projects-bridging the gap between theory and practice. Proceedings, 15th International Conference on Software Engineering (ICSE'93), Baltimore, MD, USA, pp. 221-229, 17-21 May 1993.
Keywords: prototyping, evolutionary, software development, pilot system, horizontal prototyping, vertical prototyping, presentation prototype, case study
Abstract: This paper presents case studies of industrial software projects in which prototyping was explicitly used and identifies factors for success or failure of these projects. The main contribution of this paper is that the analysis is not limited to success stories. Rather it presents the limits and problems of prototyping that will assist future projects in taking full advantage of the benefits of prototyping. The main strength of this paper is that there is sufficient data to back up their study. The paper discusses some valuable lessons learnt during the case studies namely, prototyping should be used where a system's functionality is unclear to a great extent; prototyping does not support the structuring of software development process and hence should only be restricted to the early phase of requirements engineering; it is important to preserve and enhance inputs from all user groups and integrate them in the design and architecture of the system; and in order to have a successful system development, choosing the right kind of prototype, which is a combination of different kinds of prototypes like presentation, breadboard, prototypes proper and pilot systems, is very important. Prototypes encompass the semantics of the application and the architecture of the software. If both of these aspects are modelled in the prototyping process, many problems of system design can be solved. The paper also points out that application domain knowledge is a prerequisite for successful prototyping and it is imperative that users participate throughout the prototyping project. Bringing evolutionary prototyping with object oriented analysis and design is the key to application-oriented software development. The paper seems adequate to me and I did not discover any more areas where this research could be further extended.
1. [AP03] A.I. Antón and C. Potts. Functional Paleontology: The Evolution of User-Visible System Services, IEEE Transactions on Software Engineering, 29(2), pp. 151-166, February 2003.
Keywords: functional paleontology, services, telephone system, measurement, metrics, empirical methods, reverse engineering, requirements engineering, software evolution
Abstract: This paper presents an approach, called functional paleontology, to analyze the evolution of user-visible services irrespective of architecture and design decisions. It supports the viewpoint that in order to understand or predict the future characteristics of a system, it is important to study the evolution of the functions offered by a system over its lifetime. This approach also increases the lifetime of the sotware. It is crucial to understand where a system has been and what technical decisions have been made concerning the system in order for someone to expand the system further. A subscriber telephone system case study has been used to demonstrated this approach. In this case study benefits and burdens were recognized for the services provided by the system. In order to reliably attribute burdens and benefits to services, an objective method was followed which is a three step process and starts by characterizing potential benefits and burdens for a given service; aggregating the benefit and burden counts and finally, over time, deriving variations of separate benefit and burden. The key contribution of this paper is the fact that it emphasizes on functional changes . Since change process propagates down in the software development cycle, it is important to know what kinds of functional changes occur as systems evolve. The strength of the paper is the detail presented in the study. This makes it easier to extend this approach to wireless systems and other telephonic systems with ease. The paper identifies areas where research could be further extended. Researchers are looking for answers to questions like is it possible to relate functional morphology of the system to the software architecture? What are the characteristics of a service, a benefit or a burden? How can we predict the requirements that are most likely to stay stable throughout the lifetime of the system? And finally what system services should be elaborated and fixed first? Efforts should be directed towards finding solutions to these questions.
1. [KSA02] M. Kauppinen, S. Kujala, T. Aaltio and L. Lehtola. Introducing requirements engineering: how to make a cultural change happen in practice, Proceedings of the IEEE Joint International Requirements Engineering Conference (RE'02), Essen, Germany, pp. 43- 51, 9-13 September 2002.
Keywords: requirements engineering, technical view, cultural change, customers, users
Abstract: This paper describes lessons learned from four Finish R&D organizations that have adopted requirements engineering (RE) to their product development. Introducing RE involves a change in behavior and culture in organizations and not just a change in process and technology. The managers and product development engineers believe that they know what the users need and do not understand the need to document requirements systematically. These beliefs pose a challenge in bringing about this cultural change and makes it a rather difficult and risky task. The purpose of this study is to evaluate which factors support such a change and which prevent this cultural change. The main strength of this paper is the clarity with which it displays the challenges and solutions. The four organizations chosen for this case study aim to investigate how they can develop products that better satisfy user and customer needs. The paper make an important distinction between customers and users. Customers are people who pay for the product while users are people who interact directly with the product. The Requirements Engineering Good Practice Guide was chosen to be the basis for the RE process improvement of the four organizations. These organizations did not have a way to define and manage requirements systematically from the customers' and users' point of view. They realized that they need to improve their RE processes and the primary reason for this change was that products are bigger and complex than before and product development is faster leaving less time to correct requirements mistakes in the later phases of the projects. The authors emphasize some important points which support a cultural change in practice. These are linking business goals to techinical requirements via user needs and user requirements, intergrating a simple RE procecss with the product development process, eliciting user needs actively, representing user requirements systematically in the form of use cases, and raising people's awareness of RE. The main contribution of this paper is that it describes the practical problems and solutions that are applicable in the four organizations that were studied. The authors suggest areas for future research namely, investigating how to connect user needs and user requirements more closely to the business process of an organization, analyze how to create traceability between user needs and user and technical requirements, and how to introduce RE at an organization level.
2. [NJW02] J. Nawrocki, M. Jasinski, B. Walter and A. Wojciechowski. Extreme programming modified: embrace requirements engineering practices, Proceedings of the IEEE Joint International Requirements Engineering Conference (RE'02), Essen, Germany, pp. 303-310, 9-13 September 2002.
Keywords: requirements engineering, extreme programming, lightweight
Abstract: This paper assesses the problems that occur in extreme programming (XP) and suggests way to improve this methodology. XP is a lightweight software development methodology which is growing very fast. Although it offers unique features which are different from classical approaches to software development, XP does have its weeknesseses, namely, maintenance problems, dependence on oral communication, assumption that there is only one customer, short planning perspective, and frequent dependence on automated testing. The paper proposes some improvements to make XP a widely accepted approach such as written requirements document that is managed by a tester/analyst, modified planning game that allows to have multiple customer representatives, and introducing a requirements engineering phase at the beginning of each project. The authors consider a possible indicator of improvement to be increase in the number of Sommerville-Sawyer points. After integrating the suggested modifications to XP, the approach would still be lightweight and simple. The main strength of this paper is that it brings out the problems and solutions upfront in a clear manner.