Software Requirements Specification
#1

[attachment=10367]
1. Introduction
1.1 Purpose

<Identify the product whose software requirements are specified in this document, including the revision or release number. Describe the scope of the product that is covered by this SRS, particularly if this SRS describes only part of the system or a single subsystem.>
1.2 Document Conventions
<Describe any standards or abbreviation that was followed when writing this SRS.>
1.3 Intended Audience and Reading Suggestions
<Describe the different types of audience that the document is intended for, such as developers, project managers, marketing staff, users, testers, and documentation writers. Describe what the rest of this SRS contains and how it is organized. Suggest a sequence for reading the document, beginning with the overview sections and proceeding through the sections that are most important to each reader type.>
1.4 Project Scope
<Provide a short description of the software being specified and its purpose, including relevant benefits, objectives, and goals. Relate the software to corporate goals or business strategies.>
1.5 References
1.5.1.1.1
<List any other documents or Web addresses to which this SRS refers. These may include user interface style guides, standards, system requirements specifications. Provide enough information so that the reader could access a copy of each reference, including title, date, and source or location.>
1.6 Details of Team Members
<Details of all the participating members and brief description of their role in the project. Also mention the team leader and other activities that would be performed by the members during the development of the project.>
2. Overall Description
2.1 Product Perspective

<Describe the context and origin of the product being specified in this SRS. For example, state whether this product is a member of a product family, a replacement for certain existing systems, or a new, self-contained product. If the SRS defines a component of a larger system, relate the requirements of the larger system to the functionality of this software and identify interfaces between the two. A simple diagram that shows the major components of the overall system, subsystem interconnections, and external interfaces can be helpful.>
2.2 Product Features
<Summarize the major features the product contains or the significant functions that it performs or lets the user perform. Details will be provided in Section 3, so only a high level summary is needed here. Organize the functions to make them understandable to any reader of the SRS. A picture of the major groups of related requirements and how they relate, such as a top level data flow diagram or a class diagram, is often effective.>
2.3 User Classes and Characteristics
<Identify the various user classes that you anticipate will use this product. User classes may be differentiated based on frequency of use, subset of product functions used, technical expertise, security or privilege levels, educational level, or experience. Describe the characteristics of each user class. Certain requirements may only belong to certain user classes. Distinguish the favored user classes from those who are less important to satisfy.>
2.4 Operating Environment
<Describe the environment in which the software will operate, including the hardware platform, operating system and versions, and any other software components or applications with which it must peacefully coexist.>
2.5 Design and Implementation Constraints
<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 customer’s organization will be responsible for maintaining the delivered software).>
2.6 User Documentation
<List the user documentation components (such as user manuals, on-line help, and tutorials) that will be delivered along with the software. Identify any known user documentation delivery formats or standards.>
2.7 Assumptions and Dependencies
<List any assumed factors (as opposed to known facts) that could affect the requirements stated in the SRS. These could include third-party or commercial components that you plan to use, issues around the development or operating environment, or constraints. The project could be affected if these assumptions are incorrect, are not shared, or change. Also identify any dependencies the project has on external factors, such as software components that you intend to reuse from another project.>
3. System Features
<This 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 mode of operation, user class, object class, functional hierarchy, or combinations of these, whatever makes the most logical sense for your product.>
3.1 System Feature 1
<Don’t really say “System Feature 1.” State the feature name in just a few words.>
3.1.1 Description and 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).>
3.1.2 Stimulus/Response Sequences
<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.>
3.1.3 Functional Requirements
<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.>
<Each requirement should be uniquely identified with a sequence number or a meaningful tag of some kind.>
REQ-1:
REQ-2:
3.2 System Feature 2 (and so on)
Reply
#2
Software Requirement Specification

[attachment=17739]

1.0 Introduction
Education Portal is a system which will provide online quizzes and assignment submission in universities/institutes/schools.

1.1 Purpose: In the traditional system of evolution which consumes a lot of time, we will rather try to develop a system which will be boon for both student and teacher. Students have to submit their assignment online which requires quite less efforts than the traditional one. Teacher will also have an ease to correct the submitted assignment which are submitted on or before the last date. As a result faculty can also keep track of students who submitted their assignment late, thus facilitating the easy evolution of assignment. Conducting the regular quizzes can be made online which contain the facility for examining the objective. Manually, the evolution pattern can lead to creep some errors unintentionally which can be avoided by the use of this system.

