Thursday, November 26, 2009
Difference between BRS and FRS
The main difference between brs and frs is that a brs tells the whole
requirement(story) whereas the frs tells the sequence of operations to
be perfored by a single process.
BRS is actually a document that covers the business aspect of a requirement on a broad level. For eg: lets consider that you want develop a new website. Your BRS would address what business is your website being built for. Lets say it is a website like ebay and it allows people to shop online. This would be your business requirement covered in the BRS.
Now the FRS would actually address each function that the website provides in order to make the shopping experience of the people visiting the website efficient and easy. Not just this it would also address issues of security etc that may need to be built into this wedsite.
Both the BR and FR can actually be addressed in the same document. However, this depends on the organization.
Both BRS and FRS are made by the BA who captures the requirements from the end user. A developer would be involved in making a technical document which would address the technical design of the website which the BA may or may not concern himself with.
requirement(story) whereas the frs tells the sequence of operations to
be perfored by a single process.
BRS is actually a document that covers the business aspect of a requirement on a broad level. For eg: lets consider that you want develop a new website. Your BRS would address what business is your website being built for. Lets say it is a website like ebay and it allows people to shop online. This would be your business requirement covered in the BRS.
Now the FRS would actually address each function that the website provides in order to make the shopping experience of the people visiting the website efficient and easy. Not just this it would also address issues of security etc that may need to be built into this wedsite.
Both the BR and FR can actually be addressed in the same document. However, this depends on the organization.
Both BRS and FRS are made by the BA who captures the requirements from the end user. A developer would be involved in making a technical document which would address the technical design of the website which the BA may or may not concern himself with.
Difference between SRS and FRS
Depending upon Function Requirements specifications(FRS)...... the software requirements specifications(SRS) will be built.
The Functional Requrements Specifications deals with the Client Requirements.
The Sofware Requirements Specifications deals with the Company resources.
The Functional Requrements Specifications deals with the Client Requirements.
The Sofware Requirements Specifications deals with the Company resources.
Functional testing
Functional Testing is a methodology under which Functionality testing is a type.
Ex. GUI testing is a type of Functional testing
Ex. GUI testing is a type of Functional testing
Difference between SRS and BRS
SRS is a Software /System Requirement specification it is a MS word doc. which defines the complete business functionalities of the particular application
SRS designed by System Anallyst
BRS is a Business Requirement Specification Initially client will give the req's in their own format then it will be converted in to Standard format by which s/w people can understand.
In BRS the req's are defined in general format. where as in SRS the req's will be divided in to modules and each module contains How many interfaces and screens like that
BRS is developed by Business Analyst
SRS designed by System Anallyst
BRS is a Business Requirement Specification Initially client will give the req's in their own format then it will be converted in to Standard format by which s/w people can understand.
In BRS the req's are defined in general format. where as in SRS the req's will be divided in to modules and each module contains How many interfaces and screens like that
BRS is developed by Business Analyst
System testing
System testing of software or hardware is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic. [1]
As a rule, system testing takes, as its input, all of the "integrated" software components that have successfully passed integration testing and also the software system itself integrated with any applicable hardware system(s). The purpose of integration testing is to detect any inconsistencies between the software units that are integrated together (called assemblages) or between any of the assemblages and the hardware. System testing is a more limiting type of testing; it seeks to detect defects both within the "inter-assemblages" and also within the system as a whole.
Testing the whole system
System testing is performed on the entire system in the context of a Functional Requirement Specification(s) (FRS) and/or a System Requirement Specification (SRS). System testing is an investigatory testing phase, where the focus is to have almost a destructive attitude and tests not only the design, but also the behaviour and even the believed expectations of the customer. It is also intended to test up to and beyond the bounds defined in the software/hardware requirements specification(s).
Types of system testing
The following examples are different types of testing that should be considered during System testing:
1. GUI software testing
2. Usability testing
3. Performance testing
4. Compatibility testing
5. Error handling testing
6. Load testing
7. Volume testing
8. Stress testing
9. User help testing
10. Security testing
11. Scalability testing
12. Capacity testing
13. Sanity testing
14. Smoke testing
15. Exploratory testing
16. Ad hoc testing
17. Regression testing
18. Reliability testing
19. Recovery testing
20. Installation testing
21. Idempotency testing
22. Maintenance testing
23. Recovery testing and failover testing.
24. Accessibility testing, including compliance with:
Americans with Disabilities Act of 1990
Section 508 Amendment to the Rehabilitation Act of 1973
Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C)
Although different testing organizations may prescribe different tests as part of System testing, this list serves as a general framework or foundation to begin with.
As a rule, system testing takes, as its input, all of the "integrated" software components that have successfully passed integration testing and also the software system itself integrated with any applicable hardware system(s). The purpose of integration testing is to detect any inconsistencies between the software units that are integrated together (called assemblages) or between any of the assemblages and the hardware. System testing is a more limiting type of testing; it seeks to detect defects both within the "inter-assemblages" and also within the system as a whole.
Testing the whole system
System testing is performed on the entire system in the context of a Functional Requirement Specification(s) (FRS) and/or a System Requirement Specification (SRS). System testing is an investigatory testing phase, where the focus is to have almost a destructive attitude and tests not only the design, but also the behaviour and even the believed expectations of the customer. It is also intended to test up to and beyond the bounds defined in the software/hardware requirements specification(s).
Types of system testing
The following examples are different types of testing that should be considered during System testing:
1. GUI software testing
2. Usability testing
3. Performance testing
4. Compatibility testing
5. Error handling testing
6. Load testing
7. Volume testing
8. Stress testing
9. User help testing
10. Security testing
11. Scalability testing
12. Capacity testing
13. Sanity testing
14. Smoke testing
15. Exploratory testing
16. Ad hoc testing
17. Regression testing
18. Reliability testing
19. Recovery testing
20. Installation testing
21. Idempotency testing
22. Maintenance testing
23. Recovery testing and failover testing.
24. Accessibility testing, including compliance with:
Americans with Disabilities Act of 1990
Section 508 Amendment to the Rehabilitation Act of 1973
Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C)
Although different testing organizations may prescribe different tests as part of System testing, this list serves as a general framework or foundation to begin with.
Friday, November 20, 2009
What is Baseline & configuration Management
Baseline:- Generally, a baseline may be a single work product, or set of work products that can be used as a logical basis for comparison
some times baseline can be the original requirements or specifications.
Configuration Management:-
configuration management is process of managing the changes in work product
and changes in documentation etc,
Configuration management is the process of managing change in hardware, software, firmware, documentation, measurements, etc. As change requires an initial state and next state, the marking of significant states within a series of several changes becomes important. The identification of significant states within the revision history of a configuration item is the central purpose of baseline identification.[1]
Typically, significant states are those that receive a formal approval status, either explicitly or implicitly (approval statuses may be marked individually, when such a marking has been defined, or signified merely by association to a certain baseline). Nevertheless, this approval status is usually recognized publicly. Thus, a baseline may also mark an approved configuration item, e.g. a project plan that has been signed off for execution. In a similar manner, associating multiple configuration items with such a baseline indicates those items as being approved.
Generally, a baseline may be a single work product, or set of work products that can be used as a logical basis for comparison. A baseline may also be established (whose work products meet certain criteria) as the basis for subsequent select activities. Such activities may be attributed with formal approval.
Conversely, the configuration of a project often includes one or more baselines, the status of the configuration, and any metrics collected. The current configuration refers to the current status, current audit, current metrics, and latest revision of all configuration items. Similarly, but less frequently, a baseline may refer to all items associated with a specific project. This may include all revisions of all items, or only the latest revision of all items in the project, depending upon context, e.g. "the baseline of the project is proceeding as planned."
A baseline may be specialized as a specific type of baseline.[2] Some examples include:
Functional Baseline: initial specifications established; contract, etc.
Allocated Baseline: state of work products once requirements are approved
Developmental Baseline: state of work products amid development
Product Baseline: contains the releasable contents of the project
some times baseline can be the original requirements or specifications.
Configuration Management:-
configuration management is process of managing the changes in work product
and changes in documentation etc,
Configuration management is the process of managing change in hardware, software, firmware, documentation, measurements, etc. As change requires an initial state and next state, the marking of significant states within a series of several changes becomes important. The identification of significant states within the revision history of a configuration item is the central purpose of baseline identification.[1]
Typically, significant states are those that receive a formal approval status, either explicitly or implicitly (approval statuses may be marked individually, when such a marking has been defined, or signified merely by association to a certain baseline). Nevertheless, this approval status is usually recognized publicly. Thus, a baseline may also mark an approved configuration item, e.g. a project plan that has been signed off for execution. In a similar manner, associating multiple configuration items with such a baseline indicates those items as being approved.
Generally, a baseline may be a single work product, or set of work products that can be used as a logical basis for comparison. A baseline may also be established (whose work products meet certain criteria) as the basis for subsequent select activities. Such activities may be attributed with formal approval.
Conversely, the configuration of a project often includes one or more baselines, the status of the configuration, and any metrics collected. The current configuration refers to the current status, current audit, current metrics, and latest revision of all configuration items. Similarly, but less frequently, a baseline may refer to all items associated with a specific project. This may include all revisions of all items, or only the latest revision of all items in the project, depending upon context, e.g. "the baseline of the project is proceeding as planned."
A baseline may be specialized as a specific type of baseline.[2] Some examples include:
Functional Baseline: initial specifications established; contract, etc.
Allocated Baseline: state of work products once requirements are approved
Developmental Baseline: state of work products amid development
Product Baseline: contains the releasable contents of the project
Subscribe to:
Posts (Atom)
