 |
|
#1
11-25-2011, 06:28 PM
|
||||
|
||||
another sample SRS,final project help,cs619
1.1. Introduction
This project is about the Online Budgeting System of an Organization. Currently; In Pakistan, no organization using this technology. OBCS basically design to assists budget managers and the administration in creation of and tracking budget expenditures. Online Budgeting System is helpful because it eliminates and improves the inefficiencies and difficulties such as lack of documentation, management issues, confusion, communication or data loss, etc. Online Budgeting system is a step towards meeting the needs of all who take part in the Budgeting process. The system is designed as an online system, allowing the user to access data from any computer with online access. 1.2. Purpose Purpose of this document is to list down all the user requirements and then derive functional and non-functional requirements of the system from them. Intended users for this document are both the vendor the Project Team and the Hospital The development of a sound hospital budgeting system is fast becoming matter of paramount importance in hospital administration. Hospital services prove sensitive to incentives built into the payment system. The specific impact upon services depends upon the design of the budgeting system. By adopting online budgeting system, there will be changes in hospital health services like cost containment strategies of hospital management such as: a reduction of staff; a more selective use of beds; and more stringent procedures for investments in medical technology. The common characteristic of these instruments is that they all reduce the volume of cost for the treatment of patients. The system is designed as an online system, allowing the user to access data from any computer with online access. The first step is to break down the production system in to a set of activity centers. Industries in macro level, departments and divisions in to micro level. These departments are classified as either final or intermediate centers. Final centers provides services that are directly consumed by the patient, and the intermediate centers that produce services which are consumed by others centers. In a hospital budget, the activity centers are revenue and non revenue departments. The second step is to define the unit of output or service produced department. This step is essential to associates costs with level of service and to permit interdepartmental transfers to be quantified. The third step is to define the relationship between the inputs and outputs at departmental level. There are two classes of inputs for which relationship must be specified: external and internal. External input relationships include the expected quantities of labor, supplies and other direct costs required at alternative output levels. Internal input relationships include the expected quantities of intermediate departmental outputs and indirect cost required at alternative output levels. 1.3. Scope This budgeting system comprises of three main characters; 1. User 2. Finance Manager 3. IT-Administrator USER will get login with respective password and id. Then he will fill up the form that carries the demand along with quantity and estimated price. After that pass on it to the respective department. The request seen by the respective department and take the action according to the availability of products. In last reporting has be done for that particular item in all files or ledgers. Finance Manager is responsible for budgeting management, allocation in to the respective heads like Capital, Payroll, Expenses and Clinical Income. FM is responsible for making budget report on monthly or yearly basis. IT-Administrator plays a vital role in managing the network between the user and finance manager. He is responsible for creating, editing, updating and deleting an account. A little ignorance in management leads to serious bad effects on Budgeting System. 1.4. Definitions, Acronyms and Abbreviations Web based system: A computer software system which has its interface developed for internet browser. Patient: The user on the website who has a medical problem to discuss with the doctor. Capital: Assets of the firm not include as expense. Revenue: Generated Income of the organization and donations are in include in this department Terms Description OBCS Online Budget Control System VU Virtual University SW Software SKMCH&RC Shaukat Khanam Memorial Hospital and Research Centre SRS Software Requirement Specification FM Finance Manager 1.5. Use Cases and usage scenarios 1.5.1. Use Case Diagram Actor:- User: Finance Manager: IT-Administrator: 1.5.2. Usage Scenarios Use Case Title Login Abbreviated Title Use Case Id UC01 Requirement Id Desecration : The User wants to log on to the OBCS Pre Conditions: 1. The User has properly turned on the system and connected to the OBCS Task Sequence Exceptions 1. The use case starts when the user comes and wants to log in to OBCS. 2. The system asks the user to enter his / her ID and Password to log in. 3. The users enter his / her assigned ID and Password and click the appropriate button. Alternate-3a. 4. The system verifies the given ID and Password and logs the user in to his / her personal account. Exception 1. 5. The use case end. Alternate Scenarios: 3-a: The user closes the logon page. 1- Go to step 2 1. The user enters wrong ID or Password. Then the system will generate an error message and asks again for User ID and password. Post Conditions: 1. The user has logged on to the OBCS and does all the authorized operations to which he / she HAVE rights. Modification history: 30th December 2006 Author: F062010-- Use Case Title Fill Application Form Abbreviated Title Use Case Id UC02 Requirement Id Desecration : The user filling the form according to their needs for sending request. Pre Conditions: 1. User has logged on to the system Task Sequence Exceptions Scenarios: 1. Use case starts when user wants to apply for certain request. 2. He / She open the application form and filling the form (Item Name, Quantity, Department, Estimated Price, Justification) 3. User will submit the application form. Alternate Path 2-a. 4. Use case end. Alternate Scenarios: 2b: User cancel the action 1- Go to step 2 Post Conditions: 1. A new application has been added. Modification history: 30th December 2006 Author: F062010-- Use Case Title Budget Request Abbreviated Title Use Case Id UC03 Requirement Id UC02 Desecration : 1. User will sending request for budget accept from fill application form use case. 2. Applicant view his / her result for request; whether he / she has accept a request or not Pre Conditions: 1. User has logged on to the system. 2. Fill the application form and submit in to the budget request of the system. Task Sequence Exceptions 1. After logging and submitting the request, user waits for the system result for requests. 2. User validates it. Alternate Path 2-a , 2-b 3. System displays the result of Budget Request. Exception1 4. System Accept and stores the Request form and informs the user. 5. Selected applicant will be informed further detail for further processing. 6. Use case ends. Alternate Scenarios: 2-a-1: User Wishers to make changes. -2: Control Goes Back to step1 2-b: Delete the Form. 1. Invalid appropriate Budget Request. System display appropriate message. Post Conditions: 1. Applicant has successfully confirmed. Modification history: 30th December 2006 Author: F062010-- Use Case Title Budget Management Abbreviated Title Use Case Id UC04 Requirement Id Desecration : In this section the Finance Manager manages the budget. Pre Conditions: 1. There is a new event in the budget system. A budget is borrowed or some new budgets are allocated for Budget Departments. Task Sequence Exceptions 1. The use case starts when there is some event in OBCS. And the Finance Manager wants to do manage budgets in different departments. 2. The system gets the required information from the Finance Manager and shows the proper place to do the changes. 3. The use case ends Post Conditions: 1. The Finance Manager successfully make changes in the Budget Management. Modification history: 31st December 2006 Author: F062010-- Use Case Title Budget Allocation Abbreviated Title Use Case Id UC05 Requirement Id UC04 Desecration : In this section Finance Manager allocate the budget to different departments Pre Conditions: 1. Finance Manager has logged on the system. 2. There is a new event in the budget system. A budget is borrowed from Budget Management. 3. The Finance Manager observes that budget should be allocated or it should for different Budget Departments. Task Sequence Exceptions 1. Use case starts when Finance Manager contact the system to Budget Allocation. 2. Finance Manager tells the system what to do allocate. Alternate 2-a. 3. The system gets the required information from the Finance Manger. 4. The Use case ends. Alternate Scenarios: 2-a: Finance Manger does not wish to allocation 1- Process ends. Post Conditions: 1. The Finance Manger has successfully allocated the budget. Modification history: 31st December 2006 Author: F062010-- Use Case Title Budget Status Abbreviated Title Use Case Id UC06 Requirement Id Desecration : Finance Manager or user checks the Budget Status according to their rights and departments. Finance Manager checks the budget status and then give the approval or disapproval for the request of user. Approved report will be available for user. Pre Conditions: User or Finance Manager has logged on to the system. Task Sequence Exceptions 1. The use case starts when User or Finance Manager request the system to check the Budget Status of Department. 2. User or Finance Manager selects the department he / she wants to check the budget status. Alternate 2a: 3. Use Confirms the selection. Alternate 3a: 4. Use case ends. Alternate Scenarios: 2a: All Departments status can only view Finance Manager. 1-Use case ends. 3a: Use cancel the action 1- Go to step 2 Post Conditions: 1. Status of Budget has been displayed. 2. Concerned people have been informed. Modification history: 31st December 2006 Author: F062010-- Use Case Title Report Abbreviated Title Use Case Id UC07 Requirement Id Desecration : Finance Manager want to view a report of all the major events of OBCS. Pre Conditions: Finance Manager have got every thing updated with all the events. Task Sequence Exceptions 1- The use case starts when the user wants to view a report of all the major events happening in OBCS 2- Select the required category of information 3- The System gathers the information from the user and generates a report. 4- Use case ends Post Conditions: The User and Financial Manager has got the report of all events in the system Modification history: 31st December 2006 Author: F062010-- Use Case Title Account Management Abbreviated Title Use Case Id UC08 Requirement Id Desecration : In this section the most important features is covered; which is the management of user accounts and assigning them to their rights. Pre Conditions: 1. The Administrator has to manage all the accounts and also to assign them rights according to their position. Task Sequence Exceptions 1. The use case starts when the IT-Administrator is to manage the account information of the user. 2. The system will help Administrator to keep the Database of the users. 3. The use case ends Post Conditions: 1. The Administrator manages all the current accounts. Modification history: 2nd January 2007 Author: F062010-- Use Case Title Create New Account Abbreviated Title Use Case Id UC09 Requirement Id UC08 Desecration : There is a new user who wants to be a member. He / She need a unique ID and Password to use the OBCS. So, he / she will contact the IT-Administrator to create an account for him / her. Pre Conditions: 1- The IT-Administrator is asked to create a new account. Task Sequence Exceptions 1- Use case starts when IT-Administrator requests the system to a New Account. 2- System responds by new file for account. 3- IT-Administrator provides information to the system with the identity of the applicant who is now a new user. Exception1 4- Provide the users information. IT-Administrator also provide the user-id according to relative department and assign rights. 5- The system save the information Alternate Path 6-a, 6-b. 6- System saves changes and inform the concerned people about the changes 7- Use case ends. Alternate Scenarios: 6-a: IT-Administrator reject changes 1- System will not save the changes. 2- Use case ends. 6-b: IT-Administrator cancel the action 1- Go to step 3 1- Applicant identity is invalid system display appropriate message and control goes back to step3. Post Conditions: 1- An account is successfully created. Modification history: 2nd January 2007 Author: F062010-- Use Case Title Update Account Abbreviated Title Use Case Id UC10 Requirement Id UC08 Desecration : This use case allows updating basic profile information. This use case will work for already existing user in the system. Pre Conditions: • IT-Administrator has logged on to the system. Task Sequence Exceptions 1- The use case starts when user to update the basic profile information. 2- The IT-Administrator first enter the User-id whose information is to be updated. Exception 1 3- IT-Administrator selects the information; which he wants to update and give new information. 4- After updating all the information that IT-Administrator wants to update, user will save the information. 5- The system will display a appropriate message to confirmation of update account. Alternate Path 6-a., 6-b. 6- User agrees with changes System update the profiles and saves changes. And inform the concerned people about the changes 7- Use case ends. Alternate Scenarios: 5-a: User reject changes 1- System will not save the changes. 2- Use case ends. -b: User cancel the action 1- Go to step 3 1- If no User exist; IT-Administrator executes from this use case. Post Conditions: 1- Old profile has been replaced with the new information. 2- A concerned person has been informed about the changes. Modification history: 2nd January 2007 Author: F062010-- Use Case Title Delete Account Abbreviated Title Use Case Id UC11 Requirement Id UC08 Desecration : This use case is basically to delete the existing profile from the system. Normally we are not supposed to delete the profile of user only happens in case of mistake. Pre Conditions: 1- IT-Administrator has logged on to the system. Task Sequence Exceptions 1- The use case starts when user wants to delete same information. 2- IT-Administrator enters the user-ID whom profile he / she wants to change Exception1 , 3- User’s deletes the profile. Alternate Path 3-a, 3-b 4- System confirms from user about deletion the profile 5- Use case ends. Alternate Scenarios: 5a: User reject deletion 1. System will not save the changes 2. Use case ends 5b: User cancel the action. 1- Go to step 2 1- No applicant in the system or not exist; then system display the appropriate message. Post Conditions: 1- Information of that user has been deleted. Modification history: 13th April 2007 Author: F062010-- Use Case Title Change Password Abbreviated Title Use Case Id UC12 Requirement Id Desecration : This use case allows user can change password according rights. Pre Conditions: 1- User has logged on to the system. Task Sequence Exceptions 1- The use case starts when user wants to change password of account. 2- IT-ADMINISTRATOR enters the user-id whom password changes or departments users already exist the user id. Exception1 , 3- User’s Enters the current password and new password with confirm password. 4- Users confirms and save the change password. Alternate Path 4-a, 4-b 5- Change password successfully store in databases. 6- Use case ends. Alternate Scenarios: 4a: User reject deletion 1. System will not save the changes 2. Use case ends 4b: User cancels the action. 1- Go to step 2 1- No applicant in the system or not exist; then system display the appropriate message. 2- Wrong current password enter; then system display the appropriate message. Post Conditions: 1- Password of that user has been changed. Modification history: 13th April 2007 Author: F062010-- Use Case Title Log Off Abbreviated Title Use Case Id UC13 Requirement Id Desecration : The user wants to logoff from the OBCS Pre Conditions: 1- User must login from existing User-ID and Password. 2- User have an account. Task Sequence Exceptions 1- The use case has been start when user wants to logoff from the system 2- user select the logoff; all the session remove from the system. Alternate Path 2-a. 3- user has BEEN SUCCESSFULLY logout from the system. 4- Use case ends. Alternate Scenarios: 2a: User cancels the action. Go to step 2 Post Conditions: 1- User has been completely logout from the ssytem. MODIFICATION HISTORY: 13TH APRIL 2007 Author: F062010-- And more usage scenarios according to your system. 1.6. Supplementary Requirements Supplementary Specifications capture requirements that are not included in the use cases. These are usually called non functional requirements. Requirements which are necessary for the software to run or work properly are described here. 1.6.1. Usability SW should be user friendly. The things which would be in user use should be properly defined and documented. 1.6.1.1. Required Training Time: System should be extremely user friendly. Candidate whose is giving test should not have to lean any thing major. An ordinary computer user who uses internet should be able to use this application on first time. GUI should be simple and self descriptive. 1.6.1.2. Measurable Task Time: If the user is trained how to perform the common tasks with the application, then the entry of common tasks will take about 1 minute to 3 minute depending upon the RAM and CPU power. 1.6.2. Reliability 1.6.2.1. Avalilability • System must be available for 24 hours and 7 days in a week. 1.6.2.2. Mean Time Between Failures(MTBF) • In case of failure of the web server site can be switched to backup location within 24hours. 1.6.2.3. Mean Time To Repair Failures(MTTR) • In case of system failure while the web server is live back up can be restored within minimum time. 1.6.2.4. Bugs rate • Suitable bugs and defect rate is kept under consideration. 1.6.2.5. Software Reliability A software failure is an execution event where the software behaves in an unexpected way. A software fault is a static program characteristic. Software faults cause software failures when the faulty code is executed with a particular set of inputs. 1.6.3. Supportability • Code should be simple and easily readable with proper comments where need • Naming conventions should be according to the policy of standards. 1.6.4. System Requirements 1.6.4.1. Hardware Requirements • Any Pentium-based PC-compatible computer system with SVGA-compatible display • Microsoft Windows NT 4.0 (SP6a) or Windows 2000 (SP2 or 3) • 64 MB RAM minimum, 128 MB recommended 1.6.4.2. Software Requirements • Microsoft Internet Explorer 5.01 with SP2 or later 1.6.4.3. Development Tools o Microsoft SQL Serer 2005 Express Edition o ASP. NET Development Server o Visual Studio 2008 Professional Edition Beta 2 o Language: C#.Net o LINQ o Visual Web Developer 2008 Professional Edition Beta 2 o Microsoft.Net Framework 2.0 o Microsoft.Net Framework 3.0 o Microsoft.Net Framework 3.5 Beta 2 
|
|
Linear Mode
