this article details the five main steps that comprise goal-oriented analysis. These steps include goal analysis, softgoal analysis, softgoal correlation analysis, goal correlation analysis, and evaluation of alter- focus

The objective of this work is to develop, validate and assess a goal-based method, which provides procedural support, for the identification, elaboration, refinement, and organization of goals in the specification of software-based information systems. The two main contributions of this work to current goal-refinement requirements methods are: • The extension of current goal-based methods with the provision of strategies for the initial identification and construction of goals. • Provision of a set of guidelines and recurring question types which suggest goal identification and refinement strategies and techniques. Existing goal-based methods stress the need to characterize, categorize, decompose and structure goals. However, they fail to offer strategies for the initial identification and construction of goals. It is assumed that the goals already exist in some artifact. However, if goals have not been previously specified, how does one go about specifying them, and how does one know when all of the goals have been completely specified? Strategies are needed to resolve these issues. Our research has enabled us to develop a method which offers a straightforward, methodical approach to identifying system (and enterprise) goals and requirements. It suggests goal identification and refinement strategies and techniques by including a set of guidelines and recurring questions types. Use of this method will produce a software specification of the functional requirements in the form of goal schemas showing behaviors in terms of goals, their relationships, constraints, and obstacles, as well as agent responsibilities.

A requirements specification defines the requirements for the future system at a conceptual level (i.e. class or type level). In contrast, a scenario represents a concrete example of current or future system usage. In early RE phases, scenarios are used to support the definition of high level requirements (goals) to be achieved by the new system. In many cases, those goals can to a large degree be elicited by observing, documenting and analysing scenarios about current system usage, i.e. the new system must often fulfil many of the functional and non-functional goals of the existing system. To support the elicitation and validation of the goals achieved by the existing system and to illustrate problems of the old system we propose to capture current system usage using rich media (e.g. video, speech, pictures etc.) and to interrelate those observations with the goal definitions. Thus, we particularly aim at making the abstraction process which leads to the definition of the conceptual models more transparent and traceable. More precisely, we relate the parts of the observations which have caused the definition of a goal or against which a goal was validated with the corresponding goal. These interrelations provide the basis for

Early requirements analysis is concerned with modeling and understanding the organizational context within which a software system will operate. Such organizational models can describe either the status quo or a desired new status. It is convenient to build such models by deploying organizational patterns which describe oftenused organizational structures. The paper proposes a catalogue of patterns which adopt concepts from organization theory and strategic alliances literature. The patterns are modeled using the i * framework which offers the notions of actor, goal and actor dependency and specified in Telos. Each proposed pattern is evaluated with respect to a set of quality attributes, such as predictability, adaptability and openness. We illustrate the use of our proposed patterns with a business-tobusiness example modeling alternative organizational settings. This research has been conducted within the context of a comprehensive software development methodology called Tropos. 1.

While the Internet is dramatically changing the way business is conducted, security and privacy issues are of deeper concern than ever before. A primary fault in evolutionary electronic commerce systems is the failure to adequately address security and privacy issues; therefore, security and privacy policies are either developed as an afterthought to the system or not at all. One reason for this failure is the difficulty in applying traditional software requirements engineering techniques to systems in which policy is continually changing due to the need to respond to the rapid introduction of new technologies which compromise those policies. Security and privacy should be major concerns from the onset, but practitioners need new systematic mechanisms for determining and assessing security and privacy. To provide this support, we employ scenario management and goal-driven analysis strategies to facilitate the design and evolution of electronic commerce systems. Risk and impact assessme...

Use cases have proven helpful for eliciting, communicating and documenting requirements. But whereas functional requirements are well supported, use cases provide less support for working with extra-functional requirements, such as security requirements. With the advent of e-commerce applications, security and other extra-functional requirements are growing in importance. In an earlier paper, the authors have introduced the concept of misuse cases -- inverted use cases to denote functions that should not be possible to perform in a system. In this paper, security related misuse cases are elaborated in further detail through a discussion of templates for their textual description.

This paper presents an approach that uses special purpose RBAC constraints to base certain access control decisions on context information. In our approach a context constraint is defined as a dynamic RBAC constraint that checks the actual values of one or more contextual attributes for predefined conditions. If these conditions are satisfied, the corresponding access request can be permitted. Accordingly, a conditional permission is an RBAC permission which is constrained by one or more context constraints. We present an engineering process for context constraints, that is based on goal-oriented requirements engineering techniques, and describe how we extended the design and implementation of an existing RBAC service to enable the enforcement of context constraints. With our approach we aim to preserve the advantages of RBAC, and o#er an additional means for the definition and enforcement of fine-grained context-dependent access control policies.

It has long been accepted that requirements analysis should precede architectural design and implementation, but in software evolution and reverse engineering this concern with black-box analysis of function has necessarily been de-emphasized in favor of code-based analysis and designer-oriented interpretation. In this paper, we redress this balance by describing "functional paleontology", an approach to analyzing the evolution of user-visible features or services independent of architecture and design intent. We classify the benefits and burdens of interpersonal communication services into core and peripheral categories and investigate the telephony services available to domestic subscribers over a fifty-year period. We report that services were introduced in discrete bursts, each of which emphasized different benefits and burdens. We discuss the general patterns of functional evolution that this "fossil record" illustrates and conclude by discussing their implications for forward engineering of software products.

Systems requirements errors are numerous, persistent, and expensive. To detect such errors during the development of a requirements document, we have defined Root Requirements Analysis. This technique is simple in that it is based on: generalizing requirements to form root requirements, exhaustively comparing the root requirements, and applying simple metrics to the resultant comparison matrix. Root Requirements Analysis is also effective. In the case study described in this article, the technique finds that 36 percent of the case’s root requirements interactions result in problems which require further analysis. Moreover, the technique provides a specific, operational procedure to guide the efficient iterative resolution of identified requirements conflicts. The process of Root Requirements Analysis itself is not specific to a particular methodology. It can be applied directly to requirements in a variety of forms, as well as to the documentation of requirements development. We took this later approach in the case study illustrating how Root Requirements Analysis can augment the Inquiry Cycle model of requirements development. Finally, the technique is amenable to support through collaborative CASE tools, as we demonstrate with out DEALSCRIBE prototype. Index Terms—Requirements engineering, goal/assumption surfacing, stakeholder analysis, conflict management, meta-modeling, requirements Inquiry Cycle Model, scenario analysis

Abstract—Information practices that use personal, financial, and health-related information are governed by US laws and regulations to prevent unauthorized use and disclosure. To ensure compliance under the law, the security and privacy requirements of relevant software systems must properly be aligned with these regulations. However, these regulations describe stakeholder rules, called rights and obligations, in complex and sometimes ambiguous legal language. These “rules ” are often precursors to software requirements that must undergo considerable refinement and analysis before they become implementable. To support the software engineering effort to derive security requirements from regulations, we present a methodology for directly extracting access rights and obligations from regulation texts. The methodology provides statement-level coverage for an entire regulatory document to consistently identify and infer six types of data access constraints, handle complex cross references, resolve ambiguities, and assign required priorities between access rights and obligations to avoid unlawful information disclosures. We present results from applying this methodology to the entire regulation text of the US Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule. Index Terms—Data security and privacy, laws and regulations, compliance, accountability, requirements engineering.