1. Recipe Repository RequirementsDesignPlanning

2. Requirements

3. What We Are Building A website for users to login and securely store their own personal recipes free of charge. Users have ability to convert from standard/metric, decrease/increase recipes servings and print recipes For a fee, users can join the recipe community. Share recipes with other members and exchange their opinions with each other.

4. System Functions The repository will have three different types of users. A free basic user, Premium users and Administrative users. Basic and premium users must create a unique login to enter the website. Free Basic Membership includes: Access to their private recipes Access to their private recipes Add new recipes Add new recipes Convert units between metric and standard Convert units between metric and standard Change ingredients measurements to change the serving size Change ingredients measurements to change the serving size

5. System Functions Cont’d… Premium users will have all of the functionality of the free user and also will be able to: Search through the other premium members recipes Search through the other premium members recipes Generate a grocery list for print out Generate a grocery list for print out Have ad-free access to the repository Have ad-free access to the repository Have the choice to make their recipes public or private Have the choice to make their recipes public or private Administrative users, which will include site managers (webmaster) and those who help maintain the site, will also have the ability to: Edit recipes Edit recipes Maintain clarity and site standards Maintain clarity and site standards Remove erroneous entry information Remove erroneous entry information Help edit and mange user accounts Help edit and mange user accounts

6. Stakeholders Those effected by the outcome of the project: Professor, Clark Elliott Professor, Clark Elliott Members of Team Go Members of Team Go All potential members of the website. All potential members of the website.

7. Requirements Structure Functional Requirements Fundamental System Functions Fundamental System Functions Viewing the repository (taken directly from document) Repository will be supported on Internet Explorer 5.0 or higher, no other browser viewing will be supported or guaranteed. Repository will be supported on Internet Explorer 5.0 or higher, no other browser viewing will be supported or guaranteed. The repository will be supported for desktop pc and laptop viewing only. No other media will be supported. The repository will be supported for desktop pc and laptop viewing only. No other media will be supported. All Areas of the site will be managed in American English, no translation will be provided. All Areas of the site will be managed in American English, no translation will be provided. Access by the Free User Access by the Premium User Access by the Administrative User Design Design Errors/Exceptions Errors/Exceptions

8. Requirements Structure Non-Functional Requirements Platforms Platforms Ruby on Rails MySQL Performance Performance 99.9% Availability Reliability Reliability Maintenance/Updates Maintenance/Updates Risk Assessment Risk Assessment Project Deadline is firm. No time for Scope Creep. No changes to the requirements unless PM feels it is critical to to run.

9. Testing functionality of the site Each page is linked and login is responsive Randomly chosen test users will create a personal account. Randomly chosen test users will create a personal account. Test 1 will verify that the usernames and passwords chosen are saved in the database by logging off and on again. Test 1 will verify that the usernames and passwords chosen are saved in the database by logging off and on again. Test 2 will verify that duplicate names cannot be chosen. Appropriate error messages will guide them to correct the error. Test 2 will verify that duplicate names cannot be chosen. Appropriate error messages will guide them to correct the error. The database will be tested to verify all queries can be completed. Recipe sharing will be tested to make sure appropriate access is given to free, premium and administrative users. ALL pages and links will be checked and guaranteed to be working.

10. Testing usability of the site Four users, representing varied experience, will test the navigation capability of the website. Each user will be given navigation instructions and then a brief survey to comment on their experience. Team Go will modify design based on user response.

11. Wolf/Thieves Statements Wolf pack included Syed, Sven and Anna. Thieves included Joe and Syed. Members read the document and provided in red type their comments and why. The comments were analyzed and discussion were held online and in person. Editor: Anna, corrected all grammar, spelling errors. Ensured all states made sense and were consistent with group discussions.

12. The Wolf’s Work The document did not indicate any standards for the aesthetic design of the website. Team Go could simply provide text links one after another without proper instructions. The document now includes a User Acceptance section, which states that drawings must be submitted by a deadline or else Team Go will use its discretion.

13. The Thief’s Work The original document stated we were to create a few users some of which were free, premium, administrator. Were there other users?….The client wanted more! The document now reads “…three user types will be created. They are the basic user, the premium user, the administrative user…”

14. Design

15. How will this Work? Design Demonstration Design Demonstration Finite State Machine Finite State Machine

16. Planning

17. Planning Strategies Tools that allow us the ability to deal with expected and unexpected events. Timetables that help to keep track of tasks completed. Meetings to remain aligned with the project.

18. How Are We Planning? Microsoft Project 2003 Easily view both group and individual tasks Easily view both group and individual tasks Shows critical paths and deadlines Shows critical paths and deadlines Allows for easy re-planning Allows for easy re-planning Yahoo Groups Central access to vital team files Central access to vital team files Individual Calendar Individual Calendar Message forum for group communication Message forum for group communicationMeetings Physical meeting twice a week. Physical meeting twice a week. Face to face interaction Face to face interaction

19. Re-Planning The Chief Planner had the responsibility of assigning due dates for tasks in such a way that emergency situations could cause an adjustment to the plan without affecting the major milestones. We also agreed on regular communication through email, telephone and other mediums about the status of the task to be completed. The use of our planning software gave the planner the ability to evaluate changes to the plan quickly when the due date of one of the task changed. In the event that a task could not be completed the strategy to be followed included: Team members are/were responsible for the specific task agreed to notify Planner and Project Manager about the current task delay as soon as possible. Team members are/were responsible for the specific task agreed to notify Planner and Project Manager about the current task delay as soon as possible. Other individual in the group were asked and made themselves available to assist in getting the task done with the least delay as possible. Other individual in the group were asked and made themselves available to assist in getting the task done with the least delay as possible. Good News: Based on the slack of time that was initially given to most tasks, the final due date of the project was not changed.

20. Practical Planning Demonstration Group Calendar Dependencies Individual View Re-Planning Strategy

21. THANK YOU!