diff --git a/Day 4 (initial stakeholder meeting prep)/notes.txt b/Day 4 (initial stakeholder meeting prep)/notes.txt
index 831f45c..b58ff1f 100644
--- a/Day 4 (initial stakeholder meeting prep)/notes.txt	
+++ b/Day 4 (initial stakeholder meeting prep)/notes.txt	
@@ -4,7 +4,7 @@
 * Example outline of requirements
 	* Document info (table of contents, preparer, revision date, related documents, change log)
 	* Overview
-	* Problem domain description (entities, attributes, relations, cardinalities, causal rules, events, data/file formats, information sources, hardware and software external to the system to be developed)
+	* Problem domain description (entities, attributes, relations, cardinalities, causal rules, events and sequence, data/file formats, information sources, hardware and software external to the system to be developed)
 	* Requirements (queries, behavioral rules)
 	* Platform
 	* Expectations
diff --git a/Day 6 (problem domain entities)/CampusVisits.md b/Day 6 (problem domain entities)/CampusVisits.md
new file mode 100644
index 0000000..9fc3601
--- /dev/null
+++ b/Day 6 (problem domain entities)/CampusVisits.md	
@@ -0,0 +1,46 @@
+
+# Campus visits
+
+## Overview
+
+In the Math and CS Department, the current workflow for campus visits works as follows.
+ 1. The department secretary receives a campus visit request from the campus visit office.
+ 1. The secretary sends an email to the computer science professors asking if someone could take the visit.  Information pertaining to the visit is included in this email (prospective student's name, anticipated major, hometown, date of visit, and possible times that could be scheduled that day).
+ 1. Professors email back saying that they can take the visit and at what time.
+
+The main problem is with the last step.  Professors will often delay in responding, for a variety of reasons.  For example:
+ - A professor might be *technically* available for a certain day, but it would be hectic to fit it in so they would rather someone else take that one.
+ - Professors might delay in responding, reasoning that if they delay then someone else will take it.
+ - A professor might not be able to, but won't actually respond saying so.
+
+This results in the secretary having to send multiple emails asking for someone to take the visit, and/or the CS chair polling the secretary to see if a visit is taken yet.  When an incoming student doesn't know if they will be meeting with a professor it sets a bad impression, especially for those who travel great distances for the campus visit. 
+
+## System expectations
+
+We would like a system to address the following:
+
+- There should be some way of encouraging a balance between the number of visits assigned to various professors (perhaps there should be a record of number of visits taken, etc.)
+- We expect a quick turnaround time, so that the student has confirmation of which professor they are meeting with in, say, within a few days of the visit info coming to the department secretary.
+- The system should eliminate the need for the secretary to nag and for the CS chair to poll to see if visits are taken or not.
+- Address the "social loafing" problem by managing better communication between the professors (for example, some quick and convenient way of expressing "I can do this visit if nobody else is available, but I would rather not")
+
+## Entities
+
+- Users
+    - Role: zero or more of (Coordinator, admin, tour guide)
+    - Busy times (for guides)
+- Visits
+    - Possible times (start and end intervals)
+    - Visitors
+    - Where
+    - Decided time (start/end)
+    - Decided guide (if any)
+    - Status (proposed, assigned, completed, cancelled, conflicting)
+- Visitors
+    - Role (propsective student, parent, etc.)
+    - Antipicated start semester
+    - Antipicated majors, minors
+- Existing campus visit system to sync with?
+
+## Events
+