Characteristics of Software requirement specifications
1. Correctness
2. Complete
3. Unambiguous
4. Verifiable
5. Consistent
6. Modifiable
7. Traceable
1. Correctness: This will be the genuine requirements which will be the part of SRS
2. Complete: software system will perform each and every functions as per the SRS
3. Unambiguous: which means not confusing, every requirement will be specified in the SRS which will have only one meaning.
4. Verifiable: this will do the cross verifying of the SRS which is understood by software
5. Consistent: which means stable due to the non conflicting requirement
6. Modifiable: if necessary changes can be made which doesn’t affect the consistency and also the completeness
7. Traceable: origin of the requirement should be clear that the future assist verification and also validates.
All the characteristics will be desirable and the complete one since addition or the deletion of the requirement at later stages of the software development which will be quite expensive and also the same job. This might happen due to missing of the requirement and in requirement specifications from the client side during requirement analysis activity at initial stage.
Components of SRS:
It’s difficult to arrive at the complete requirements specifications. Instead it’s better to indicate the necessary components which is good SRS to posses and a good SRS should specify all the necessary functions that the software needs to support:
1. Functionality: These are the function requirements which will specify the relationship between input and output of the system. They will verify the behaviour of the system for invalid inputs and invalid output. Functional requirements will suggest the various outputs which are being produced from the given input.
2. Performance: There will be two types of performance requirements one is static and other is dynamic.
Static requirements examples: number of terminals or number of users which are to be supported which will not impose constraints on the execution behaviour of the system.
Dynamic requirement example: response time, throughput constraints on the system.
3. Design: restrictions on implementation
Designers choices will be restricted on the various factors which will be existed in the client working environment like standard to be observed and the limitations on the resources.
Restrictions will be identified and grouped:
1. Standard compliance
2. Hardware limitations
3. Reliable and fault tolerance
4. Security
Structure of requirement documents
The requirement document has to be prepared, which has to include the complete requirements specifications of the system developed for many of the methods and standard. The recommended structure of an SRS is as below :
General structure
1 Introduction
1.1 purpose
1.2 scope
1.3 definitions, acronyms
1.4 references
1.5 overviews
2. Overall description
2.1 product perspective
2.2 product functions
2.3 user characteristics
2.4 general constraints
2.5 assumption and dependency
3. Specific requirements
3.1 external interface requirements
3.1.1 user interface
3.1.2 hardware interface
3.1.3 software interface
3.1.4 communication interface
3.2 functional requirements
3.2.1 mode 1
3.3.1.1 functional requirements 1.1
3.2.1 functional requirements 1.n
3.2 m mode
3.3 performance requirements
3.4 design constraints
3.5 system attribute
3.6 other requirements
Functional specifications with the use case
Functional specifications will be the requirement specifications which has to be specified for the proposed software systems which is being developed. As the end users have to be specified well before the software system then they realise via functionality of the proposed software which is being developed.
Basics of use case
These are the general methods for describing the functional requirements
1. Use case will be textual description which will specify the behaviour in the usual manner followed by stakeholders or the clients to feel the familiarity of the system behaviour. Use cases which represent the behaviour requirement of the software system and this kind of behaviour specifications will gather most of the functional requirements of the software system which is being developed
Characteristics of Software requirement specifications: Following are the characteristics of a good SRS document:
1. Correctness: This will be the genuine requirements that will be part of SRS
2. Complete: software system will perform each and every functions as per the SRS
3. Unambiguous: which means not confusing, every requirement will be specified in the SRS which will have only one meaning.
4. Verifiable: this will do the cross verifying of the SRS which is understood by software
5. Consistent: which means stable due to the non-conflicting requirement
6. Modifiable: If necessary, changes can be made which doesn’t affect the consistency and also the completeness
7. Traceable: the origin of the requirement should be clear that the future assists verification and also validates.
All the characteristics will be desirable and the complete one since the addition or the deletion of the requirement at later stages of the software development which will be quite expensive and also the same job. This might happen due to missing of the requirement and requirement specifications from the client-side during requirement analysis activity at the initial stage.
1. Correctness: This will be the genuine requirements which will be the part of SRS
2. Complete: software system will perform each and every functions as per the SRS
3. Unambiguous: which means not confusing, every requirement will be specified in the SRS which will have only one meaning.
4. Verifiable: this will do the cross verifying of the SRS which is understood by software
5. Consistent: which means stable due to the non-conflicting requirement
6. Modifiable: if necessary, changes can be made which doesn’t affect the consistency and the completeness
7. Traceable: origin of the requirement should be clear that the future assist verification and validates.
Characteristics of Software Requirement Specification:
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
2. Clarity
3. Correctness
4. Consistency
5. Verifiability
6. Ranking
7. Modifiability
8. Traceability
9. Feasibility
Seven Main Characteristics of a SRS are :
1. Correctness: The requirements in the SRS should be genuine.
2. Complete: As S/W system will perform each and every functions as per the SRS, it should be complete. no missing information.
3. Unambiguous: It should not be confusing. Every requirement will be specified in the SRS which will have only one meaning.
4. Verifiable: This will do the cross verifying of the SRS which is understood by software.
5. Consistent: It is stable due to the non conflicting requirement.
6. Modifiable: Necessary changes can be made without affecting the consistency and the completeness.
7. Traceable: Origin of the requirement should be clear that the future assist verification and validates.
Components of SRS:
It’s difficult to arrive at the complete requirements specifications. Instead it’s better to indicate the necessary components which is good SRS to posses and a good SRS should specify all the necessary functions that the software needs to support:
1. Functionality: These are the function requirements which will specify the relationship between input and output of the system. They will verify the behaviour of the system for invalid inputs and invalid output. Functional requirements will suggest the various outputs which are being produced from the given input.
2. Performance: There will be two types of performance requirements one is static and other is dynamic.
Static requirements examples: number of terminals or number of users which are to be supported which will not impose constraints on the execution behaviour of the system.Basics of use case
These are the general methods for describing the functional requirements
1. Use case will be textual description which will specify the behaviour in the usual manner followed by stakeholders or the clients to feel the familiarity of the system behaviour. Use cases which represent the behaviour requirement of the software system and this kind of behaviour specifications will gather most of the functional requirements of the software system which is being developed
Characteristics of Software requirement specifications: Following are the characteristics of a good SRS document:
1. Correctness: This will be the genuine requirements that will be part of SRS
2. Complete: software system will perform each and every functions as per the SRS
3. Unambiguous: which means not confusing, every requirement will be specified in the SRS which will have only one meaning.
4. Verifiable: this will do the cross verifying of the SRS which is understood by software
5. Consistent: which means stable due to the non-conflicting requirement
6. Modifiable: If necessary, changes can be made which doesn’t affect the consistency and also the completeness
7. Traceable: the origin of the requirement should be clear that the future assists verification and also validates.
All the characteristics will be desirable and the complete one since the addition or the deletion of the requirement at later stages of the software development which will be quite expensive and also the same job. This might happen due to missing of the requirement and requirement specifications from the client-side during requirement analysis activity at the initial stage.
characteristics of software requirment specifications are
1. Correctness: This will be the genuine requirements which will be the part of SRS
2. Complete: software system will perform each and every functions as per the SRS
3. Unambiguous: which means not confusing, every requirement will be specified in the SRS which will have only one meaning.
4. Verifiable: this will do the cross verifying of the SRS which is understood by software
5. Consistent: which means stable due to the non conflicting requirement
6. Modifiable: if necessary changes can be made which doesn’t affect the consistency and also the completeness
7. Traceable: origin of the requirement should be clear that the future assist verification and also validates.