SRS IEEE 830
Name
Professor
Course
Date

SRS IEEE 830
Software requirement specifications (SRS) are essential in software development process. It is expected to define software requirements in the correct way because it exists in order to perform the task that requires solving. SRS should not offer a description regarding any implementation or design details as it will be described during the project’s design stage. It should not also impose other constraints on the software as they are specified in other documents. A good SRS is required to be correct, consistent, complete, unambiguous, modifiable, traceable and verifiable (IEEE, 1998). There should be an agreement regarding the functionality of completed software between the supplier and customer at the beginning of the development process involving the software. The agreement should be jointly prepared because neither the supplier nor the customer has the qualifications to write a reputable SRS alone. This is because customers are not conversant with software designs and development process and suppliers do not comprehend the customer’s problem that is needed to satisfy their requirements.
A special situation is evident when a system including its software is defined concurrently. This implies the predefinition of the functionality, performance, interfaces including other software constraints and attributes although they are subject to change and negotiation and are jointly defined. This implies that an SRS that fails to comply with the requirements arising from the parent system specification is rendered incorrect. There is need for the evolution of SRS during the progressing of software product development and the specifications of some details at project initiation may be impossible. Changes may ensue as discoveries regarding shortcomings, inaccuracies and deficiencies are evident in the SRS, which poses two major considerations. First, requirements require thorough and complete specifications that are known at the time although evolutionary revisions can be inevitably foreseen. This is inclusive of noting the incomplete facts. Second, formal change processes require initiation to identify, track, control and report the projected changes. Changes that gain approval in terms of requirements should be subject to SRS incorporation so as to offer accuracy and completeness in audit trail resulting from changes and permitting the review regarding current and future SRS portions. Project requirements use prototyping, which is used for three reasons. It enables the customer to react after viewing it rather than reading the SRS, which implies quick feedback. It displays unanticipated aspects related to system behavior, which produces answers alongside new questions that assist in reaching the SRS closure (IEEE, 1998). An SRS that relies on a prototype is considered to comprise of less change, which shortens the development time. It should be utilized in a way that elicits software requirements and features. Standards compliance specifies the requirements that are derived from regulations or existing standards. This includes accounting procedures, data naming, report format and audit tracing. . Software system attributes serve as requirements and require specifications in order to ensure the object verification of their achievement. The attributes include portability, reliability, maintainability, security and availability.
Systems have varied behaviors depending on their operation modes. However, the choice relies on whether performance and interfaces are dependent on mode. System modes include user class, which involves varied sets of functions to varied classes of users. Objects comprise of counterparts within a system and are real-world entities. Feature is considered a service that is desired externally by the system and may require input sequence so as to effect desired results. Stimulus involves organizing systems in order to facilitate function description in the form of stimuli. Response involves organizing systems through describing all the functions that support the response generation.
Functional hierarchy arises when the above schemes fail to be helpful. It involves organizing the overall functionality into a functions hierarchy that is organized by common inputs, outputs or internal data access. In order to indicate the relationships between functions and data, data dictionaries and data flow diagrams may be used. The contemplation of a new SRS requires the use of organizational techniques. This involves the need to organize specific requirements based on multiple hierarchies that are tailored to system specification needs.

Reference
IEEE. (1998, June 25). IEEE Recommended Practice for Software Requirements Specifications. IEEE-SA Standards Board. Retrieved July 21, 2014, from http://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf