The 3-layer architecture for methods consisting of the generic model, meta-model, and method laye... more The 3-layer architecture for methods consisting of the generic model, meta-model, and method layers is considered and the advantages of introducing the generic layer are brought out. It is argued that this layer helps in method selection, construction of methods in diverse domains and has the potential of rapidly engineering methods. A generic model is introduced and then instantiated from meta-models from the Information Systems and Robotics and Project Planning domains. Thereafter methods are produced by an instantiation of these meta-models. Computer based support for the 3-layer architecture is considered and notion of a generic-CASE tool is introduced.
Notes on numerical fluid mechanics and multidisciplinary design, 1994
It is argued that a methodology provides primitives using which the developer can construct the d... more It is argued that a methodology provides primitives using which the developer can construct the desired process. From the point of view of a process, a methodology is a passive device which only specifies a set of steps and step transition constraints. A step of a methodology can be modelled in terms of the triplet, <situation, decision, action>. A methodology is a collection of such triplets. The decisions-of triplets articulate different kinds of methodology primitives like the creation, deletion, and modification of methodology-specific situations. Under this model, the development process becomes a decision making activity rooted in a methodology. The validation constraints of a methodology constrain this activity by regulating the transition from one decision to another.
Notes on numerical fluid mechanics and multidisciplinary design, 1999
Development methods contain heuristics and constraints that help in producing good quality produc... more Development methods contain heuristics and constraints that help in producing good quality products. Whereas CASE tools enforce method constraints, they rarely support heuristic checking. This paper develops a generic quality model, capable of handling both method constraints and heuristics, which forms the basis of a uniform mechanism for building quality products. The model is metric based, hierarchical in nature, and links metrics to the developmental decisions that are available in a method. The use of this model and the associated quality assessment process is demonstrated through an example of the Yourdon method.
Although procuring Enterprise Resource Planning systems from commercial suppliers is becoming inc... more Although procuring Enterprise Resource Planning systems from commercial suppliers is becoming increasingly popular in our industry, fitting those systems to customer requirements remains problematic. In this paper, we propose an approach for matching ERP system functionality to customer requirements. The assumption made is that the ERP system postulates a set of requirements that are worth eliciting from the ERP documentation as abstractions of the ERP system functionality. Then, the requirements engineering process is a process that matches the ERP set of requirements against organisational ones. Those requirements that match, perhaps after adaptation identify the ERP system features and their adaptations, that must be included in the ERP installation. To facilitate the matching process, the ERP requirements and the organisational ones are both expressed using the same representation system, that of a Map. The paper presents the Map representation system and the matching process. T...
HAL (Le Centre pour la Communication Scientifique Directe), 2001
Conceptual modelling is situated in the broader view of information systems requirements engineer... more Conceptual modelling is situated in the broader view of information systems requirements engineering. Requirements Engineering (RE) explores the objectives of different stakeholders and the activities carried out by them to meet these objectives in order to derive purposeful system requirements and therefore lead to better quality systems i.e. systems that meet the requirements of their users. Thus RE product models use concepts for modelling these instead of concepts like data, process, events etc. used in conceptual models. Since the former are more stable than the latter, requirements engineering manages change better. The paper gives the rationale for extending traditional conceptual models and introduces some RE product models. Furthermore, in contrast to conceptual modelling, requirements engineering lays great stress on the engineering process employed. The paper introduces some RE process models and considers their effect on tool support.
Data Warehouses are decisional information artifacts that are embedded in the organizations that ... more Data Warehouses are decisional information artifacts that are embedded in the organizations that create/maintain them. Therefore, Data Warehouse Requirements Engineering must start from goals and work its way to the decisional information needed to take decisions that fulfils these goals. We propose two associations, the goal-decision association and the decision-information association to represent this. These associations form part of a larger model called the goal decisional information (GDI) model.
We argue that ERP installations are difficult to align to specific requirements of the enterprise... more We argue that ERP installations are difficult to align to specific requirements of the enterprise because of the low level at which ERP functionality is described. We raise this level from a functional description to a goal-oriented one. We use SAP R/3 to illustrate this. A SAP goal expresses the task that a SAP function carries out and abstracts away from the performance of this task. Since a SAP goal can be achieved in many ways, we introduce the notion of SAP strategies. We organise goals and strategies as a directed graph called a map. We illustrate the map with the Materials Management Module of SAP. In order to evaluate and compare the use of the map with the functional approach, we develop an evaluation framework. The evaluation and comparison is presented. The materials management map is then used to align the SAP module to the stores and purchase department of an academic institute.
Lecture Notes in Business Information Processing, 2012
We propose two stages for data warehouse requirements engineering (i) an 'early information' part... more We propose two stages for data warehouse requirements engineering (i) an 'early information' part where the information relevant to decision making is discovered, and (ii) a 'late' part where this information is structured as facts and dimensions. Our focus is on the former. Early information data warehouse requirements engineering starts with targets defined as pairs of the form <A, I> where A is an aspect of an organization and I is a set of business indicators. An aspect is a work area, work unit, service or quality to be preserved in an organization. Business indicators are measures/metrics for specifying the desired performance level of aspects. Targets are organized in a target hierarchy. This hierarchy is a complete specification of what is to be achieved by a top level target. We associate targets with choice sets so that alternative ways of target achievement can be represented. These alternatives form their own hierarchy. Finally, information relevant to selection of each alternative is discovered through Ends, Means, Key Success Factor, and Outcome Feedback analysis techniques. These techniques determine early information that is to be subsequently to be processed in the 'late information' requirements engineering stage. Our early information requirements engineering phase is illustrated through a case study.
Wide usage of model transformation in the Information Systems has resulted in a number of transfo... more Wide usage of model transformation in the Information Systems has resulted in a number of transformation approaches recently. In order to provide an insight into the existing transformation approaches, to draw out the practicability and analyze the strengths and weaknesses of these approaches a multidimensional classification is required. In this paper, a classification framework is proposed which provides a multidimensional, faceted and measure based viewpoint to give a clear and better insight into the existing model transformation approaches.
We focus exclusively on the issue of Requirements engineering for Data Warehouses (DW). Our posit... more We focus exclusively on the issue of Requirements engineering for Data Warehouses (DW). Our position is that the information content of a DW is found in the larger context of the goals of an organization. We refer to this context as the organizational perspective. Goals identify the set of decisions that are relevant which in turn help in determining the information needed to support these. The organizational perspective is converted into the technical perspective, which deals with the set of decisions to be supported and the information required. The latter defines Data warehouse contents. To elicit the technical perspective, we use the notion of an informational scenario. It is a typical interaction between a DW system and the decision maker and consists of a sequence of pairs of the form, \information request, response[. We formulate an information request as a statement in an adapted form of SQL called Specification SQL. The proposals here are implemented in the form of an Informational Scenario Engine that processes informational scenarios and determines Data Warehouse Information Contents.
Admin is a database management system based on the network model of data. It has a number of data... more Admin is a database management system based on the network model of data. It has a number of data definition facilities over and above those provided by the CODASYL DDLC. It is possible to define a schema and build subschemas on top of it. Further, one can build another layer of subschemas on any given subschema, subject to the restriction that a total of 63 subschemas are built on top of any schema. It is also possible to define one's own value sets from which fields of records can take on values. Further, one can build 'new' corecs over currently existing corecs. Similarly, one can also define new cosets between any pair of corec types currently existing in a subschema. There is also an authorization and access control specification available with Admin. All these features are described herein.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this p... more The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. The publisher, the authors and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, express or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Transactional systems have been the forte of Information Systems/Software Engineering. These syst... more Transactional systems have been the forte of Information Systems/Software Engineering. These systems deal with automating the functionality of systems, to provide value to the users. Initially, up to the end of the decade of the 1960s, transactional systems were simple, single-function systems. Thus, we had payroll systems that accounts people would use to compute the salary of employees and print out salary. Information Systems/Software Engineering technology graduated to multi-functional systems that looked at the computerization of relatively larger chunks of the business. Thus, it now became possible to deal with the accounts department, the human resource department, customer interface, etc. Technology to deal with such systems stabilized in the period 1960-1980. Subsequently, attention shifted to even more complex systems, the computerization of the entire enterprise, and to inter-organization information systems. The demand for engineering of ever more complex systems led to the "software crisis", a term widely used in the 1990s to describe the difficulties that industry of that time faced. A number of studies were carried out and some of the problems highlighted were systems failure/rejection by clients, inability to deliver complex and large software well. The Standish Group's "Chaos" reports [1] presented software industry's record in delivering large-sized systems using traditional development methods. The Group conducted a survey of 8380 projects carried out by 365 major American companies. The results showed that projects worth up to even $750,000 exceeded budget and time. Further, they failed to deliver the promised features more than 55% of the time. As the size of the applications grew, the success rate fell to 25% for efforts over $3 million and down to zero for projects over $10 million. Bell labs and IBM [2] found that 80% of all defects in software products lie in the requirements phase. Boehm and Papaccio [3] said that correcting requirements errors is 5 times more expensive when carried out during the design phase; the cost of correction is 10 times during implementation phase; the cost rises to 20 times for corrections done during testing and it becomes an astronomical 200 times after the system has been delivered. Evidently, such corrections result in expensive products
To reduce the gap between the business-oriented view of business rules of business people and the... more To reduce the gap between the business-oriented view of business rules of business people and the technical orientation of technical people, we introduce a Business layer on top of the CIM layer of MDA. This facilitates an investigation into the features of business-oriented business rules. We underpin our work with a four dimensional framework of business rules consisting of the domain, system, representation, and application dimensions. Since our focus is on features of business rules, our interest is the domain dimension. This dimension provides a number of attributes of business rules but we concentrate on the governance/guidance attribute to develop the features needed for capturing this attribute in business rules. We express governance concepts in three levels. The Governance model is the top most level and consists of governance objects, governance criteria, and the governance relationship between these. We obtain BIGm by instantiating the Governance model based on concepts ...
In this chapter, we consider the three issues that emerge from the previous chapter, namely, 1. T... more In this chapter, we consider the three issues that emerge from the previous chapter, namely, 1. The need for a central notion that forms the focus of data warehouse requirements engineering. Just as the notion of a function is central to transactional requirements engineering, we propose the concept of a decision as the main concept for data warehouse requirements engineering. 2. The development of information elicitation techniques. The absence of systematic information elicitation makes the data warehouse requirements engineering process largely ad-hoc. We propose to systemize these techniques. 3. The tension between rapid DW fragment development and consolidation. This tension arises because consolidation is treated as a project in itself separate from the DW fragment development process. We propose to integrate it with the requirements engineering process of the data warehouse development life cycle. Since a data warehouse system is used to provide support for decision-making, our premise is that any model that is developed must be rooted in the essential nature of decision-making. Therefore, in this section, we first consider the notion of a decision process. Thereafter, we consider the role of data warehousing in decision-making and highlight the importance of basing data warehouse requirements engineering on the notion of a decision.
2017 11th International Conference on Research Challenges in Information Science (RCIS), 2017
Data Warehouses are decisional information artifacts that are embedded in the organizations that ... more Data Warehouses are decisional information artifacts that are embedded in the organizations that create/maintain them. Therefore, Data Warehouse Requirements Engineering must start from goals and work its way to the decisional information needed to take decisions that fulfils these goals. We propose two associations, the goal-decision association and the decision-information association to represent this. These associations form part of a larger model called the goal decisional information (GDI) model.
Conceptual modelling is situated in the broader view of information systems requirements engineer... more Conceptual modelling is situated in the broader view of information systems requirements engineering. Requirements Engineering (RE) explores the objectives of different stakeholders and the activities carried out by them to meet these objectives in order to derive purposeful system requirements and therefore lead to better quality systems i.e. systems that meet the requirements of their users. Thus RE product models use concepts for modelling these instead of concepts like data, process, events etc. used in conceptual models. Since the former are more stable than the latter, requirements engineering manages change better. The paper gives the rationale for extending traditional conceptual models and introduce some RE product models. Furthermore, in contrast to conceptual modelling, requirements engineering lays great stress on the engineering process employed. The paper introduces some RE process models and considers their effect on tool support. 1. Introduction A number of studies s...
The 3-layer architecture for methods consisting of the generic model, meta-model, and method laye... more The 3-layer architecture for methods consisting of the generic model, meta-model, and method layers is considered and the advantages of introducing the generic layer are brought out. It is argued that this layer helps in method selection, construction of methods in diverse domains and has the potential of rapidly engineering methods. A generic model is introduced and then instantiated from meta-models from the Information Systems and Robotics and Project Planning domains. Thereafter methods are produced by an instantiation of these meta-models. Computer based support for the 3-layer architecture is considered and notion of a generic-CASE tool is introduced.
Notes on numerical fluid mechanics and multidisciplinary design, 1994
It is argued that a methodology provides primitives using which the developer can construct the d... more It is argued that a methodology provides primitives using which the developer can construct the desired process. From the point of view of a process, a methodology is a passive device which only specifies a set of steps and step transition constraints. A step of a methodology can be modelled in terms of the triplet, <situation, decision, action>. A methodology is a collection of such triplets. The decisions-of triplets articulate different kinds of methodology primitives like the creation, deletion, and modification of methodology-specific situations. Under this model, the development process becomes a decision making activity rooted in a methodology. The validation constraints of a methodology constrain this activity by regulating the transition from one decision to another.
Notes on numerical fluid mechanics and multidisciplinary design, 1999
Development methods contain heuristics and constraints that help in producing good quality produc... more Development methods contain heuristics and constraints that help in producing good quality products. Whereas CASE tools enforce method constraints, they rarely support heuristic checking. This paper develops a generic quality model, capable of handling both method constraints and heuristics, which forms the basis of a uniform mechanism for building quality products. The model is metric based, hierarchical in nature, and links metrics to the developmental decisions that are available in a method. The use of this model and the associated quality assessment process is demonstrated through an example of the Yourdon method.
Although procuring Enterprise Resource Planning systems from commercial suppliers is becoming inc... more Although procuring Enterprise Resource Planning systems from commercial suppliers is becoming increasingly popular in our industry, fitting those systems to customer requirements remains problematic. In this paper, we propose an approach for matching ERP system functionality to customer requirements. The assumption made is that the ERP system postulates a set of requirements that are worth eliciting from the ERP documentation as abstractions of the ERP system functionality. Then, the requirements engineering process is a process that matches the ERP set of requirements against organisational ones. Those requirements that match, perhaps after adaptation identify the ERP system features and their adaptations, that must be included in the ERP installation. To facilitate the matching process, the ERP requirements and the organisational ones are both expressed using the same representation system, that of a Map. The paper presents the Map representation system and the matching process. T...
HAL (Le Centre pour la Communication Scientifique Directe), 2001
Conceptual modelling is situated in the broader view of information systems requirements engineer... more Conceptual modelling is situated in the broader view of information systems requirements engineering. Requirements Engineering (RE) explores the objectives of different stakeholders and the activities carried out by them to meet these objectives in order to derive purposeful system requirements and therefore lead to better quality systems i.e. systems that meet the requirements of their users. Thus RE product models use concepts for modelling these instead of concepts like data, process, events etc. used in conceptual models. Since the former are more stable than the latter, requirements engineering manages change better. The paper gives the rationale for extending traditional conceptual models and introduces some RE product models. Furthermore, in contrast to conceptual modelling, requirements engineering lays great stress on the engineering process employed. The paper introduces some RE process models and considers their effect on tool support.
Data Warehouses are decisional information artifacts that are embedded in the organizations that ... more Data Warehouses are decisional information artifacts that are embedded in the organizations that create/maintain them. Therefore, Data Warehouse Requirements Engineering must start from goals and work its way to the decisional information needed to take decisions that fulfils these goals. We propose two associations, the goal-decision association and the decision-information association to represent this. These associations form part of a larger model called the goal decisional information (GDI) model.
We argue that ERP installations are difficult to align to specific requirements of the enterprise... more We argue that ERP installations are difficult to align to specific requirements of the enterprise because of the low level at which ERP functionality is described. We raise this level from a functional description to a goal-oriented one. We use SAP R/3 to illustrate this. A SAP goal expresses the task that a SAP function carries out and abstracts away from the performance of this task. Since a SAP goal can be achieved in many ways, we introduce the notion of SAP strategies. We organise goals and strategies as a directed graph called a map. We illustrate the map with the Materials Management Module of SAP. In order to evaluate and compare the use of the map with the functional approach, we develop an evaluation framework. The evaluation and comparison is presented. The materials management map is then used to align the SAP module to the stores and purchase department of an academic institute.
Lecture Notes in Business Information Processing, 2012
We propose two stages for data warehouse requirements engineering (i) an 'early information' part... more We propose two stages for data warehouse requirements engineering (i) an 'early information' part where the information relevant to decision making is discovered, and (ii) a 'late' part where this information is structured as facts and dimensions. Our focus is on the former. Early information data warehouse requirements engineering starts with targets defined as pairs of the form <A, I> where A is an aspect of an organization and I is a set of business indicators. An aspect is a work area, work unit, service or quality to be preserved in an organization. Business indicators are measures/metrics for specifying the desired performance level of aspects. Targets are organized in a target hierarchy. This hierarchy is a complete specification of what is to be achieved by a top level target. We associate targets with choice sets so that alternative ways of target achievement can be represented. These alternatives form their own hierarchy. Finally, information relevant to selection of each alternative is discovered through Ends, Means, Key Success Factor, and Outcome Feedback analysis techniques. These techniques determine early information that is to be subsequently to be processed in the 'late information' requirements engineering stage. Our early information requirements engineering phase is illustrated through a case study.
Wide usage of model transformation in the Information Systems has resulted in a number of transfo... more Wide usage of model transformation in the Information Systems has resulted in a number of transformation approaches recently. In order to provide an insight into the existing transformation approaches, to draw out the practicability and analyze the strengths and weaknesses of these approaches a multidimensional classification is required. In this paper, a classification framework is proposed which provides a multidimensional, faceted and measure based viewpoint to give a clear and better insight into the existing model transformation approaches.
We focus exclusively on the issue of Requirements engineering for Data Warehouses (DW). Our posit... more We focus exclusively on the issue of Requirements engineering for Data Warehouses (DW). Our position is that the information content of a DW is found in the larger context of the goals of an organization. We refer to this context as the organizational perspective. Goals identify the set of decisions that are relevant which in turn help in determining the information needed to support these. The organizational perspective is converted into the technical perspective, which deals with the set of decisions to be supported and the information required. The latter defines Data warehouse contents. To elicit the technical perspective, we use the notion of an informational scenario. It is a typical interaction between a DW system and the decision maker and consists of a sequence of pairs of the form, \information request, response[. We formulate an information request as a statement in an adapted form of SQL called Specification SQL. The proposals here are implemented in the form of an Informational Scenario Engine that processes informational scenarios and determines Data Warehouse Information Contents.
Admin is a database management system based on the network model of data. It has a number of data... more Admin is a database management system based on the network model of data. It has a number of data definition facilities over and above those provided by the CODASYL DDLC. It is possible to define a schema and build subschemas on top of it. Further, one can build another layer of subschemas on any given subschema, subject to the restriction that a total of 63 subschemas are built on top of any schema. It is also possible to define one's own value sets from which fields of records can take on values. Further, one can build 'new' corecs over currently existing corecs. Similarly, one can also define new cosets between any pair of corec types currently existing in a subschema. There is also an authorization and access control specification available with Admin. All these features are described herein.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this p... more The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. The publisher, the authors and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, express or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Transactional systems have been the forte of Information Systems/Software Engineering. These syst... more Transactional systems have been the forte of Information Systems/Software Engineering. These systems deal with automating the functionality of systems, to provide value to the users. Initially, up to the end of the decade of the 1960s, transactional systems were simple, single-function systems. Thus, we had payroll systems that accounts people would use to compute the salary of employees and print out salary. Information Systems/Software Engineering technology graduated to multi-functional systems that looked at the computerization of relatively larger chunks of the business. Thus, it now became possible to deal with the accounts department, the human resource department, customer interface, etc. Technology to deal with such systems stabilized in the period 1960-1980. Subsequently, attention shifted to even more complex systems, the computerization of the entire enterprise, and to inter-organization information systems. The demand for engineering of ever more complex systems led to the "software crisis", a term widely used in the 1990s to describe the difficulties that industry of that time faced. A number of studies were carried out and some of the problems highlighted were systems failure/rejection by clients, inability to deliver complex and large software well. The Standish Group's "Chaos" reports [1] presented software industry's record in delivering large-sized systems using traditional development methods. The Group conducted a survey of 8380 projects carried out by 365 major American companies. The results showed that projects worth up to even $750,000 exceeded budget and time. Further, they failed to deliver the promised features more than 55% of the time. As the size of the applications grew, the success rate fell to 25% for efforts over $3 million and down to zero for projects over $10 million. Bell labs and IBM [2] found that 80% of all defects in software products lie in the requirements phase. Boehm and Papaccio [3] said that correcting requirements errors is 5 times more expensive when carried out during the design phase; the cost of correction is 10 times during implementation phase; the cost rises to 20 times for corrections done during testing and it becomes an astronomical 200 times after the system has been delivered. Evidently, such corrections result in expensive products
To reduce the gap between the business-oriented view of business rules of business people and the... more To reduce the gap between the business-oriented view of business rules of business people and the technical orientation of technical people, we introduce a Business layer on top of the CIM layer of MDA. This facilitates an investigation into the features of business-oriented business rules. We underpin our work with a four dimensional framework of business rules consisting of the domain, system, representation, and application dimensions. Since our focus is on features of business rules, our interest is the domain dimension. This dimension provides a number of attributes of business rules but we concentrate on the governance/guidance attribute to develop the features needed for capturing this attribute in business rules. We express governance concepts in three levels. The Governance model is the top most level and consists of governance objects, governance criteria, and the governance relationship between these. We obtain BIGm by instantiating the Governance model based on concepts ...
In this chapter, we consider the three issues that emerge from the previous chapter, namely, 1. T... more In this chapter, we consider the three issues that emerge from the previous chapter, namely, 1. The need for a central notion that forms the focus of data warehouse requirements engineering. Just as the notion of a function is central to transactional requirements engineering, we propose the concept of a decision as the main concept for data warehouse requirements engineering. 2. The development of information elicitation techniques. The absence of systematic information elicitation makes the data warehouse requirements engineering process largely ad-hoc. We propose to systemize these techniques. 3. The tension between rapid DW fragment development and consolidation. This tension arises because consolidation is treated as a project in itself separate from the DW fragment development process. We propose to integrate it with the requirements engineering process of the data warehouse development life cycle. Since a data warehouse system is used to provide support for decision-making, our premise is that any model that is developed must be rooted in the essential nature of decision-making. Therefore, in this section, we first consider the notion of a decision process. Thereafter, we consider the role of data warehousing in decision-making and highlight the importance of basing data warehouse requirements engineering on the notion of a decision.
2017 11th International Conference on Research Challenges in Information Science (RCIS), 2017
Data Warehouses are decisional information artifacts that are embedded in the organizations that ... more Data Warehouses are decisional information artifacts that are embedded in the organizations that create/maintain them. Therefore, Data Warehouse Requirements Engineering must start from goals and work its way to the decisional information needed to take decisions that fulfils these goals. We propose two associations, the goal-decision association and the decision-information association to represent this. These associations form part of a larger model called the goal decisional information (GDI) model.
Conceptual modelling is situated in the broader view of information systems requirements engineer... more Conceptual modelling is situated in the broader view of information systems requirements engineering. Requirements Engineering (RE) explores the objectives of different stakeholders and the activities carried out by them to meet these objectives in order to derive purposeful system requirements and therefore lead to better quality systems i.e. systems that meet the requirements of their users. Thus RE product models use concepts for modelling these instead of concepts like data, process, events etc. used in conceptual models. Since the former are more stable than the latter, requirements engineering manages change better. The paper gives the rationale for extending traditional conceptual models and introduce some RE product models. Furthermore, in contrast to conceptual modelling, requirements engineering lays great stress on the engineering process employed. The paper introduces some RE process models and considers their effect on tool support. 1. Introduction A number of studies s...
Uploads
Papers by Naveen Prakash