[AA01] T. Alspaugh, A.I. Antón. "Scenario Networks: A Case Study of the Enhanced Messaging System." Seventh International Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ), Interlaken, Switzerland, 5-6 June 2001.

• Abstract: System behavior is specified by scenarios. An enhanced voice messaging system was discussed in this paper using scenario networks. Scenario networks connect scenarios sequentially, therefore, eliminating omissions and errors. Pre- and post-conditions are assigned to each scenario to rule out undesired sequences.
  

• Notes: A case study of scenario networks: EMS.
  Scenario Networks - a set of scenarios and the connections from each scenario to those that may follow it
  Initial scenario - a scenario that may begin a scenario sequence
  Terminal scenario - a scenario that may end a scenario sequence
  Stub branch - a scenario in a scenario network that is not reachable, but is not an initial scenario; or a scenario that is not leavable, but is not a terminal scenario
  

[AAB99] T. Alspaugh, A.I. Antón, T. Barnes, and B. Mott. "An Integrated Scenario Management Strategy." IEEE Fourth International Symposium on Requirements Engineering (RE`99), University of Limerick, Ireland, pp. 142-149, 7-11 June 1999.

• Abstract: This paper proposes an integrated strategy for scenario management that formalizes similar scenario structures and attributes to guide and facilitate the requirements analysis process. A powerful goal-based scenario management tool is formalized in combination with Goal-Based Requirements Analysis Method (GBRAM). This tool includes strategies for glossary creation, episode management, similarity measures, and coverage analysis.
  

• Notes: Formalization of a powerful goal-based scenario management tool (later to be called SMaRT).
  Event - consists of an actor and an action
  Subsequence - a sequence of one or more events that forms all or part of a scenario's sequence
  Episode - a named subsequence that is usually shared among several scenarios
  Attributes - system goals, viewpoint, pre- and post-conditions, purpose, concreteness level, author, requirements, events, actors and actions, and episodes of a scenario
  

[ACD01] A.I. Antón, R. Carter, A. Dagnino, J. Dempster, D. Siege. "Deriving Goals from a Use-Case Based Requirements Specification." Requirements Engineering Journal, Springer-Verlag, Volume 6, pp. 63-73, May 2001.

• Abstract: This paper identifies the specific risks incurred, focusing more on the challenges imposed due to traceability, inconsistent use of terminology, imcompleteness and consistency, rather than on traditional software project management risks during a goal-driven requirements analysis effort for an electronic commerce application. Various lessons learned were outlined at the end of the paper in the context of building quality systems during goal and scenario analysis.
  

• Notes: Specification of risks and learned lessons pertaining to requirements engineering.
  Authors - refers to the six individuals who authored the Software Requirements Specification (SRS)
  Analysts - refers to those who actively participated in this case study
  Stakeholders - the authors of the SRS as well as a number of intended users of the electronic commerce and quotation system
  Traceability - the measure of quality that reduces the risk of, for example, not propagating changes across life cycle artifacts
  

[AE01a] A.I. Antón and J.B. Earp. "Strategies for Developing Policies and Requirements for Secure Electronic Commerce Systems." Accepted to the 1st ACM Workshop on Security and Privacy in E-Commerce (CCS 2000), Athens, Greece, 1-4 November 2000.

• Abstract: Electronic commerce systems fail to address security and privacy issues adequately and often these policies are adopted haphazardly or not at all. Instead, the goal should be to tailor security and privacy policies to an organization's risks that change as technology evolves. To do this, an organization must use a scenario management and goal-driven analysis strategies in the requirements phase. Through this method, organizations will adopt security and privacy policies that are adequate in scope for the organization's electronic commerce system.
  

• Notes: This is a tool to help organizations develop policy goals and follow them.
  Goals - the objectives and targets of achievement for a system
  Scenarios - descriptions of concrete system behaviors
  

[AE01b] A.I. Antón, J.B. Earp. "A Taxonomy for Web Site Privacy Requirements." NCSU Technical Report TR-2001-14, 18 December 2001.

• Abstract: This paper gave a brief history of privacy in order to background the work done. This is followed by five categories of Fair Information Practice Principles in which protection goals may be subdivided. A method for goal-mining is then introduced which includes heuristics for identifying, classifying, and refining the goals.
  

• Notes: An in-depth description of developing privacy requirements using goal-mining.
  

[AEC02] Annie I. AntŪn, Julia B. Earp and Ryan A. Carter. "Aligning Software Requirements with Security and Privacy Policies." Submitted to: International Workshop on Requirements Engineering for Software Quality (REFSQ 2002), Essen, Germany, 18 April 2002.

• Abstract: This paper analyzed three case studies in which the EPRAM model was employed to evaluate its effectiveness in ensuring adherence of system requirements to the security and privacy policies. Various conflict relationships were encountered in the requirements specification, security policy, and privacy policy. These case studies pointed out the need for companies to carefully develop the three previous documents and eliminate conflict between them.
  

• Notes: Three case studies were examined for conflict between the requirements specification document, the security policy, and the privacy policy. The following conflicts were the classifications used.
  Terminology - Complete clash between terminology used within documentation
  Ambiguity - Differences between terminology used within documentation in which there is a need to qualify or further refine some term
  Incomplete Ambiguity - A specialized form of ambiguity that results from terms being left out of the documentation
  Potential - There exists even the slightest possibility for a conflict to occur, as the statements are open to misinterpretation
  Definite - A conflict will occur if the requirements and policies are implemented as written
  

[AEP02] A.I. AntŪn, J.B. Earp, C. Potts. "A Conceptual Framework for Privacy Policy and Stakeholder Privacy Values." Currently being reviewed by the Requirements Engineering Journal (REJ).

• Abstract: Tools and techniques to help requirements engineers and IT policy makers bring policies and system requirements into better alignment were discussed in this paper. It stresses a need for software engineers to have methods and tools to enable them to design systems that reflect values held to protecting a person's personal information. Image schemes for privacy concepts were introduced.
  

• Notes: An in-depth analysis was made into how privacy and security polices could be created.
  Privacy - the interrest individuals have in sustaining personal space free from interference by other people and organizations
  Privacy Policy - a comprehensive description of a Web site's practices that is located on the site itself and may be easily accessed by visitors
  

[AER01] A.I. Antón, J.B. Earp, A. Reese. "Analyzing Web Site Privacy Requirements Using a Privacy Goal Taxonomy." Accepted to the 10th Anniversary IEEE Joint Requirements Engineering Conference (RE '02).

• Abstract: Privacy-related goals, especially as they pertain to health care web sites, are best derived using a technique called goal-mining. The motivation for seeking out privacy-related goals is two fold: (1) seeking to develop a corpus of reusable privacy and security goals for e-commerce software developers and (2) these goals are a cogent unit by which to objectively analyze and compare Internet privacy policies, enabling the useful guidance to requirements engineering practitioners, policy makers, and consumers. These goals are then classified using a specified taxonomy. Through the work of the researchers, a library of reusable security and privacy goals is well on its way to creation.
  

• Notes: This paper introduces the technique of goal-mining and a taxonomy for classifying privacy goals.
  Goal-mining - the extraction of pre-requirements goals from post-requirements text artifacts, as a technique for analyzing privacy policies
  Requirements Engineering - the principled application of proven methods and tools to describe the behavior and constraints of a proposed system

[Ant96] A.I. Antón. "Goal-Based Requirements Analysis." Int. Cof. on Requirements Engineering (ICRE '6), Colorado Springs, CO, USA, pp. 136-144, Apr. 1996.

• Abstract: This paper stresses that goals must be used to identify, organize, and justify software requirements. Goals are discussed from the perspective of two themes: goal analysis and goal evolution. A series of lessons were learned by applying the goal-based approach to analyze the goals for a Career Track Training System for an Air Force Base.
  

• Notes: A case study using goal analysis and goal evolution.
  Goal-analysis - the exploration of documentation (for goal identification) followed by the organization and classification of goals
  Goal Evolution - concerns the way goals change from the moment they are first identified to the moment they are operationalized in a system specification

[AP98a] A.I. Antón, 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.

• Abstract: This paper addresses the use of goals to surface requirements for the redesign of existing or legacy systems. A summary of a goal-based method, GBRAM, is addressed and used to uncover hidden issues, goals, and requirements as well as illustrate its application to a commercial system, an Intranet-based electronic commerce application. The core techniques in GBRAM are the systematic application of heuristics and inquiry questions for the analysis of goals, scenarios, and obstacles.
  

• Notes: A case study using GBRAM for a commercial system.
  

[AP98b] A.I. Antón, C. Potts. "A Representational Framework for Scenarios of System Use." Requirements Engineering Journal, Springer Verlag, pp. 219-241, December 1998.

• Abstract: This paper examines the space of representational alternatives for scenarios and how representation and use constrain each other. It further outlines how requirements engineering can benefit from the adoption of representational techniques that originate in downstream software engineering processes, human-computer dialogue design and organizational process design.
  

[Hoc01] M. Hochhauser. "Lost in the Fine Print: Readability of Financial Privacy Notices."

• Abstract: Financial privacy notices were analyzed for readability and found to be written at a 3rd-4th year college reading level despite the recommended level of junior high. This means that consumers have a hard time reading and understanding the notices because of complicated sentences and uncommon words. The author classifies 60 different financial privacy notices according to their reading level and gives six strategies for ensuring that a notice is written in a "clear and concise" manner.
  

• Notes: Offers six strategies for ensuring that privacy policy notices are written in a "clear and concise" manner.
  

[Kov95] G. Kovacich. "Security Requirements for Voice Messaging Operations." Network Security, Feb 1995 p.15-18.

• Abstract: Private branch exchanges (PBX) give companies control over their voice and data communications networks. Attacks from hackers and internal threats are not prevented by establishing security policies and procedures documentations for each PBX. However, these policies and documentation must exist and address the major security threats, vulnerabilities and risks, and applicable countermeasures. This can form the basis on which to develop a more secure system.
  

• Notes: Security policy and procedures documentation pertaining to PBX.
  

[PTA94] C. Potts, K. Takahashi, A. Antón. "Inquiry-Based Requirements Analysis." IEEE Software March 1994 p.21-31.

• Abstract: The Inquiry Cycle model was developed to support requirements identification. An inquiry-based approach to the analysis process uses a series of questions and answers that are designed to pinpoint where information needs come from and when. A case study of the Meeting Scheduler problem was used to demonstrate this cycle.
  

• Notes: The Meeting Scheduler problem was used to demonstrate the Inquiry Cycle model.
  Inquiry Cycle model - a formal structure for describing discussions about requirements
  Scenario - a description of one or more end-to-end transactions involving the required system and its environment
  Stakeholder - anyone who can share information about the system, its implementation constraints, or the problem domain
  Assumption - an answer to a tacit question about the requirements without articulating the question