Contents

Introduction

In this paper the requirement engineering Commitment Analysis Approach (CAA) method is elaborated . The CAA method identifies software requirements based on policy commitments. It helps organizations to honour the statements in their policy documents and thus avoid illegal practices (Young & Antón ,2010). This is important for instance in America where a corporation can be fined by the Federal Trade Commission (FTC, 2012) when they detect illegal practices. The FTC closely watched how corporations collect, store and use the personal information of users.

The method is created by Jessica Young who is a Ph.D. Candidate on the North Carolina State University and Dr. Annie I. Antón who is a professor at the North Carolina State University (Young & Antón ,2010). It was developed during a formative case study of four healthcare organizations policy documents. After they developed the CAA method they validated the method with success by doing a summative case study on policy documents at eight other healthcare organizations (Young & Antón , 2010).

In Figure 1 (Young & Antón, 2010) the three main step of the CAA method can be seen. These are explained below:

1. Prepare privacy policy for analysis
   In this first step the requirement engineer takes a policy document and prepares it for the CAA. This is done by splitting the document up into single statements. Young & Anton (2010) advise to use the Manning & Schutze’s (1999) algorithm to identify what the boundaries of all sentences in the policy document are and thus create single statements according to these boundaries. For instance, a boundary may be a question marks, punctuation or when a sentence contains examples it is combined to one boundary.
2. Classify statements
   When the policy document sentences have been split into different statements it is time to classify the statements. There are three main classifications named: Scope, Actor and Concept. The scope describes the basis for the action that is made, which can be either procedural or legal. Statements that are legal in scope are derived from a particular law or regulation and statements that are procedural express actions that are taken based on organizational practices or policy and do not mention law or regulation. The Actor is the one that performs the action described in the statement who can either be an organization or user. The last classification is called concept, which states if an action is a necessity or possibility, can be classified as a commitment, privilege or right. Next to this, the single statements are assigned to attributes. These attributes become more clear in the example which is given in the next section.
3. Operationalize classified statements into requirements
   When all statements are classified, the statements can be transformed into requirements. This is done by making use of two different templates. These two templates will be shown and explained in the example section.

Figure 1. Main steps CAA.  

Example

In this part an example will be given for the CAA method. The template, which can be found in Appendix A, is used for this example. The policy paragraph from Google Plus, which users need to sign when they make an account, will be used. The paragraph states the following:

‘’Information you provide – When you sign up for a Google Account, we ask you for personal information. We may combine the information you submit under your account with information from other Google services or third parties in order to provide you with a better experience and to improve the quality of our services. For certain services, we may give you the opportunity to opt out of combining such information. ‘’ (Google, 2012) (Google, 2012).

The steps from the CAA method, which are mentioned in the introduction, will now be used to get requirements out of this policy paragraph.

Step one: Prepare privacy policy for analysis The preparation of the privacy policy requires the requirement engineer to split up the paragraph into separated statements. This gives the following result:

Statement1	When you sign up for a Google Account
Statement2	When you sign up for a Google Account
Statement3	We may combine the information you submit under your account with information from other Google services or third parties in order to provide you with a better experience and improve the quality of our services.
Statement4	We may give you the opportunity to opt out of combining such information.

Step two: classify statements
Now that the statements are separated, they can be classified and assigned to attributes. This is important for step 3 where a template needs to be filled in according to classifications and attributes to get the requirements. The result of the classification can be seen in Table 2 and the result of assigning attributes can be seen in Table 3.

	Scope	Actor	Concept
1. When you sign up for a Google Account	Procedural	user	privilege
2. We ask you for personal information	Procedural	organisation	commitment
3. We may combine the information you submit under your account with information from other Google services or third parties in order to provide you with a better experience and improve the quality of our services.	Procedural	organisation	right
4. We may give you the opportunity to opt out of combining such information.	Procedural	user	privilege

Table 2. Assign Classification to statements.

	Statement1	Statement2	Statement3	Statement4
Actor	user	organisation	organisation	user
Action	sign up	ask for	combine information	opt out
Object	Google Account	personal information	Information user submits	information
Object’s source		user	from other Google services or third parties
Target	the user		the user
Purpose			Give better experience and improve the quality of our services.	the user
conditions
Examples

Table 3. Assigning attributes to statements.

