Kotoyna, G., & Sommerville, I. (1998). Requirements Engineering: Processes and Techniques.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....conflicts and defects during their evolution. During requirements analysis, the main goal is detecting conflicts, which will be handled by the requirements negotiation process, and gain a deeper understanding of the requirements. The usual technique for achieving this goal is conceptual modeling [15]. During requirements verification, and paraphrasing Boehm [6] the goal is answering the question Am I building the requirements right . More formally, Pohl [19] defines the goal of requirements verification as checking the requirements according to desired quality properties. Some of these ....

G. Kontoya and I. Sommerville. Requirements Engineering: Processes and Techniques. Wiley, 1997.

....those properties can be specified. A prototypical scenario for an agentmediated system is discussed and some important requirements for this system are specified. 1 Introduction Requirements Engineering is today a well studied field of research within Software Engineering; e.g. 2] 14] [11]. Requirements describe the required properties of a system (this may include the functions of the system, structure of the system, static and dynamic properties) In recent years requirements engineering for distributed and agent systems has been studied in some depth, e.g. in [3] 5] 9] In ....

Kontonya, G., and Sommerville, I. (1998). Requirements Engineering: Processes and Techniques. John Wiley and Sons, New York.

....requirements are part of the initial problem definition, but may also evolve during the development of a system. Requirements Engineering is a well studied field of research. In recent years requirements engineering for distributed and agent systems has been studied, e.g. 19] 20] 21] 25] [33]. At the level of the multi agent system, requirements are related to the dynamics of interaction and co operation patterns. At the level of individual agents, requirements are related to agent behaviour. Due to the dynamic complexity, analysis and specification of such requirements is a difficult ....

Kontonya, G., and Sommerville, I., Requirements Engineering: Processes and Techniques. John Wiley and Sons, New York, 1998.

....and implementation. Requirements Engineering is one of the early but important phases in the software development life cycle and numerous studies have revealed the misidentification of requirements as one of the most significant sources of customer dissatisfaction with delivered systems [10] [22], 28] However, it is a difficult process, as it involves the elicitation, analysis and documentation of knowledge from multiple stakeholders of the system. There is an increased need to involve the users at this stage of the development life cycle [8] 29] It is recognised that the users are ....

Kontonya, G., and Sommerville, I. (1998). Requirements Engineering: Processes and Techniques. John Wiley and Sons, New York.

....concepts given by an organisation model, such as groups, roles within groups, and role interaction. 1. Introduction Requirements Engineering is a well studied field of research. In recent years requirements engineering for distributed and agent systems has been studied, e.g. 1] 2] 5] [7]. The approach introduced in this paper is especially relevant for requirements engineering for distributed and agent systems. At the level of the multiagent system, requirements concern the dynamics of interaction and cooperation patterns. At the level of individual agents, requirements concern ....

Kontonya, G., and Sommerville, I. (1998). Requirements Engineering: Processes and Techniques. John Wiley and Sons, New York.

....to just focus on the programming of these agents, for more sophisticated information agent applications it is essential to design them on a higher conceptual level. A principled design process not only involves conceptual design specifications but also requirements specifications (e.g. 11] [28], 32] and verification e.g. 30] In the first place, in order to develop a system with appropriate properties, such a design process includes the analysis of requirements on the functionality or behaviour of the overall (multi agent) system consisting of the information agents. Moreover, ....

....for this example domain are discussed in section 2. In section 3 design structures are discussed. Verification is the topic of section 4 while section 5 concludes with a brief discussion. 2 Specification of Requirements and Scenarios In Requirements Engineering (cf. 11] 13] 14] 15] 22] [28], 29] 32] the role of scenarios, in addition to requirements, has gained more importance; e.g. see [17] 34] Traditionally, scenarios or use cases are examples of interaction patterns between the users and a system; they are often used during the requirement elicitation, being regarded as ....

Kontonya, G., and Sommerville, I., Requirements Engineering: Processes and Techniques. John Wiley and Sons, New York, 1998.

....they are kept implicit or informal. In principle, the required behavioural properties play a heuristic role: the system design is made up in such a manner that the system behaviour does what is needed, although it is not explicitly specified what that means. Requirements Engineering (cf. 5] [18], 21] addresses the development and validation of methods for eliciting, representing, analysing, and confirming system requirements. Requirements express intended properties of the system, and scenarios specify use cases of the intended system (i.e. examples of intended user interaction ....

Kontonya, G., and Sommerville, I., Requirements Engineering: Processes and Techniques. John Wiley and Sons, New York, 1998.

....and confirming system requirements and with methods for transforming requirements into specifications for design and implementation. A requirements engineering process is characterised as a structured set of activities that are followed to create and maintain a systems requirements document [4] [8], 9] 10] To obtain insight in this process, a description of the activities is needed, the inputs and outputs to from each activity are to described, and tools are needed to support the requirements engineering process. No standard and generally agreed requirements engineering process exists. ....

....[10] To obtain insight in this process, a description of the activities is needed, the inputs and outputs to from each activity are to described, and tools are needed to support the requirements engineering process. No standard and generally agreed requirements engineering process exists. In [8], 10] the following activities are expected to be core activities in the process: Requirements elicitation, through which the requirements are discovered by consulting the stakeholders of the system to be developed. Requirements analysis and negotiation, through which requirements are ....

[Article contains additional citation context not shown here]

Kontonya, G., and Sommerville, I., Requirements Engineering: Processes and Techniques. John Wiley and Sons, New York, 1998.

No context found.

Kotoyna, G., & Sommerville, I. (1998). Requirements Engineering: Processes and Techniques.

No context found.

I. Sommerville, and G. Kotonya, "Requirements Engineering: Processes and Techniques", John Wiley & Sons, Toronto, 1998.

No context found.

Kontonya, G., and Sommerville, I. (1998). Requirements Engineering: Processes and Techniques. John Wiley and Sons, New York.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC