Know what a requirements document is. Understand and discuss its uses
	- contract negotiation, user req on proposal/bids, system req on contract sign
	- lets stakeholders get an understanding of the system
	- lets developers know what to implement
Know what requirements specification is. Understand ways of writing requirements
	-
Able to discuss advantages and disadvantages of stating requirements in natural language
	- easier for users to understand
	- disadv: with calculations and math it gets much harder to understand
Understand guidelines for writing requirements
Understand structured and tabular format for expressing requirements.

Four activities common to RE
- Elicitation
- Analysis
- Validation
- Management/changes

Four problems with requirements elicitation
- dont know what they want
- express requirements poorly
- requirements change
- different stakeholders conflicting reuqirements

interviewing:
- customers focus on specifics
ethnography
- can give better info on nonfuntional requirements, like organizational
- downside: no innovation

requirements validation
- validity
- consistency
- completeness
- realism
- verifiability

















===============================
System Modeling:
4 different kinds of models
	- Context models
		- How the system fits in with other external systems
	- Interaction models
		- Use Case
			- Models user interactions, helping identify requirements
			- Models communication between systems
		- Sequence Diagrams
			- Models system structure, component interaction
			- calls/returns, alt box, loop box
	- Structural models (for system architecture)
		- Static
			- Class design
				- UML diagrams
				- classname, attributes, and methods
				- public/protected/private!!
		- Dynamic
			- Architecture Description Language
	- Behavioural models
		- Describe what happens when external stimulus happens
		Data driven models:
			Activity model
				- Square is data, oval is process
			Sequence Diagram
		Event Driven models:
			- with minimal data processing
			State diagram/finite state machine

Model driven engineering:
	- higher abstraction
		- good: quick to change platforms
		- bad: too abstracted, cant test for bugs
			- often  have to spend just as much time on the UML and translator

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

Architectural Design
- Advantages of explicit architecture:
	- focuses stakeholder discussion
	- facilitates analysis of requirements
- Disadvantages
	- Rigorous notation
	- No industry standard

Architectural system characteristics - these impact how you design your arch
	- Performance
	- Security
	- Safety
	- Availability
	- Maintainability

Architectural Views (types of models, diff perspectives)
	- Logical view
	- Process view
	- Development view
	- Physical view

PATTERNS
	Good design goals:
		- low coupling, high cohesion
	Object Oriented Arch
		- can change impl without changing other objs
		- design whole system as many interacting objects
		- disadv: objs need to identify all other objs it wants to interact with
	Model View Controller
		- use when future is unknown
		- Allows data to change independently of its view
		- Supports presenting the same data in different ways
		- disadv: high code complexity when data model/interactions are simple
	Layered Arch
		- use when dev spread across several teams
		- Can replace entire layers
		- Redundant services can be provided in each layer
		- disadv: clear separation between layers is hard
		- disadv: perf bottlenecks
		open vs closed layers
	Client-Server
		- servers can be distributed (modular)
		- general functionality doesnt need to be reimplemented, simply called as a service
		- disadv: each service is a single point of failure
		- disadv: performance depends on the network now, too
		- disadv: servers typically owned by diff organizations (management problem)
		- disadv: client objs but know identity of servers
	Repositories
		- use when large volume of long term data is generated
		- use when data driven systems, data insert/update causes action
		- components dont need to know about other components
		- changes in one component are easily propagated
		- disadv: repo is single point of failure
	Implicit Invocation
		- use when events
		- Good for reuse
		- System volution is simple
		- disadv: special protocols needed
	Pipe and filter
		- used when batch data processing
		- Supports reuise
		- Easily understood by orgs
		- Can evolve easily by adding filters
		- disadv: needs common protocols and data formats