Software Requirements Specification

for

Slap Weh Calories

Version 1.0 approved Prepared by P. McLeod, G. Ranger,R.Barker Slap Weh Calories

24/09/2012

Copyright 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.

Table of Contents
1. Introduction.....................................................................................................................................1 2. Overall Description.........................................................................................................................2 3. External Interface Requirements.................................................................................................. 3 4. System Features...............................................................................................................................4 5. Other Nonfunctional Requirements.............................................................................................. 4 6. Other Requirements....................................................................................................................... 5

Revision History
Name Slap Weh Calories Date 24/09/2012 Reason For Changes Initial version Version 1

1.

Introduction

1.1

Purpose

This Software Requirement Specification, (SRS) documentation describes the function and performance requirements for a software engineering project. It will contain an overview of the project describing functional requirements for the system specification among other details for the reader. The name of the product is Slap Weh Caloriess, this is the initial version, version number is 1.0. The scope of the SRS documentation, gives you the target age group of the product, some limits the user may face, requirements for Slap Weh Calories. 1.Slap Weh Calories is a web base tool that can calculate the caloric value an individual requires to maintain their current weight for a day and then allow the user to create a schedule where they can track their calorie intake for a day and allow them maintain their weight, gain or lose based on the principle that the human body requires a particular amount of calorie to carry out basic function after which the rest is stored as fat or glycogen. 2.Slap Weh Calories is in it's initial stages the primary functions which is to return the caloric value of basic food item is present, the database currently does not have a vast amount of information to compare, and the user will not get a wide variety, this will however change overtime as database will be filled via the user with administrative privileges qualified person who can validate the nutritional value of a meal .
Copyright 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.

3.Slap Weh Calories has not been standardize and should not be used to plan your diet complete but a mere reference tool. 4.Slap Weh Calories is for any group but it is recommend that before use the user checks with their physician. 5.The system database is build from scratch and hence the amount of pre-existing meals the user can look will be limited, but with time the administrator can filled them with accurate data when it comes to a food item caloric value.

1.2

Document Conventions

This SRS is pretty straightforward, divided up into sections detailing an overall description, the external interface requirements, system features, and other nonfunctional requirements. This is the initial version of the product and it has not gone through any test and the development is in the preliminary stages. Once read, it is evident that each section is important to the overall SRS and significant to the project in its own right.

1.3

Intended Audience and Reading Suggestions

This document is intended for the user interested in alternative method to weight control, health physicians, nutritionist and other individuals in the profession of food,. The SRS goes into detail about what our product does, and is not necessary for reading if all you want to do is track your caloric intake and access its other features. The information here describes product features and user requirements. The aim of Slap Weh Calories is to make it easy and effective for an individual to track their caloric intake and allow them control over their weight without the pressure of going the gym and everyday exercise which can be hard to maintain.

1.4

Product Scope

Slap Weh Calories is being developed solely for the software project and there is no intended commercial use for the software after the project is over, this said the potential of the system is very high and the software product can make a huge impact on the health industry currently this is the only version of the documentation out. There are many benefits to the product one its relatively new concept the users wont lose anything apart from weight.

Copyright 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.

1.5References
TBD

2.
2.1

Overall Description
Product Perspective

Slap Weh Calories uses the concept that human body requires a certain amount of calories to maintain their weight When your body needs energy or nutrition, it digests the food you eat, sending
valuable materials to the places where they are needed most. The excess is stored as glycogen or fat this causes weight gain. When the user enters their particulars the system returns the amount of calories they need to maintain that weight for the day, which act as a precursor so the can eat less or more calories if they like for that day this will allow the a lot more control over their weight and their health to an extent. The

2.2

Product Functions

The Product Game Player: allows user to create an account by entering certain cafeterias, once created the user gets their calorie requirements for a day. the user enter their particular meal at a specific time and get a The user can add the meal to their schedule or search for more meals. user can than log out and their results will be saved the user can the login again to add another meal and their total caloric intake for that day will be logged User logs out. Exit web site

2.3

User Classes and Characteristics

