SOFTWARE SPECIFICATION

Specifications are mandatory requirements for system and software acquisitions

(a)Explain why these requirements are important.

(b)How are these requirements addressed in package software acquisition?

(a)System specification (SRS) is the process in which user of the software system state what he/she really want to appear in the new system. SRS fully describes what the software will do and how it will be expected to perform it.

An SRS minimizes the time and effort required by developers to achieve desired goals and also minimizes the development cost. A good SRS defines how an application will interact with system hardware, other programs and human users in a wide variety of real-world situations. Parameters such as operating speed, response time, availability, portability, maintainability, footprint, security and speed of recovery from adverse events are evaluated.

Here we establish the basis for agreement between the customers and the suppliers on what the software product is to do. The complete description of the functions to be performed by the software specified in the Software Requirement Specification will assist the potential users to determine if the software specified meets their needs or how the software must be modified to meet their needs. SRS is used as the basis of for a contract with clients all the time that are to check if the delivered system corresponds with requirements specified.

Reduce the development effort. The preparation of the SRS forces the various concerned groups in the customer organization to consider carefully all of the requirements before design begins and reduces later redesign, recoding, and retesting. Careful review of the requirements in the SRS can reveal omissions, misunderstandings, and inconsistencies early in the development cycle when these problems are easier to correct. So even developers concentrate more in what is specified in the documents.

 Provide a basis for estimating costs and schedules. The description of the product to be developed as given in the SRS is a realistic basis for estimating project costs and can be used to obtain approval for bids or price estimates. We use the SRS as the basis for our fixed price estimates, since after providing the requirement, the price of the software system is negotiated so without requirement, it would be difficult to estimate the price the software.

 Provide a baseline for validation and verification. Organizations can develop their validation and Verification plans much more productively from a good SRS. As a part of the development contract, the SRS provides a baseline against which compliance can be measured. System requirement specification can be used to create the Test Plan.

Facilitate transfer. The SRS makes it easier to transfer the software product to new users or new machines. Customers thus find it easier to transfer the software to other parts of their organization, and suppliers find it easier to transfer it to new customers.

 Serve as a basis for enhancement. Because the SRS discusses the product but not the project that developed it, the SRS serves as a basis for later enhancement of the finished product. The SRS may need to be altered, but it does provide a foundation for continued production evaluation.  This is often a major challenge especially when the SRS is not continually updated with changes.

(b) Software Requirement are addressed in package software acquisition as analyzed below;

The following are the key processes and steps involved in a software package acquisition project, based on the Package Acquisition Capability Maturity Model.

Planning

Planning for the software acquisition begins when the idea or need is established for acquiring a software product. This phase can be divided into three parts, these are; Key acquisition roles are assigned, Describe the Business Need and Document the Acquisition Plan. A package acquisition project requires just as much planning as a software development project. It involves producing preliminary budgets, developing a schedule, defining the acquisition strategy and identification of risks. Planning should take place early in the project and prior to any contractual actions.

Requirements Definition

In the Define the Software Product requirement step of the acquisition process, the software requirements are elicited, analyzed, specified and validated. This step drives the direction of the acquisition. The desired product must be adequately analyzed and its individual features and quality attributes decided on and documented. It is essential to establish a common and unambiguous definition of the contractual requirements that is understood by the project team, business and the supplier. This will include both technical (software requirements) and non-technical (contractual requirements). This all needs to be documented in the Business Requirements document.

Supplier Selection

In the Select a Supplier step of the acquisition process the results of the supplier evaluation are judged against established selection criteria, risk associated with each supplier are identified and analyzed, and a cost/benefit analysis is conducted. Based on this information, the final supplier selection is made. Other things which may be considered here are Supplier Scoring and Supplier Qualification Audits. Then an Invitation to Tender (ITT) needs to be prepared and the supplier selected who is best capable of satisfying the requirements of the contract. It must include planning and performing the activities necessary to issue the Invitation to Tender, preparing for the evaluation of suppliers' responses, carrying out the evaluation, negotiation with the suppliers and awarding the contract.

Project Management

Throughout the project the activities of the project team and any supporting contractors must be managed to ensure a timely, efficient and effective software acquisition. This will involve planning, organizing, leading and controlling the project; determining and scheduling the project tasks; training; leading the project team and testing and acceptance of the software products and services.

Contract Control

Once the supplier has been selected the contract or agreement terms are negotiated and the contract is awarded. Now is the time to do the final negotiation with the preferred supplier. In this step, the final terms of the contract are negotiated and the contract is maintained .Ongoing control is needed to ensure that the product and services acquired are being performed in accordance with contractual requirements and that evolving products and services will satisfy the contractual requirements. It involves providing input and guidance to the supplier and identifying risks and problems in the work. The contract provides the binding agreement for establishing the requirements for the product and services to be acquired. It establishes the mechanism to allow the project team to oversee the supplier's work and evaluate the products and services.

Identify and evaluate potential suppliers.

In the Identify and Evaluate Potential Suppliers step a market search is performed to make sure that we are considering the available candidate suppliers and their software products. Sufficient preliminary research should be performed to narrow the list to the few potential suppliers that best match our business needs in order to target our evaluation and keep evaluation costs to a minimum. The data collected during the market search can be used as feedback to reassess our original requirements and to determine whether modification to those requirements will result in greater overall value in terms of cost, performance, availability, reliability, etc. The market analysis should also cover maintenance and support data, test results, and user satisfaction analyses.

Methods for doing this include:

· Formal Request-For-Proposal (RFP)

·  Supplier Demos and Conferences

· Prototypes and Evaluation Copies

· Supplier Evaluations, References and Past Performance

Transition to Support:

To provide for the transition of the acquired software products to production use and ongoing support. The project team provides for an orderly, smooth transition of the software products from the supplier to the support organization.

By concluding, it may be deduced that software system requirement specification is an important part in the system acquisition since it enable computer system department to acquire system which is working correctly and with a reasonable cost. So it is important for any organization to pass through these stages before acquiring any system to avoid defects in the acquired system.