Step three: Operationalize classified statements into requirements Now that all statements are classified and assigned to attributes, the statements can be transformed into requirements. This is done by filling in one of the two different templates made by Young & Antón (2009). The first template is shown in Figure 2. which is intended for the concept commitment. The second template is shown in Figure 3. Which is intended for the concepts privilege and right.

This gives the following result:

Requirement1	The system shall require the organisation to ask personal information from user.
Requirement2	The system shall allow the organisation to sign up a Google account to the user.
Requirement3	The system shall allow the organisation to combine information that the user submits from other Google services or third parties in order to give better experience and improve the quality of services.
Requirement4	The system shall allow the user to opt out information.

 

Process Deliverable Diagram

Weerd & Brinkkemper (2009) describe a way of modelling which delivers the Process Deliverable Diagram (PDD). It consists of two different parts, on the left side the Meta-process model and on the right side the Meta-data model. The Meta-process model shows all activities that should be executed in which order and the Meta-data model shows which products are derived from the activities. The PDD is shown in Figure 4. Part of making a PDD is creating a Concept table which can be seen in Table 3, where all concepts are fully explained. Also an activity table should be created which is shown in table 4, where all (sub)activities are fully explained.

Figure 4. Proccess Deliverable Diagram (PDD).

Activity	Sub-activity	Description
Prepare privacy policy for analysis	Collect all relevant policy document	POLICY DOCUMENTS are needed to parse sentences into STATEMENTS, thus the requirement engineer needs to collect the relevant POLICY DOCUMENTS.
	Parse all sentences into statements	Young & Anton (2010) advise to use the Manning and Schutze’s (1999) algorithm to identify what the boundaries of all sentence in the POLICY DOCUMENTS are and thus create single STATEMENTS according to these boundaries. For instance, a boundary may be a punctuation, question marks or when a sentence contains examples it is combined to one boundary. This is done by the requirement engineer.
classify statements	Assign classification	There are three main classifications named Scope, Actor and Concept which should be assigned to the STATEMENTS. The scope describes the basis for the action that is made which can be either procedural or legal. The Actor is the one that performs the action described in the statement who can either be an organization or user. The last classification called concept, which states if an action is a necessity or possibility, can be classified as a commitment, privilege or right. This is done by the requirement engineer and results into the CLASSIFICATION LIST
	Assign attributes	All STATEMENTS need to be assigned to attributes in order to make REQUIREMENTS out of them. There are a total of seven attributes: actor, action, object, object’s source, target, purpose and pre-condition. This is done by the requirement engineer and results into the ATTRIBUTE LIST.
Operationalize classified statements into requirements	Operationalize classified statements using commitment requirement template	The template can be found in Figure 2. This will result into COMMITMENT REQUIREMENT. This is done by the requirement engineer
	Operationalize statement using privilege/right requirement template	The template can be found in Figure 3. This will result into PRIVILEGE/RIGHT REQUIREMENT. This is done by the requirement engineer.

Table 3. (sub)activities.

Concepts	Sub-Description
ATTRIBUTE LIST	A list in the CAA method where statements are assigned to attributes (Young and Antón, 2010).
CLASSIFICATION LIST	A list in the CAA method where statements are assigned to classifications (Young and Antón, 2010).
COMMITMENT REQUIREMENT	A requirement that is an obligation, promise, etc. that restricts one's freedom of action (Young & Antón ,2010).
POLICY DOCUMENT	Policy documents describe how consumers’ or users’ personal information will be collected, stored, and used by the organization (Young and Antón, 2010).
PRIVILEGE/RIGHT REQUIREMENT	A requirement that is a grant to an individual, corporation, etc., of a special right or immunity, under certain conditions (Young & Antón ,2010).
REQUIREMENT	A thing desired or needed (Young & Antón ,2010).
REQUIREMENT TEMPLATE	A template for the CAA method that is used for a privilege/right or commitment requirement. (Young & Antón ,2010)
STATEMENT	A message that is stated or declared; a communication (written in this case) setting forth particulars or facts (Young & Antón ,2010).

Table 4. Concepts.

Related works

In this section relevant requirement engineering literature is addressed.

About CAA
Young & Antón (2010) is the first paper that is used in this paper. In their paper they describe how and why they developed the Commitment Analysis Approach (CAA), how it works and give an extensive examples of this method.