This section identifies the classes of user anticipated for the game, it is based on the users educational level. There are two basic user for the Slap Weh Calories user 1. Regular user, this user log into the system with limited privileges and they are allowed to search the system data base at anytime as long as they have an internet connection, calculate
Copyright 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.

caloric value of meals add to they schedule allowing them to track their caloric intake. 2.Administrator this user can make changes to the data base validate the calorie value of a meal and it's nutritional value as well the administrator can also add and remove user based on certain plight.

2.4

Operating Environment

The product will be built entirely with java swing, which can run on most if not all operating systems. The system requirements are based on windows. These are the minimum system requirements required to run our 2D software.

Intel Atom N450 1.66 Ghz or higher (or compatible) Windows XP Service Pack 3 (32bit) or Windows Vista/7 (32/64bit) 1 GB RAM or higher OpenGL-compatible graphics card, running in 32-bit color mode

2.5

Design and Implementation Constraints

The Web based software product Slap Weh Calories allows user to search their database or calculate the caloric value of a meal they wish to know about, the user requires an internet connection to access their

account and carry out the calorie calculations on their meals each day. there was a time constraint as the project was done during the duration of the school semester with other courses and a very short time to complete the developers had also had limited contact time due to conflicting schedules so much of the features of the program was not added.
<Describe any items or issues that will limit the options available to the developers. These might include: corporate or regulatory policies; hardware limitations (timing requirements, memory requirements); interfaces to other applications; specific technologies, tools, and databases to be used; parallel operations; language requirements; communications protocols; security considerations; design conventions or programming standards (for example, if the customers organization will be responsible for maintaining the delivered software).>

2.6
TBD

User Documentation

Copyright 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.

2.7Assumptions and Dependencies

It is assumed the user is computer literate and can read above the grade three level access to the internet to access. The meals in the database are placed in the by nutritionist and may be subject to change if this doesnt seems accurate enough to the administrators which are the web site creators and the nutritionist.

3.
3.1

External Interface Requirements

User Interfaces

<Describe the logical characteristics of each interface between the software product and the users. This may include sample screen images, any GUI standards or product family style guides that are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that will appear on every screen, keyboard shortcuts, error message display standards, and so on. Define the software components for which a user interface is needed. Details of the user interface design should be documented in a separate user interface specification.>

3.2Hardware Interfaces
TBD

3.3
TBD

Software Interfaces

3.4
TBD

Communications Interfaces

4.

System Features

<This template illustrates organizing the functional requirements for the product by system features, the major services provided by the product. You may prefer to organize this section by use case, mode of operation, user class, object class, functional hierarchy, or combinations of these, whatever makes the most logical sense for your product.>

4.1

System Feature 1

Copyright 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.

4.1.1

Description and Priority

High Priority <Provide a short description of the feature and indicate whether it is of High, Medium, or Low priority. You could also include specific priority component ratings, such as benefit, penalty, cost, and risk (each rated on a relative scale from a low of 1 to a high of 9).>

4.1.2

Stimulus/Response Sequences
Users choose the game they wish to play and the game will appear in another window, so that the list of games will be easily accessible. <List the sequences of user actions and system responses that stimulate the behavior defined for this feature. These will correspond to the dialog elements associated with use cases.>

4.1.3

Functional Requirements

The functional areas of the of Slap Weh Calories will include logging on/off, creating account, calorie count, adding user, removing user, search, add meal to database. The following section will describe the the functional requirement of slap weh calories. 4.1.4Create account REQ-1: the Slap Weh Calorie System shall provided first users with a form which will ask the user for the following values a.age, b. weight c. height , d.level of activeness REQ-2:the following values will will be tabulated and the system will return the number of calories the user needs to maintain their current weight each day. REQ-3: Create account also will ask the user to enter a unique username and password to protect their account and determine the type of user that is trying to access the system. 4.1.4 Logging on/off REQ-4: Once the user account has been created and validated. The user can access his or her account by entering their username and password.

Copyright 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.

