View
219
Download
1
Category
Preview:
Citation preview
Testing RequirementsTesting Requirements
What are the requirements
for a ripe apple?
Testing RequirementsTesting Requirements
Make them measurableMake them quantifiableHow to quantify non-quantifiable onesOnes not possible to quantify
Quality MeasureQuality Measure
Each requirement must have a quality measure that can be tested to see if the solution meets the requirement
How to Do ThisHow to Do This - Keep - Keep TrackTrack
Define all criteria for measuring the goodness of the solutionDescription of requirement – one sentence
Purpose of requirement – why it is important?
Owner(s) – who wants this requirement?
Quality Measure – unambiguous test for measuring whether the solution meets the requirement
Value – Customer value 1 (bells) to 10 (essential)
Type – Functional or non-functional?
Unique Identifier – tag for tracking the requirement
Dependency – existence/change dependencies on the requirements
Consistency - CoherencyConsistency - Coherency
Requirements must be understood by anyone who reads them
Measurement of the requirements must be easily understood
Specification ClaritySpecification Clarity
Does the specification contain a definition of the meaning of every essential term?
If I specify “user” what does that mean?
I need to specify all the details that describe “user” as part of the definition.
CompletenessCompleteness
Does the context of the system cover everything that you need to understand for the system?
Problems that the new system creates? Solves?
Is there a requirement that we don’t know about because we don’t know it’s possible?
Stakeholders’ OptionsStakeholders’ Options
Have they been asked about the completeness of the requirements?
Compare requirements of new system to that of the old system.
RelevanceRelevance
Many requirements that are suggested may not be relevant to the new system – the goal of the system.
Personal bias for wants may enter into the picture.
Check the stated requirements against the goal to determine relevancy.
Failure vs. SuccessFailure vs. Success
Bad system performance = aggravation Good system performance = happiness Not meeting requirements = failure Use a Likert scale to judge performance (1 to 5)
If necessary but missing = 5 point penalty or 5 point reward if there
If nice to have but not critical = 3 point reward And so forth.. Sum up the numbers = design priorities
This knowledge determines the priorities in the design of the system and where trade-offs should be made
TraceabilityTraceability
Need to identify each requirement and follow its progress through the system creation
Should be able to map the requirement to the solution in the end for testing
ConnectionsConnections
After considering each requirement as unique, you must examine the connections between each requirement
Event/Use cases are a good way of doing this
Requirements SpecificationRequirements Specification
The requirements specification should contain all requirements that are to be solved by the system
As soon as we have one requirement we can begin our requirements testing.
This method eliminates most of the cost of reworking a project
When you have met success When you have met success with the requirements testing with the requirements testing then you are ready to eat the then you are ready to eat the
sweet apples sweet apples
Recommended