1.importance of sec requirement gathering
	-since it is non functional, it is often overlooked
	-stakeholders often overlook also
	-negligence may cause severe impact
	-eliciting sec requirement needs different approach
		-because functional requirements are the positive requirements where else
		sec requirements are negative requirements
		-means what can go wrong with the application instead of what can the system do
	-should enumerated separate from functional requirement
	-it is against the natural tendency of what people want, because we need to
	listdown what we don't want
	-mixing with functional requirement will make security requirement gathering complicated
	-idenfity the stake holders-user,customer, business sponsor, developers,requirement engineer,
	security expert, project managers
	-follow SMART for good security requirement-Specific,Measurable,Actionable,Realistic,Timely
		-clear and precise wordings for requirements
		-there should be clear way to test the security requirements
		-developers should clearly know what to be developed to satisfy the requirements
		-should be implementable in realtime, practically possible

2.understand SREengineering and its phases

	types
		1.functional sec requirements-input validations,authentications, strong password policy
		2.security drivers-HIPPA,SOX
	phases
		-requirement elicitation is the initial activity of SREngineering-ask for what has to be done !
			-analyze, find the stake holders, security expectation for various functioning of the system,
			-use different approach like brainstorming, white boarding, interviews, workshops,questionnaires
		-requirement analysis based on the elicitation done earlier-check the what has to be done with how can it be done !
			-check for conflicts  and ambiquity
			-check for completenes and clarity
			-check if the requirements meets stakeholders expectation
		-requirement specification
			-finalize and put in on paper
			-critical part as the development will start and continue to be based on this
		-security requirement management
			-update security requirements
			-provide support based on the approach selected-derived or dedicated

		SRE Approaches

		1.derived
				-abuse cases
				-security use cases
				-abuse stories
		2. dedicated
				-SQUARE
				-OCTAVE
		-common mistakes
			-requirement engineer will not be able to idenfity all security requirements
			due to lack of modern elicitation knowledge
			-requirements are directly specified without analyzing
			-not SMART-refer to what is SMART
			-requirements are not prioritized

3.abuse cases and its modeling
	-abuse cases
		-derived from use cases
		-captures abnormal behaviours
		-depicts the intentions of intrude,hack and compromise
		-so that stakeholders can differentiate the appropriate and
		inappropriate uses of system
	-threatens relationship
		-describes abuse case scenario
		-describes how attacker can abuse the system
	-advantages
			-easy to learn n use
			-can contribute a lot during requirement gathering process
		-disadvantages
			-can only be used in object oriented systems

4.security use cases and its modeling
	-analyze the abuse case for mitigation
		-usecase ->(includes) security use case ->(mitigate) abuse case
		-security use cases are driven from abuse cases
	-refer slide for examples
5.abuser n security stories(apart from use case)
	-refer slide for examples
6.SQUARE
	-elicitate,categorize and pritorize security requirements
	-focus is similar to derived ,
		to build security concept on the early stages of the development
7.OCTAVE
	-based on risk evaluation
	-provides structured approach to identify ,priotize and manage security risk
	-based on three phases
		-identify asset based threatens
		-evaluate and identify the vulnerabilities
		-draft the plans