1.2 Scope:
This software system will be a education portal system for universities and schools. This system will provide online assignment submission and quizzes, which would otherwise have to be performed manually, which is more time consuming. This software will meet to the needs of Universities and Schools. It will be very easy to understand and use. This system will provide indirect communication between students and teachers via quizzes.
Reply
#3

to get information about the topic"software requirement specification" full report ppt and related topic refer the page link bellow

http://studentbank.in/report-software-re...cification

http://studentbank.in/report-software-re...ent-system

http://studentbank.in/report-software-re...cury-tours

http://studentbank.in/report-software-re...9%09%09%09

http://studentbank.in/report-software-re...-pucsdians

http://studentbank.in/report-online-nati...cification

http://studentbank.in/report-software-re...ion-system

http://studentbank.in/report-software-re...rking-site

http://studentbank.in/report-software-re...ion--29849
Reply
#4
This software system will be a education portal system for universities and schools. This system will provide online assignment submission and quizzes, which would otherwise have to be performed manually, which is more time consuming. This software will meet to the needs of Universities and Schools. It will be very easy to understand and use. This system will provide indirect communication between students and teachers via quizzes.
Reply
#5

to get information about the topic "Software Requirements Specification" full report ppt and related topic refer the page link bellow

http://studentbank.in/report-software-re...cification

http://studentbank.in/report-software-re...-pucsdians
Reply
#6
Software Requirements Specification


.doc   Software Requirements Specification-WRM (1).doc (Size: 213 KB / Downloads: 9)

Introduction
Software Purpose


This document specifies the requirements set for Web Recipes Management site.

WRM will provide central location for users how would like to save recipes on the internet. After uploading a recipe to WRM, the user can decide to save it to his self repository, to publish it to a predefined registered users group or to all WRM visitors. Registered user will be able to define Smart Agent Request for one or more recipe. All WRM users including visitors can search recipe in the system and open them according to the recipe view privilege. In future releases the WRM should have the ability to locate restaurants according to a certain dish, present commercial for companies and more.

WRM intend to serve mainly Israel home users. WRM will be designed for uses of, among the rest, novice users, how are not expert in using computers or internet.

This SRS document covers the entire project at this stage of development.

Software Scope

WRM designed in the Hebrew language, to allow people in Israel, or Hebrew speaking people around the world, to use it.

WRM have three main users:

1. Guest –
• Search recipe.
• View public recipe.
• Can register to WRM.
2. Registered is have the basic ability of the guest users, and to add to that –
• Upload a recipe.
• Comment on recipes.
• Grade recipes.
• Publish recipes to all users.
• Share recipes with other registered users.
• Add SAR for recipe.
• Notified by SAR when a requested recipe was published.
3. Administrator is have the ability of Registered user, and add to that –
• Set the configuration of the system.
• Define categories for the recipes.
• Approve new uploaded recipes.



User Characteristic

The users of the system have been planned in phase I:
• Users (all) should have an internet connection and have basic browsing knowledge.
• Since the web site will be designed in Hebrew, users should have good knowledge of the language and have read/write skills that would allow them to understand the recipes and upload recipes in correct language.
• User (end user) no any previous knowledge is required, every operation will have hint bubbles and very strict instructions that will make it easy in 3 steps to create, upload and save a book.
• Administrators – will need to have basic knowledge in web applications, and JavaDB.
With knowledge to manage, restore, fix tables (DBA level of expertise) .Running special functionalities of phase II (currently out of scope) such as uploading commercial ads.
• Admin should have the ability to determine when information presented by the end users causes a violation of the law, or might offend stakeholders.


Assumptions and Dependencies

• We believe that in the first phase the number of hit rate will not require load balancing appliances ,
• DB will manage to hold the initial number of thread connections.
• Search engine – since the application will be Hebrew ingredients search will be free text and will look for closest match, or by fixed checkbox for categories.



Reply

Important Note..!

If you are not satisfied with above reply ,..Please

ASK HERE

So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page
Popular Searches: insider recipes for, mrs dash recipes, software requirements specification sample of library management system, petrel hardware requirements**mba system project in iob bank, software requirements specification, algebraic specification, software specification job portal project report,

[-]
Quick Reply
Message
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Possibly Related Threads...
Thread Author Replies Views Last Post
  Software Design Principles seminar class 8 6,451 11-01-2013, 05:21 PM
Last Post: havet

Forum Jump: