Internship Report on Overall Branch Bank

Download Internship Report on Overall Branch Bank

How to avoid Cheating Case & Zero marks in Assignments?

Dear fellows,

Lots of students are really hardworker & they really do they own work in making assignment solution but they are getting Zero Marks.
In this discussion i will give you some useful tips to avoid Cheating Case or Zero marks by instructor



You can avoid this (Cheating Case or zero marks) by using following techniques


1. Always trust in Allah and do your own work honestly. hopefully there will be no issue of cheating.


2. use unique kind of formatting for your assignment.

3. Try to rephrase the sentences in your own word rather than copy pasting from handouts or internet source or other student's solved assignment.

4. Use correct & suitable synonyms for the typical words used in definition or explanation taken from handouts, books or any other source...


5. Rephrase the definitions, Explanation & sentences in such a way that every 5th word should not be similar to the handouts or any other source. You can use synonyms also.



6. After completing Assignment , Right click on Assignment file and click on "properties" then click on "Summary" and make sure that its your name is written in "Author field"

SRS Report of Stock Management System (Accepted)

<Stock Management System>

Software Requirements Specification (SRS)

Version 1.0

  

Submitted By:      

Yasir Javaed

mc090200982

    Revision History

Date (dd/mm/yyyy)	Version	Description	Author
28/05/2011	1.0	Introduction of the project	Mc090402972
		Inventory Management system is an enterprise-wide discipline or the system apprehensive with the recognition and tracking of Inventory Information Services inventory and production line asset. Managing stock effectively is important for any business, because without enough stock, production and sales will grind to a halt. Stock control involves careful planning to ensure that the business has sufficient stock of the right quality available at the right time. Stock can mean different things and depends on the industry the firm operates in. It includes: Raw materials and components from suppliers Work in progress or part finished goods made within the business Finished goods ready to dispatch to customers Consumables and materials used by service businesses

Scope Of Stock Management System

To create direct principles for inventory control over belongings procure or dispensed to the association. As I know that property consists of material goods, furniture, fixtures and equipment. The elemental intention of this strategy is to ensure that such items are properly recorded and valued in the inventory systems, and defended alongside burglary or loss.

This article is meant to help scope stock management needs of a project and find a method that meets the needs of the project, and all parties involved, without adding undue administrative or technical overhead, and that is (hopefully) efficient, user-friendly, and secure.

Functional and non Functional Requirements:

Functional Requirement:-

"A requirement specifies a function that a system or component must be able to perform." 

Functional requirements specify specific behavior or functions, for example:

Characteristically some functional requirement:

ü      Transaction corrections, adjustments, cancellations

ü       Administrative functions

ü      Authentication

ü       Audit Tracking

ü       Certification Requirements

ü      Ropes the footage of Actual Cost by Product

ü       Wires the soundtrack of Weighted Average Cost by Product

ü      Supports the recording of FIFO Cost by Product

ü      Supports Planning Identifier for Make Only, Buy Only, or a Combined Value for On-Going Make/Buy Analysis

ü      Supports Identification of Multiple Vendors and Associated Information per Product (See Purchasing Section)

ü      Supports Online Explosion of Multi-Level and Indented BOM's

ü      Supports the Phantom BOM's

Non functional Requirements:-

"A non-functional requirement is a statement of how a system must behave, it is a constraint upon the systems behavior."

In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture.

Examples

A system may be required to present the user with a display of the number of records in a database. This is a functional requirement. How up-to-date this number needs to be is a non-functional requirement. If the number needs to be updated in real time, the system architects must ensure that the system is capable of updating the displayed record count within an acceptably short interval of the number of records changing.

Other examples:

•           Accessibility

•           Audit and control

•           Availability (see service level agreement)

•           Backup

•           Capacity, current and forecast

•           Certification

•           Compliance

•           Configuration management

•           Dependency on other parties

Use Case Diagrams:

Ø      Use Case:

A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse.

Ø      Actors:

An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures.

Ø      Associations:

 Associations between actors and use cases are indicated in use case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use case.  Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line. The arrowhead is often used to indicating the direction of the initial invocation of the relationship or to indicate the primary actor within the use case.  The arrowheads are typically confused with data flow and as a result I avoid their use.

Figure 1: System use case diagram.

                          

Limitations of Use Cases:

There are some limitations of the use case that is

Usability

          Color blind people should not have any difficulty in using the system color coding should take care of common forms of color blindness.

Presentation

Authorization should be completed within 1 minute 90% of the time.

Average authorization confirmation time should not exceed 30 seconds.

Access

System should be accessible over the internet – hidden requirement – security.

Because of this shortcoming, use cases must be amplified by supplementary information.

Usage Scenarios:-

ü     Login:

1. Use Case Title	Login
2.Abbreviated Title	Login
3.Use Case Id	(A).
4.Actors	Customer
5.Description  To interact with the system, the Scheme will authenticate its registration with this system. It also defines the actions a user can perform in this scheme.
5.1.Pre Conditions:  Customer or the user must have proper client installed on user terminal
5.2.Task Sequence: System show Login Screen Customer Fill in required information Enter user name and password Login scheme concede entry
5.3.Post Conditions:  System transfer control to customer main screen to proceed further actions

ü     Check Account:

1.Use Case Title	Check Account
2.Abbreviated Title	Check Account
3.Use Case Id	1
4.Actors	Customer
5.Description System will show customer current purchased Items, transaction history.
5.1.Pre Conditions:  Customer must be login to the system
5.2.Task Sequence: 1.      System will display all Customer history
5.3.Post Conditions:  1.      Customer will be on member status screen

ü     Search ITEM:

1.Use Case Title	Search Item
2.Abbreviated Title	Search Item
3.Use Case Id	2
4.Actors	Customer
5.Description  Search item makes it easy to search for product list. With this search cohort, customer can specify several search criteria. For example, product name, brand name, selling price, etc.
5.1.Pre Conditions:  User must be login
5.2.Task Sequence 1.      System will show searching screen 2.      Customer enter required information a.       It can be customer name, product specificatoin etc 3.      By pressing search button system will list down all searching results
5.3.Post Conditions:  1.      Customer can view his desire results

ü     Maintain Account:

1.Use Case Title	Maintain Account
2.Abbreviated Title	Maintain Account
3.Use Case Id	3
4.Actors	Sales manager
5.Description From this use case system will maintain inventory
5.1.Pre Conditions:  Customer must be login with its sales account
5.2.Task Sequence 1.      System will open Inventory main form
5.3.Post Conditions:  System can have updated system inventory position.

ü     Manage Customer Purchase Order:

1.Use Case Title	Manage Customer Purchase Order
2.Abbreviated Title	Manage Customer Purchase Order
3.Use Case Id	4
4.Actors	Sales manager
5. Description:  From this use case sales manager can manage purchase orders.
5.1.Pre Conditions: Customer must be logged on with sales account
5.2.Task Sequence 1.      System show all users registered with the system. 2.      Sales manager will select any customer; system will list down all assigned and unassigned permission of current customer. 3.      Sales manager can grant or revoke any securities from this screen
5.3.Post Conditions:  Customer will be restricted or granted permission

ü     Approve the order:

1.Use Case Title	Approve the order
2.Abbreviated Title	Approve the order
3.Use Case Id	5
4.Actors	Sales manager
5.Description This use case is used to approve the customer purchase order on some Items like reserved, for internal use only or blocked due to any reason.
5.1.Pre Conditions:          Customer must be logged
5.2.Task Sequence 1.      System show all items entered in the scheme 2.      Customer will select any item; system will list down all approve and unapproved orders of current item. 3.      Customer can endowment or cancel any securities from this screen
5.3.Post Conditions:  Items will be secure or approved

ü     Issue ordered Item:

1.Use Case Title	Issue ordered Item:
2.Abbreviated Title	Issue ordered Item:
3.Use Case Id	6
4.Actors	Sales manager
5.Description       This use case is used to issue items to the customer.
5.1.Pre Conditions:      System must be logon to the system
5.2.Task Sequence 1.      System display items available for the issuance 2.      Customer enters items and its member code 3.      System will mark this item as issued item
5.3.Post Conditions:  Items will be booked till issuance allowed.

v    Encryption

Encryption is the ability to encode files or stocks to be managed in such a way that fraudulent interception of the files does not allow perpetrators to be able to read and open their contents. Encryption is particular where confidentiality and classified information is to be shared.

v    Web-Based/Software

Whether the stock management technology is web-based or software-based., most management technologies by way of their definition are software-based as being so they supposedly provide for greater privacy and control over the materials being made available.

v    Synch features

The ability to synchronize files and folders shared with a selected group of customer or computers. An automatic feature checks every time a group member goes online whether he/she has all the files (and the latest revisions) available to everyone else.

v    Max file size

Limitations are there on the number and size of files that can be managed or shared to the customers.

Remote Access to specific files

Some stock management tools provide the ability to share files by enabling one or more computers to be accessed remotely so that certain files located on those machines can be accessed remotely.

       

Assignment 04 - Revised SRS document

Assignment 04 - Revised SRS document for Project

Dated: Jun 06, 11

Note: This assignment is for below mentioned students ONLY: 1.     Whose SRS document submitted in Assignment # 01, 02 or 03 has been REJECTED 2.     Whose SRS document submitted in Assignment # 01, 02 or 03 is in the category of  Needs Improvement 3.     Who have not submitted SRS document against Assignment # 01, 02 or 03   Dear Student, This is to inform you that assignment 04 (revised SRS document for project) has been given on VULMS for the above mentioned students ONLY. You must submit your revised / improved SRS document against Assignment#03 before Due Date.. Make sure no submission will be entertained through E-mail.

Use Case Diagrams for SRS Report

Use Case Diagrams

Declaration of result of Assignment# 1 (SRS Document)

Declaration of result of Assignment# 1 (SRS Document)

Dated: Apr 27, 11

The result of Assignment 01 (SRS Document) has been declared. The SRS documents have been evaluated and uploaded on the VULMS of the course. Evaluated SRS documents have been categorized under three heads: Rejected, Needs Improvement and Accepted/Approved. ONLY those students whose SRS documents are rejected or needs Improvement are required to prepare and submit Assignment # 02 (revised SRS document for project). The students whose SRS documents have been accepted are allowed to start working on their final project. Type One:      Rejected: Topic / SRS document is rejected Please Note: Without having a valid/approved SRS document you are not allowed to work on your final project. What to do now? Step 1.             Revise your topic / SRS document in the light of the instructions given in the evaluated SRS document as well as guidelines/formats uploaded on VULMS of the course. Step 2.            Submit your revised / improved SRS document against Assignment#02 before Due Date.   Type Two:      Needs Improvement Please Note: Read the instructions very carefully! The topic or the SRS document is not completely rejected. However, a revised / improved SRS document is required to be submitted. Without having a valid/approved SRS document you are not allowed to work on your final project. What to do now? Step 1.             Revise your SRS document in the light of the instructions given in the evaluated file as well as on VULMS. Step  2.        Submit your revised / improved SRS document against Assignment#02 on due date.  Type Three:   Accepted/Approved SRS document What to do now? Step 1.            Start working on your final project according to the instructions given by the instructor in your evaluated SRS document and meet the deadline given for the submission of your final project. See Semester Calendar. IMPORTANT:             The students who could not submit SRS document for project under assignment 01 can also submit their SRS documents now under assignment 02: Revised SRS document. The students whose topics are rejected by the Instructor are NOT allowed to work on the rejected topics. They are required to select a new topic according to the comments given by the Instructor. The deadline for the submission of final project will remain same as announced in semester calendar on VULMS.

SRS Document Format

<Give Here Your Own Project Title>

Software Requirements Specification

Version 1.0

   

Group Id: <Mention your group id>

Supervisor Name :< Mention your supervisor name>

             

Revision History

Date (dd/mm/yyyy)	Version	Description	Author
Current date	1.0	Introduction of the project	Write student(s) id

Table of Contents

                                                                                                                                   

1. Scope (of the project)                                                                                                  
2. Functional Requirements Non Functional requirements                          
3. Use Case Diagram                                                                                           
4. Usage Scenarios                                                                                              

SRS Document

Scope of Project:

<Write here in detail about the scope of your project>

Functional and non Functional Requirements:

<Write here in detail about the functional and non-functional requirements of your system in separate headings>

Use Case Diagram(s):

<Provide here the use case diagram of your system>

Usage Scenarios:

<Provide here the usage scenarios of all use cases in table format explaining Use Case title, Use Case Id, Actions, Description, Alternative Paths, Pre and Post Conditions, Author, Exceptions. You are supposed to provide a usage scenario for each of use case shown in use case diagram>