1 / 21

Recipe Repository

Recipe Repository. Requirements Design Planning. Requirements. 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

jeremy-duffy
Download Presentation

Recipe Repository

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Recipe Repository Requirements Design Planning

  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 • Add new recipes • Convert units between metric and standard • 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 • Generate a grocery list for print out • Have ad-free access to the repository • 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 • Maintain clarity and site standards • Remove erroneous entry information • Help edit and mange user accounts

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

  7. Requirements Structure • Functional Requirements • 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. • 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. • Access by the Free User • Access by the Premium User • Access by the Administrative User • Design • Errors/Exceptions

  8. Requirements Structure • Non-Functional Requirements • Platforms • Ruby on Rails • MySQL • Performance • 99.9% Availability • Reliability • Maintenance/Updates • 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. • 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. • 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 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 • Shows critical paths and deadlines • Allows for easy re-planning • Yahoo Groups • Central access to vital team files • Individual Calendar • Message forum for group communication • Meetings • Physical meeting twice a week. • 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. • 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!

More Related