The following is a list of recommended requirements gathering practices. They are based on the author's extensive review of industry literature combined with the practical experiences of requirements analysts who have supported dozens of projects.
Understand a project vision and scope document.
Initiate a project glossary that provides definitions of words that are acceptable to and used by customers/users and the developers, and a list of acronyms to facilitate effective communication.
Evolve the real requirements via a "joint" customer/user and developer effort. Focus on product benefits (necessary requirements), not features. Address the minimum and highest priority requirements needed to meet real customer and user needs.
Document the rationale for each requirement (why it is needed).
Establish a mechanism to control changes to requirements and new requirements.
Prioritize the real requirements to determine those that should be met in the first release or product and those that can be addressed subsequently.
When the requirements are volatile (and perhaps even when they are not), consider an incremental development approach. This acknowledges that some of the requirements are "unknowable" until customers and users start using the system.
Use peer reviews and inspections of all requirements work products.
Use an industry-strength automated requirements tool.
Assign attributes to each requirement.
Provide traceability.
Maintain the history of each requirement.
Involve customers and users throughout the development effort.
Perform requirements validation and verification activities in the requirements gathering process to ensure that each requirement is testable.
Software Testing Training
Software testing institute
corporate training software testing
For More Visit Site
http://www.crestechsoftware.com/
For discussion FORUM
http://www.crestechsoftware.com/forum
Tuesday, June 10, 2008
Quality testing dashboard
Quality testing dashboard
The tool would gather information as test cases were created, as problem reports were entered, and as test cases were executed. The data would automatically be gathered into a database and online up to the second, and reporting would be available at all times.
Because the test management system fosters a structured test process, it can provide several reports and processes that would otherwise require extensive manual data collection, organization, analysis, and reporting.
Throughout the lifecycle of a project, the test management system can provide relevant status reporting to facilitate planning, test execution, results tracking, and release decisions.
1. During test development, reports are available to determine what work has been completed and what tasks remain open.
2. During execution, the test management system tracks scripts that have been executed and those that have not, the result of the execution of each script, and the requirements coverage achieved and links to defects reported due to failed test cases, to provide a complete view of the release readiness.
Reports just based on defect tracking data show incomplete status; for example, a report that there are ten open defects does not tell much, unless we know how many test cases have been executed and how much requirements coverage is achieved by these test cases. We can use test management data to generate this missing information. Test case metrics complement defect reports metrics and give a better view of product quality.
Apart from this, other reports can be generated based on different attributes like type of test, modules, etc. Test management can provide objective, accurate, real-time information, which is just what is needed for deciding on the quality of a product. This is the most important benefit of having a structured testing process and tool. Based on test reports available, the product manager can make informed decisions about the quality of the application under development.
Software Testing Training
Software testing institute
corporate training software testing
For More Visit Site
http://www.crestechsoftware.com/
For discussion FORUM
http://www.crestechsoftware.com/forum
The tool would gather information as test cases were created, as problem reports were entered, and as test cases were executed. The data would automatically be gathered into a database and online up to the second, and reporting would be available at all times.
Because the test management system fosters a structured test process, it can provide several reports and processes that would otherwise require extensive manual data collection, organization, analysis, and reporting.
Throughout the lifecycle of a project, the test management system can provide relevant status reporting to facilitate planning, test execution, results tracking, and release decisions.
1. During test development, reports are available to determine what work has been completed and what tasks remain open.
2. During execution, the test management system tracks scripts that have been executed and those that have not, the result of the execution of each script, and the requirements coverage achieved and links to defects reported due to failed test cases, to provide a complete view of the release readiness.
Reports just based on defect tracking data show incomplete status; for example, a report that there are ten open defects does not tell much, unless we know how many test cases have been executed and how much requirements coverage is achieved by these test cases. We can use test management data to generate this missing information. Test case metrics complement defect reports metrics and give a better view of product quality.
Apart from this, other reports can be generated based on different attributes like type of test, modules, etc. Test management can provide objective, accurate, real-time information, which is just what is needed for deciding on the quality of a product. This is the most important benefit of having a structured testing process and tool. Based on test reports available, the product manager can make informed decisions about the quality of the application under development.
Software Testing Training
Software testing institute
corporate training software testing
For More Visit Site
http://www.crestechsoftware.com/
For discussion FORUM
http://www.crestechsoftware.com/forum
Preferred Requirements Gathering Techniques - Risk Analysis 5
Risk Assessment for Projects
At least 50% of all projects (if not much more) are not successful in the sense that they do not achieve their objectives, or do not deliver the promised results, or sacrifice the predefined quality, or are not completed in the given time schedule, or use much more resources than originally planned.
There is a multitude of reasons for projects to fail. Projects often come on top of the usual work load and members of the project team belong to different departments, i.e. they have their first accountability to their line manager which often brings them into conflict with the project work. Team members have to work overtime if they want to complete their project tasks. At the end, project work is often sacrificed, and time budgets are often not sufficient.
What is mostly neglected: the occurrence of problems in project implementation increases with the complexity and length of the project.Larger and more complex projects that run over more than a year have other reasons of failure. Often these projects have permanent staff who are released from other tasks and work full time on the project, and well established budgets. However, those projects depend on a large number of external assumptions which influence their outcomes. It is impossible to clearly predict the future and the impact of various influence factors that are uncertain. Many project plans are too rigid to flexibly respond to changing needs.
Common to most projects is the lack of appropriate and transparent communication. Team members (and other stakeholders) often do not share a common understanding of the project's goals and strategies. It is important to unveil these misunderstandings and hidden agendas from the very beginning. The following tool, if applied in a project planning session helps to uncover issues that otherwise might remain undiscussed.
Explanations:
Business Level: Does the project have a strategic importance for the organization?
Length: How long is the intended implementation time?
Complexity: Does the project cover various business areas / objectives?
Technology: Is the technology to be applied well-established or is it a technology which yet has to be developed?
Number of organizational units involved: cross functional / geographical areas, etc.
Costs: estimated costs of the project
Overall risk of failure: How would you personally rank the risk that the project cannot achieve the objectives with the intended resources?
Software Testing Training
Software testing institute
corporate training software testing
For More Visit Site
http://www.crestechsoftware.com/
For discussion FORUM
http://www.crestechsoftware.com/forum
At least 50% of all projects (if not much more) are not successful in the sense that they do not achieve their objectives, or do not deliver the promised results, or sacrifice the predefined quality, or are not completed in the given time schedule, or use much more resources than originally planned.
There is a multitude of reasons for projects to fail. Projects often come on top of the usual work load and members of the project team belong to different departments, i.e. they have their first accountability to their line manager which often brings them into conflict with the project work. Team members have to work overtime if they want to complete their project tasks. At the end, project work is often sacrificed, and time budgets are often not sufficient.
What is mostly neglected: the occurrence of problems in project implementation increases with the complexity and length of the project.Larger and more complex projects that run over more than a year have other reasons of failure. Often these projects have permanent staff who are released from other tasks and work full time on the project, and well established budgets. However, those projects depend on a large number of external assumptions which influence their outcomes. It is impossible to clearly predict the future and the impact of various influence factors that are uncertain. Many project plans are too rigid to flexibly respond to changing needs.
Common to most projects is the lack of appropriate and transparent communication. Team members (and other stakeholders) often do not share a common understanding of the project's goals and strategies. It is important to unveil these misunderstandings and hidden agendas from the very beginning. The following tool, if applied in a project planning session helps to uncover issues that otherwise might remain undiscussed.
Explanations:
Business Level: Does the project have a strategic importance for the organization?
Length: How long is the intended implementation time?
Complexity: Does the project cover various business areas / objectives?
Technology: Is the technology to be applied well-established or is it a technology which yet has to be developed?
Number of organizational units involved: cross functional / geographical areas, etc.
Costs: estimated costs of the project
Overall risk of failure: How would you personally rank the risk that the project cannot achieve the objectives with the intended resources?
Software Testing Training
Software testing institute
corporate training software testing
For More Visit Site
http://www.crestechsoftware.com/
For discussion FORUM
http://www.crestechsoftware.com/forum
Preferred Requirements Gathering Techniques - 5
Effort Estimation
Effort estimation consists in predict how many hours of work and how many workers are needed to develop a project. The effort invested in a software project is probably one of the most important and most analysed variables in recent years in the process of project management. The determination of the value of this variable when initiating software projects allows us to plan adequately any forthcoming activities. As far as estimation and prediction is concerned there is still a number of unsolved problems and errors. To obtain good results it is essential to take into consideration any previous projects. Estimating the effort with a high grade of reliability is a problem which has not yet been solved and even the project manager has to deal with it since the beginning.
Cost Estimation
It is the responsibility of the project manager to make accurate estimations of effort and cost. This is particularly true for projects subject to competitive bidding where a bid too high compared with competitors would result in loosing the contract or a bid too low could result in a loss to the organisation . This does not mean that internal projects are unimportant. From a project leaders estimate the management often decide whether to proceed with the project. Industry has a need for accurate estimates of effort and size at a very early stage in a project. However, when software cost estimates are done early in the software development process the estimate can be based on wrong or incomplete requirements. A software cost estimate process is the set of techniques and procedures that an organisation use to arrive at an estimate. An important aspect of software projects is to know the cost, The major contributing factor is effort.
Why SCE is difficult and error prone ?
Software cost estimation requires a significant amount of effort to perform it correctly.
SCE is often done hurriedly, without an appreciation for the effort required.
You need experience at developing estimates, especially for large projects.
Human bias i.e An Estimator is likely to consider how long a certain portion of the system would take, and then to merely extrapolate this estimate to the rest of the system, ignoring the non-linear aspects of software development.
The causes of poor and inaccurate estimation
imprecise and drifting requirements
new software projects are nearly always different form the last.
software practitioners don't collect enough information about past projects.
estimates are forced to match the resources available.
Software Testing Training
Software testing institute
corporate training software testing
For More Visit Site
http://www.crestechsoftware.com/
For discussion FORUM
http://www.crestechsoftware.com/forum
Effort estimation consists in predict how many hours of work and how many workers are needed to develop a project. The effort invested in a software project is probably one of the most important and most analysed variables in recent years in the process of project management. The determination of the value of this variable when initiating software projects allows us to plan adequately any forthcoming activities. As far as estimation and prediction is concerned there is still a number of unsolved problems and errors. To obtain good results it is essential to take into consideration any previous projects. Estimating the effort with a high grade of reliability is a problem which has not yet been solved and even the project manager has to deal with it since the beginning.
Cost Estimation
It is the responsibility of the project manager to make accurate estimations of effort and cost. This is particularly true for projects subject to competitive bidding where a bid too high compared with competitors would result in loosing the contract or a bid too low could result in a loss to the organisation . This does not mean that internal projects are unimportant. From a project leaders estimate the management often decide whether to proceed with the project. Industry has a need for accurate estimates of effort and size at a very early stage in a project. However, when software cost estimates are done early in the software development process the estimate can be based on wrong or incomplete requirements. A software cost estimate process is the set of techniques and procedures that an organisation use to arrive at an estimate. An important aspect of software projects is to know the cost, The major contributing factor is effort.
Why SCE is difficult and error prone ?
Software cost estimation requires a significant amount of effort to perform it correctly.
SCE is often done hurriedly, without an appreciation for the effort required.
You need experience at developing estimates, especially for large projects.
Human bias i.e An Estimator is likely to consider how long a certain portion of the system would take, and then to merely extrapolate this estimate to the rest of the system, ignoring the non-linear aspects of software development.
The causes of poor and inaccurate estimation
imprecise and drifting requirements
new software projects are nearly always different form the last.
software practitioners don't collect enough information about past projects.
estimates are forced to match the resources available.
Software Testing Training
Software testing institute
corporate training software testing
For More Visit Site
http://www.crestechsoftware.com/
For discussion FORUM
http://www.crestechsoftware.com/forum
Preferred Requirements Gathering Techniques - 4
Effort Estimation
Effort estimation consists in predict how many hours of work and how many workers are needed to develop a project. The effort invested in a software project is probably one of the most important and most analysed variables in recent years in the process of project management. The determination of the value of this variable when initiating software projects allows us to plan adequately any forthcoming activities. As far as estimation and prediction is concerned there is still a number of unsolved problems and errors. To obtain good results it is essential to take into consideration any previous projects. Estimating the effort with a high grade of reliability is a problem which has not yet been solved and even the project manager has to deal with it since the beginning.
Cost Estimation
It is the responsibility of the project manager to make accurate estimations of effort and cost. This is particularly true for projects subject to competitive bidding where a bid too high compared with competitors would result in loosing the contract or a bid too low could result in a loss to the organisation . This does not mean that internal projects are unimportant. From a project leaders estimate the management often decide whether to proceed with the project. Industry has a need for accurate estimates of effort and size at a very early stage in a project. However, when software cost estimates are done early in the software development process the estimate can be based on wrong or incomplete requirements. A software cost estimate process is the set of techniques and procedures that an organisation use to arrive at an estimate. An important aspect of software projects is to know the cost, The major contributing factor is effort.
Why SCE is difficult and error prone ?
Software cost estimation requires a significant amount of effort to perform it correctly.
SCE is often done hurriedly, without an appreciation for the effort required.
You need experience at developing estimates, especially for large projects.
Human bias i.e An Estimator is likely to consider how long a certain portion of the system would take, and then to merely extrapolate this estimate to the rest of the system, ignoring the non-linear aspects of software development.
The causes of poor and inaccurate estimation
imprecise and drifting requirements
new software projects are nearly always different form the last.
software practitioners don't collect enough information about past projects.
estimates are forced to match the resources available.
Software Testing Training
Software testing institute
corporate training software testing
For More Visit Site
http://www.crestechsoftware.com/
For discussion FORUM
http://www.crestechsoftware.com/forum
Effort estimation consists in predict how many hours of work and how many workers are needed to develop a project. The effort invested in a software project is probably one of the most important and most analysed variables in recent years in the process of project management. The determination of the value of this variable when initiating software projects allows us to plan adequately any forthcoming activities. As far as estimation and prediction is concerned there is still a number of unsolved problems and errors. To obtain good results it is essential to take into consideration any previous projects. Estimating the effort with a high grade of reliability is a problem which has not yet been solved and even the project manager has to deal with it since the beginning.
Cost Estimation
It is the responsibility of the project manager to make accurate estimations of effort and cost. This is particularly true for projects subject to competitive bidding where a bid too high compared with competitors would result in loosing the contract or a bid too low could result in a loss to the organisation . This does not mean that internal projects are unimportant. From a project leaders estimate the management often decide whether to proceed with the project. Industry has a need for accurate estimates of effort and size at a very early stage in a project. However, when software cost estimates are done early in the software development process the estimate can be based on wrong or incomplete requirements. A software cost estimate process is the set of techniques and procedures that an organisation use to arrive at an estimate. An important aspect of software projects is to know the cost, The major contributing factor is effort.
Why SCE is difficult and error prone ?
Software cost estimation requires a significant amount of effort to perform it correctly.
SCE is often done hurriedly, without an appreciation for the effort required.
You need experience at developing estimates, especially for large projects.
Human bias i.e An Estimator is likely to consider how long a certain portion of the system would take, and then to merely extrapolate this estimate to the rest of the system, ignoring the non-linear aspects of software development.
The causes of poor and inaccurate estimation
imprecise and drifting requirements
new software projects are nearly always different form the last.
software practitioners don't collect enough information about past projects.
estimates are forced to match the resources available.
Software Testing Training
Software testing institute
corporate training software testing
For More Visit Site
http://www.crestechsoftware.com/
For discussion FORUM
http://www.crestechsoftware.com/forum
Preferred Requirements Gathering Techniques - 3
Interfaces Analysis.
Missing or incorrect interfaces are often a major cause of cost overruns and product failures. Identifying external interfaces early clarifies product scope, aids risk assessment, reduces product development costs, and improves customer satisfaction. The steps of identifying, simplifying, controlling, documenting, communicating, and monitoring interfaces help to reduce the risk of problems related to interfaces.
Please see attached Requirement Analysis Template
b) The feasibility Study
The Feasibility Study uses technical information and cost data to determine the economic potential and practicality (i.e. feasibility) of a project. The Feasibility Study uses techniques that help evaluate a project and/or compare it with other projects. Factors such as interest rates, operating costs, and depreciation are generally considered. The following questions are answered during feasibility study
An abstract definition of problem
Formulation of different Solution strategy
Examination of alternative solution strategy (in terms of benefits, Resource requirement, costs etc)
Cost and benefit analysis to determine the best strategy
Who uses it?
Technical Architect, Business Analyst, Configuration Manager, Development Manager, Project Manager, IT Manager, System Administrator, Test Manager, Documentation Manager, Technical Writers, System Administrator.
When is it used?
The Feasibility Study analyses potential solutions against a set of requirements, evaluates their ability to meet these objectives, describe a recommended solution, and offer a justification for this selection.
c) Project Planning
When a project is estimated to be feasible, project planning is done. Project planning consist of the following steps
Effort, Cost, Resource and Project Duration planning
Risk Analysis and mitigation plan
Project Scheduling
Staffing organization and Staffing Plan
Software Testing Training
Software testing institute
corporate training software testing
For More Visit Site
http://www.crestechsoftware.com/
For discussion FORUM
http://www.crestechsoftware.com/forum
Missing or incorrect interfaces are often a major cause of cost overruns and product failures. Identifying external interfaces early clarifies product scope, aids risk assessment, reduces product development costs, and improves customer satisfaction. The steps of identifying, simplifying, controlling, documenting, communicating, and monitoring interfaces help to reduce the risk of problems related to interfaces.
Please see attached Requirement Analysis Template
b) The feasibility Study
The Feasibility Study uses technical information and cost data to determine the economic potential and practicality (i.e. feasibility) of a project. The Feasibility Study uses techniques that help evaluate a project and/or compare it with other projects. Factors such as interest rates, operating costs, and depreciation are generally considered. The following questions are answered during feasibility study
An abstract definition of problem
Formulation of different Solution strategy
Examination of alternative solution strategy (in terms of benefits, Resource requirement, costs etc)
Cost and benefit analysis to determine the best strategy
Who uses it?
Technical Architect, Business Analyst, Configuration Manager, Development Manager, Project Manager, IT Manager, System Administrator, Test Manager, Documentation Manager, Technical Writers, System Administrator.
When is it used?
The Feasibility Study analyses potential solutions against a set of requirements, evaluates their ability to meet these objectives, describe a recommended solution, and offer a justification for this selection.
c) Project Planning
When a project is estimated to be feasible, project planning is done. Project planning consist of the following steps
Effort, Cost, Resource and Project Duration planning
Risk Analysis and mitigation plan
Project Scheduling
Staffing organization and Staffing Plan
Software Testing Training
Software testing institute
corporate training software testing
For More Visit Site
http://www.crestechsoftware.com/
For discussion FORUM
http://www.crestechsoftware.com/forum
Preferred Requirements Gathering Techniques - 2
Prototyping.
Prototyping is a technique for building a quick and rough version of a desired system or parts of that system. The prototype illustrates the capabilities of the system to users and designers. It serves as a communications mechanism to allow reviewers to understand interactions with the system. Prototyping sometimes gives an impression that developers are further along than is actually the case, giving users an overly optimistic impression of completion possibilities. Prototypes can be combined effectively with other approaches such as JAD and models.
Use Cases.
A use case is a picture of actions a system performs, depicting the actors. It should be accompanied by a textual description and not be used in isolation of other requirements gathering techniques. Use cases should always be supplemented with quality attributes and other information such as interface characteristics. Many developers believe that use cases and scenarios (descriptions of sequences of events) facilitate team communication. They provide a context for the requirements by expressing sequences of events and a common language for end users and the technical team.
Be cautioned that use cases alone do not provide enough information to enable development activities. Other requirements elicitation techniques should also be used in conjunction with use cases. Use operational concepts as a simple, cost-effective way to build a consensus among stakeholders and to address two large classes of requirements errors: omitted requirements and conflicting requirements. Operational concepts identify user interface issues early, provide opportunities for early validation, and form a foundation for testing scenarios in product verification.
Software Testing Training
Software testing institute
corporate training software testing
For More Visit Site
http://www.crestechsoftware.com/
For discussion FORUM
http://www.crestechsoftware.com/forum
Prototyping is a technique for building a quick and rough version of a desired system or parts of that system. The prototype illustrates the capabilities of the system to users and designers. It serves as a communications mechanism to allow reviewers to understand interactions with the system. Prototyping sometimes gives an impression that developers are further along than is actually the case, giving users an overly optimistic impression of completion possibilities. Prototypes can be combined effectively with other approaches such as JAD and models.
Use Cases.
A use case is a picture of actions a system performs, depicting the actors. It should be accompanied by a textual description and not be used in isolation of other requirements gathering techniques. Use cases should always be supplemented with quality attributes and other information such as interface characteristics. Many developers believe that use cases and scenarios (descriptions of sequences of events) facilitate team communication. They provide a context for the requirements by expressing sequences of events and a common language for end users and the technical team.
Be cautioned that use cases alone do not provide enough information to enable development activities. Other requirements elicitation techniques should also be used in conjunction with use cases. Use operational concepts as a simple, cost-effective way to build a consensus among stakeholders and to address two large classes of requirements errors: omitted requirements and conflicting requirements. Operational concepts identify user interface issues early, provide opportunities for early validation, and form a foundation for testing scenarios in product verification.
Software Testing Training
Software testing institute
corporate training software testing
For More Visit Site
http://www.crestechsoftware.com/
For discussion FORUM
http://www.crestechsoftware.com/forum
Subscribe to:
Posts (Atom)