31-05-2012, 05:47 PM
SRS Planning and Scheduling
SRS Planning.docx (Size: 62.37 KB / Downloads: 29)
Introduction:
Software Requirement Specification (SRS) is a fundamental document, which forms the foundation of the software development process. SRS not only lists the requirements of a system but also has a description of its major features. The recommendations would form the basis for providing clear visibility of the product to be developed serving as baseline for execution of a contract between client and the developer.
SRS should accurately and completely represent the system requirements as it makes a huge contribution to the overall project plan. The software being developed may be a part of the overall larger system or may be a complete standalone system in its own right. If the software is a system component, the SRS should state the interfaces between the system and the software portion.
Purpose:
The purpose of the document is to convey information about the application’s requirements, both functional and nonfunctional to the reader and the user.
This document provides the following.
A description of the environment in which the application is expected to operate.
A definition of the application’s capability.
A specification of the application’s functional and nonfunctional requirements.
The document is intended to serve several groups of audiences.
First, it is anticipated that the application designers will use the SRS. Designers will use the information recorded here as the basis for creating the application’s design.
Second, the client for the project is expected to review this document. The SRS will serve to establish a basis for agreement between the client and development team about the functionality to be provided by the application.
Third, the application maintainers will review the document to clarify their understanding of what the application does.
Fourth, test planners will use this document to derive test plans and test cases.
Finally, the project manager will use this document during project planning and monitoring.
Scope:
The document is the only one that describes the requirement of the system. It is meant for use by the developers and will be the basis for validating the final delivered system. Any changes made to the requirements in future will have to go through a format change approval process. The developer is responsible for asking the clarifications where necessary and will not make any alterations without the permission of the client.
Feasibility Study:
Feasibility is the determination of whether or not a project is worth doing. The process followed in making this determination is called a Feasibility Study. Once it has been determined that the project is feasible keeping the benefit of the Organization in mind, the analyst can go ahead and prepare the project specification, which finalizes the project requirements. Different tests of feasibility are studied during the investigation. The main of them are –
Technical feasibility
Economical feasibility
Operational feasibility
Technical Feasibility:
This is concerned with specifying equipment and software that will successfully satisfy the user requirement. It involves determining whether or not a system can actually be constructed or upgraded to solve the problem at hand. The technical needs of a system may vary considerably, but might include the following:
The necessary technology of both hardware and software existed and could be acquired for the new system.
Technically, the system is designed in such a way that it provides accuracy, reliability, and easy access to the information.
Economical Study:
Economic Feasibility involves estimating benefits and costs. These benefits and costs may be tangible or intangible. It is seen whether the expenditure incurred for developing the new system will be cost effective or not. Because of the confusion between the types of costs, it is sometimes very difficult to decide if the benefits outweigh the costs. This basically involves top-level management of the company who are the decision makers. Some key findings from the study are listed below.
There was no extra cost burden to conduct a full systems investigation.
Basic Hardware and software would ensure the smooth run of the application, as the necessary tools were easily available.
The benefits are in the form of reduced costs with merely any errors, thus reducing the manual work.
If the system were used without any major changes to it, no extra costs would be incurred.
Operational Feasibility:
Operational feasibility deals with the human aspect of the organization. Proposed projects are beneficial only if they can be turned into information systems that will meet the organization’s operating requirements. This feasibility test asks whether the system will work when developed and installed. In this test it is seen whether with the existing manpower, the new system can be handled efficiently or not. If the users are not taken into confidence, resentment from them is inevitable. The users need to be convinced about the advantages of the new system. Unless this is done effectively, the system would not be implemented even after its development and the old system would continue to be used. Some key findings from the study are as follows.
It has been found to be well supportive by both the management and the users. If changes are needed, it has been notified and comprehensive solution has been designed.
The system after testing has been seen to yield better results than the prior system.
The system is designed in such a way that the user has the control in most places and accessibility of information is easier and faster.
Limitations:
The application supports only data from one database and which provides for the basic use of ERP Systems. This system also works offline and can easily be extended to be made feasible with it.
Schedule Feasibility:
The deadline for the project is sufficient enough to complete the project that meets all the aspects of the specification’s the future needs of the end user will be considered under future enhancements.
External Interface Requirements:
User Interface:
The proposed system will display screens depending upon the option selected. The system will display user-Friendly messages that can be either error massages or messages, which give guidelines to the user about how to use the system.
Performance Requirements:
Forms must be displayed within 5 seconds. The user must be informed of errors occurred, if any, within 10 seconds.
Design Constraints:
Software Constraints:
The system is to run under Windows Operating system and requires Java
language and My SQL server.
Hardware Constraints:
The computer on which the proposed system is being executed must have a
minimum requirement of Pentium III processor and 32 MB of RAM.
Acceptance Criteria:
Before accepting the system the developer will have to show by suitable test cases that all conditions are satisfied.