CPSC 3720 - DAY 3
JANUARY 18, 2017

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

REQUIREMENTS ENGINEERING
------------------------

	.The hardest single part of building a software system is deciding what
	to build. 
	.Helps software engineers understand the problems 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 on a a day to day basis?
	.How is the problem currently solved.
	.Envisioning
		.How will the planned system work
			.Not too much detail
	.Final output - requirements specification
	.Usually replaces a job a human used to do.
		.Automation

CUSTOMER STATEMENT OF WORK
--------------------------

	.AKA customer statement of requirements
	.Informal description
	.What the customers think they need
	.Opinion based.


WELL-DEFINED PROBLEM
--------------------

	.Key task of requirements engineering
	.Includes:
		.Requirements
			.Critera that will determine if a proposed system solves
			the problem or fails to solve it.
		.Resources and components avaliable to solve the problem
			.These can be a restriction on how the problem can be
			solved.
			.Ex. due to a security concerns, no parts can be
			connected to the internet.

STAKEHOLDER
-----------

	.Can be an individual, a team, and organization
	.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 to maintain
	.Business analysts
		.Wil this work in our domain
	.Lawyers
		.Any legal issues, privacy issues
	.Software Architects and Developers
		.Can this be implemented?

Requirements Process

Requirements gathering > Requirements analysis > Requirements specification

REQUIRMENTS GATHERING
---------------------

	.AKA Requirements Elicitation
		.Customer interviews
	.Customer needs to define:
		.What is required?
		.What is to be accomplished?
		.How the system fits into the needs of the business
		.How the system is used on a day-to-day basis
	.Customer statement of work
	.Interview stakeholders to get a complete set of requirements
	.Get priorities
		.Small scale (ex 1-5)
	.Make user stories (extreme programming method)
	.Obstacles
		.Customer doesn't know what they want
		.Software engineers don't understand the domain
			.Stakeholders can be so familiar that they don't think
			it needs to be explained.
		.Hard for customer to envision completed system.
		.Hard for customer to envision leaps in technology.
	.Ask a lot of questions
		.How does this work?
			.Is that the best way?
		.What is your role in the system?
			.How can it be easier?
			.What obstacles do you face?
		.Define domain terms
			.Customer may not, so used to them.	
			.You need to use them in the system.
		.Make suggestions
			.If the customer doesn't like them, find out why
		.Always ask why
		.Don't get too technical yet

	.User stories are similar to system requirements but focus on user
	benefits, instead of on system features.
	

ON-SCREEN APPEARANCE REQUIREMENTS
---------------------------------

	.Do not waste your time by creating elaborate screenshots with many
	embellishments, coloring, shading, etc that serves only to distract
	attention from most important aspects of the interface
		.E.x. color scheme
		.Don't show them a prototype GUI
	.Hand-drawing the proposed interface forces you to economize and
	focus on the most important features.
	.Only when there is a consensus that a good design is reached,
	invest effort to prototype the interface
	.The customer does not understand that the GUI is the easy part.

REQUIREMENTS ANALYSIS
---------------------

	.After recieving requirements from the customer
	.Refine the requirements
	.Develop User Scenerios
	.Develop use cases
	.Ensure the developers understanding of the requirements matches the 
	customers
		.Understanding the problem domain.
	.Make high level estimations.