REQ-5 once the system identifies the user, the user can access the system features which are allocated based on their password. 4.1.6 Search REQ-6 the user can search the Slap Weh Calories' data base for existing meals and the meals corresponding caloric value. REQ-7 Slap Weh Calories does not have the desired meal the user can mention this and the administrator will add the meal to the database. 4.1.7 Calorie Counter REQ-8 Slap Weh Calorie provides their user with the option of add calculating the caloric value of a meal by entering the ingredients and it's quantity. 4.1.8 Schedule REQ-9 Slap Weh Calorie gives a shedule to their user where the can keep track of their meals and the amount of calories they have consumed each day. REQ-10 The user can add meals to their schedule via two methods which mention in section 4.1.6 and 4.1.7. REQ-11 The total caloric intake or calories is totaled and displayed to user as they add to their schedule. REQ-12 The user can evalute the total value returned to them to determine if the should consume more calories or less. This depends on the user's goals off course. 4.1.9 Remove user REQ-13 Slap Weh Calories give user with administrative privileges the option to remove user depending on certain circumstances. 1.the user wishes to deactivate their account. 2. the user has been inactive for a period of time. 3. the user violates certain regulations. 4.1.9.0 Add user REQ-14 Another feature only accessible to user with administrative privileges, the admin might have to add user because of the following: 1. user doesnt remember password or user name or both 4.1.9.1 Modify Account the user can modiy their account as can the administrator based on the following reasons :

Copyright 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.

1. increase/ decrease in user height, weight or level of activeness 2. the user might wish to change their password

<Itemize the detailed functional requirements associated with this feature. These are the software capabilities that must be present in order for the user to carry out the services provided by the feature, or to execute the use case. Include how the product should respond to anticipated error conditions or invalid inputs. Requirements should be concise, complete, unambiguous, verifiable, and necessary. Use TBD as a placeholder to indicate when necessary information is not yet available.> <Each requirement should be uniquely identified with a sequence number or a meaningful tag of some kind.>

REQ-1: REQ-2:

4.2

System Feature 2 (and so on)

5.
5.1

Other Nonfunctional Requirements

Performance Requirements

<If there are performance requirements for the product under various circumstances, state them here and explain their rationale, to help the developers understand the intent and make suitable design choices. Specify the timing relationships for real time systems. Make such requirements as specific as possible. You may need to state performance requirements for individual functional requirements or features.>

5.2 TBD

Safety Requirements

<Specify those requirements that are concerned with possible loss, damage, or harm that could result from the use of the product. Define any safeguards or actions that must be taken, as well as actions that must be prevented. Refer to any external policies or regulations that state safety issues that affect the products design or use. Define any safety certifications that must be satisfied.>

5.3

Security Requirements

TBD No security detail is need for this product, the user does not have to submit any harmful
Copyright 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.

information, just download and play.

<Specify any requirements regarding security or privacy issues surrounding use of the product or protection of the data used or created by the product. Define any user identity authentication requirements. Refer to any external policies or regulations containing security issues that affect the product. Define any security or privacy certifications that must be satisfied.>

5.4

Software Quality Attributes

<Specify any additional quality characteristics for the product that will be important to either the customers or the developers. Some to consider are: adaptability, availability, correctness, flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability, and usability. Write these to be specific, quantitative, and verifiable when possible. At the least, clarify the relative preferences for various attributes, such as ease of use over ease of learning.>

5.5
TBD

Business Rules

<List any operating principles about the product, such as which individuals or roles can perform which functions under specific circumstances. These are not functional requirements in themselves, but they may imply certain functional requirements to enforce the rules.>

Appendix A: Glossary
Fat Glycogen ATP

calorie

protein

kilogram

<Define all the terms necessary to properly interpret the SRS, including acronyms and abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire
Copyright 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.

organization, and just include terms specific to a single project in each SRS.>

Appendix B: Analysis Models

<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams, state-transition diagrams, or entity-relationship diagrams.>

Appendix C: To Be Determined List

<Collect a numbered list of the TBD (to be determined) references that remain in the SRS so they can be tracked to closure.>

Copyright 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.