Introduction to Characteristics of the SRS
To properly satisfy the basic goals an SRS should have certain properties and should contain different types of requirements. A good SRS document should have the following characteristics:
1. Completeness: A SRS is complete if everything the software the software is supposed to do and the responses of the software to all class of input data are specified in SRS. It ensures that everything is indeed specified. It is one of the most difficult properties to spot. To ensure completeness, one has to detect the absence of specification which is much harder to determine.
2. Clarity: The documented requirement should lead to only a single interpretation, independent of the person or the time when the interpretation is done. The SRS needs to be unambiguous to the authors, the users, other reviewers as well as the developers and testers who will use the document. So SRS writer should be careful about ambiguity. One way to avoid ambiguity is to use some formal requirements specification language, but it is the major drawback. The formal languages require more effort to write an SRS more cost and the increased difficulty in reading and understanding formally stated requirements.
3. Correctness: The SRS can be considered as correct if every requirements stated in the SRS is required in the proposed system. Correctness of an SRS:
Ensures that what is specified is done correctly.
Is an easier property to establish as it basically involves examining each requirement to make sure that it represents the use requirements?
There are no real tools or procedures that ensure correctness. If there are any preceding documents then the requirements from those earlier documents need to be traced to the SRS:
4. Cossistency: Requirements at all levels must be consistent with each other .any conflict between requirements within the SRS must be identified and resolved. The types of conflicts that generally occur are:
Characteristics (format details) of real word entity interfacing with the system maybe conflicting. For an example, one requirements states that an individual can work up o 6 hours whereas another requirement state is as 8 hours.
The terminology used for some entities events may be different for example different requirements may use different terms to refer to the same objects.
5. Verifiability: A SRS is verifiable if and only if every stated requirement is verifiability. A requirement is verifiable if there exists some cost effective process that can check whether the final software meets that requirements un ambiguity is essential for verifiability of requirements is often done through reviews it also implies that SRS in understandable, at least by the developer the client and the users.
6.Ranking : Generally, the requirements are stated according to their priorities are critical, other are important but not critical, and there are some which are desirable but not very important. Similarly some requirements are core requirements which are not likely to change as time passes, while others are more dependent on time. A SRS is ranked for importance and or stability if for each requirement the importance and the stability of the requirements are indicated.
7. Modificability: The SRS needs to be documented in such a manner that a history of changes can be contained in the document. It will also necessary to be able to highlight and tr5ace the changes of the requirements as we progress through the project. Certain good practices (that can lead to high modifiability are minimal redundancy and the numbering of the requirements. According to IEEE, standard 830-1993 (recommended practice for software requirements specification) SRS is modifiable if its structure and style are such that any necessary changes to the requirements can be made easily while preserving completeness an consistency while retaining its structure and style.
8. Tracability: As SRS is traceable if the origin of each its requirements is clear and if it facilitates the referencing of each requirements in future development. There are two types of traceability.
Backward traceability: to the documentation and other work products created prior to the requirements phase. This will depend upon how well referencing and labelling has been provided in the previous documents work products,
Forward traceability: will depend upon how each requirement in the SRS is labelled numbered. This traceability is extremely important, as this is one of the ways of tracing requirements to its implementation. Traceability aids verification and validation.
9. Feasibility: Though it may not be possible to confirm the feasibility of implementation of all the requirements any requirement which is apparent infeasible, should be eliminated from the SRS.
Latest technology based Software Engineering Online Tutoring Assistance
Tutors, at the www.tutorsglobe.com, take pledge to provide full satisfaction and assurance in Characteristics of the SRS homework help via online tutoring. Students are getting 100% satisfaction by online tutors across the globe. Here you can get homework help for Characteristics of the SRS, project ideas and tutorials. We provide email based Characteristics of the SRS homework help. You can join us to ask queries 24x7 with live, experienced and qualified online tutors specialized in Characteristics of the SRS. Through Online Tutoring, you would be able to complete your homework or assignments at your home. Tutors at the TutorsGlobe are committed to provide the best quality online tutoring assistance for Software Engineering homework help and assignment help services. They use their experience, as they have solved thousands of the software engineering assignments, which may help you to solve your complex issues of Characteristics of the SRS. TutorsGlobe assure for the best quality compliance to your homework. Compromise with quality is not in our dictionary. If we feel that we are not able to provide the homework help as per the deadline or given instruction by the student, we refund the money of the student without any delay.