As has been told in the introduction Young & Anton (2010) advise to use an algorithm to identify where the boundaries of all sentence in the policy document are, which is important in the first step of the CAA. A detailed description of the algorithm can be found in the paper of Manning & Schutze’s (1999).

The CAA method is based on the idea that it ensures organisations to honour the statements expressed in their policy documents (Young & Anton, 2010). Researchers have shown that it is indeed important for requirement engineers to identify requirements from policy documents. This is elaborated in by Antón, Earp & Cartel (2003), Antón, Earp, Frink & Gheen, (2007) and Breaux, Antón & Vail (2006).

Related methods
Antón & Earp (2004) introduced a dynamic system that changes trough new insights and discoveries of website privacy requirements. The system consists of vulnerabilities and privacy protections. Organizations can express with the system how they will protect the consumers privacy. It is created to help requirements engineers not skip any of the privacy requirements. In contrast the CAA method helps organisations do what their privacy policies state. Robinson (2005) has developed a framework called REQMON which monitors software requirements at runtime which has the same goal as the CAA, making sure that the policies are honoured. The difference with the CAA method is that the CAA focuses on the initial derivation of requirements that are compliant with policies.

Ghanavati, Amyot & Peyton (2007) created an approach to track legal compliance. The technique they use connects models of business processes with legislations. The difference is that the CAA uses a commitment-based approach while Ghanavati et al. (2007) use a goal-based approach.

Breaux & Antón (2005) and Breaux, Antón & Vail (2006) introduced a legal-based approach to get requirements out of legal text. Antón & Young (2010) say that legal-based approaches do not give sufficient enough coverage of requirements as expressed in policy documents. They also state that the reason for this is that policies emphasize procedural practices rather than legal practices. The legal-based approach focuses on rights and legal obligations while the CAA focus on commitments, privileges and rights.

 

Reference

Antón A.I., Earp J.B., Carter R.A., (2003). Precluding Incongruous Behaviour by Aligning Software Requirements with Security and Privacy Policies. Information and Software Technology, 45(14), 967-977.

Antón AI., Earp JB. (2004). A requirements taxonomy for reducing web site privacy vulnerabilities. Requirement Engineering Journal, 9(3), 169-185.

Antón A.I., Earp J.N., Vail M.W., Jain N., Gheen C., Frink J.M., (2007).‘’HIPAA’s Effect on Web Site Privacy Policies, ‘’ IEEE Security & Privacy, 5 (1), 45-52.

Breaux T.D., Antón A.I., (2005). Deriving Semantic Models from Privacy Policies, Proceedings of the IEEE 6th Workshop on Policies for Distributed Systems and Networks, Miami, USA, 67-76.

Breaux T.D., Antón A.I., Vail M.W. (2006). Towards Regulatory compliance: Extracting Rights and Obligations to Align Requirements with Regulations, Proceedings of the 13th IEEE International Conference on Requirements Engineering, Los Alamitos, USA, 35-67.

FTC. (2012). About the Federal Trade Commission. Retrieved 16 02, 2012, from http://www.ftc.gov/ftc/about.shtm

Google. (2012). Privacy Policy. Retrieved 16 02, 2012, from Google: www.google.com/int/en/policies/privacy

Ghanavati S., Amyot, Peyton L., (2007) Towards a Framework for Tracking Legal Compliance in Healthcare, Proceedings of the 19th International Conference of Advanced Information Systems Engineering, Los Alamitos, USA, 218-232.

Manning C.D., Schutze H., (1999). Foundation of Statistical Natural Language Processing, Cambridge, MA: The MIT Press.

Robinson W.N., (2005), Implementing Rule-Based Monitors within a Framework for Continuous Requirements Monitoring, Proceeding of the 38th Hawaii International Conference on System Science, Hawaii, USA, 34-56.

Weerd, I. van de, & Brinkkemper, S. (2009). Meta-modeling for situational analysis and design methods. Handbook of Research on Modern Systems Analysis and Design Technologies and Applications, 38-58.

Young, J., & Antón, A. (2010). A Method for Identifying Software Requirements Based on Policy Commitments. Proceedings of the 2010 18th IEEE International Requirements Engineering Conference, Los Alamitos, USA, 47-56.

 

-- OlivierRichters - 12 Apr 2012