CPSC 3720 - DAY 16
FEBRUARY 24, 2017

================================================================================

Exam Review
-----------

	Waterfall Method
		Unidirectional, no way back, finish this step befor moving on
		Not flexible, delays earlier affect later steps
	
	Iterative Model
		Break project up into interations based on functionality
		"mini-waterfall"
		at the end of each iteration, you deploy a functional system
		Pros: constant customer feedback,  they can adjust different 
		functionality add/remove
	
	Requirements Engineering
		Help software engineers understand the problem that they are
		trying to solve
		Must understand the domain or business context
			How will the user use the system?
			How will the system be used day-to-day?
		Fact finding
			How is the problem currently solved
				Is that the best way to solve it?
		Envisioning
			How will the planned system work
				Not too much detail
		Final output - requirements specification
	
	Stakeholder
		Can be an individual, a team and organizaiton
		Has interests in or concerns related to the system
			They all have a stake, but the stakes may differ
		End users
			Functionality and ease of use
		Customer
			Costs and timelines
		Future maintenance organization
			How easy it is to maintain
		Business analysts
			Will this work in our domain
			Is the price right?
		Lawyers
			Legal, privacy issues
		Software Architects and Developers
			Can this be implemented?

	Requirements Gathering
		AKA Requirements elicitation
		Customer need to define
			What is required
			What is to be accomplished
			How system fits into the needs of the business
			How system used on a day-to-day basis
		Customer statement of work
		Interview stakeholders to get he complete set of requirements
		Get priorities
			Small scale to rank, 1-5 preffered
		Make user stories

	User stories
		ex: as a tenant, I can unlock the doors to enter my apartment.
		Similar to system requirmenets, but focus on the user benefits
		instead fo system features

	Functional vs. Nonfunctional Requirements
		Functional Requirements
			Describe interactions between system and its
			environment and users
		Non-functional requrements
			Describe aspects of the system not directly related to
			functional behavior of the system.
			Not something the user can do
			Still a requirement of the system

	Non-functional requirements
		FURPS+
			functionality
			usability		}
			reliability		} Quality Requirements
			performance		}
			supportability		}
			+
				implementation		}
				interface		}
				operations		} Constraints/ Pseudo
				packaging		} Requirements
				legal			}

	Use Cases
		Capture functional requirements
		Contain related scenarios
			Sequence of steps
			Describe interactions between users and system
			One thing that could happen
			Related scenarios are grouped together into a use case
		External view of the system
			Not tied to specific classes.

	Contents of a Use Case
		Title
		Goal Level
		Main Success Scenario
		Extensions
		Primary Actor
			Has the goal that the use case is trying to solve
		Secondary Actor	
			Also involved in the use case
			Not driving the goal
			System may communicate with them
		Precondition, guarantee, trigger
	Agile and Iterative methods have less formal specification requiremnts

	Verifiable - tests can be done to see if it meets the reqirments, not
		doesn't have errors

	Traceable - each requirment can be traced throughout the developement
		process to it's corresponding system functions

	Design goals come from non-functional requirments