Home > Archive > Software Engineering > May 2006 > requirement validation in sw
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
requirement validation in sw
|
|
| puzzlecracker 2006-05-03, 7:04 pm |
| How do you validate a product against the requirements? What kind of
the techniques used to guarantee that the final system is in line with
the requirements specifications above.
need to that for an employers and never done it before, suggestions
,examples, explanations appreciated. thx
| |
| H. S. Lahman 2006-05-03, 7:04 pm |
| Responding to Puzzlecracker...
> How do you validate a product against the requirements? What kind of
> the techniques used to guarantee that the final system is in line with
> the requirements specifications above.
The short answer is: Testing. However, there are all sorts of ways to
test things besides executing the application. Specification reviews,
documentation reviews, code reviews, model reviews, and any other sort
of intermediate work product review are essentially tests against
requirements.
How to do each of those is material for an entire book. In addition,
beyond testing there is conformance to process. Shops have formal
processes to, among other things, reduce errors by preventing defects
from entering the product. So ensuring that those processes were
carried out properly is also a mechanism for validating the
requirements, albeit indirectly.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH
| |
| carlosrf82 2006-05-03, 7:04 pm |
| Well,
There are two mainly way to validate requirement.
Prototype: You make a prototype of the product and present this to the
client, and the client tell you that it is what he wants.
Review: You review your document of requirement to find an
inconsitencies. There are tecnics to help you, like separate in
categories the requirement, like that the client sign a document
recognizing that it is validated, etc...
This info i have get in the book "Software Engineering (Somerville)"
and in SWEBOK (IEEE Computer Society). You can get the last book in pdf
format freely in www.swebok.org
| |
| Ananth the Boss 2006-05-07, 10:05 pm |
| a tool is just a tool.only we stakeholders have thorough idea of
problem.the tool serves as tracker of requirements.it all depends on
how efficiently we feed the rqmts to the tool&how better we map the
software requirements with the stakeholder rqmts or the product
requirements.
| |
| Suyash Agnihotri 2006-05-07, 10:05 pm |
| I agree with the first part. PROTOTYPES / PROOF OF CONCEPT can be used
for Validating the requirements. Even acceptance testing will be kind
of validation activity.
In simpler words where ever customer is involved (even in approvals of
SRS) it is Validation.
Whereas REVIEW is more kind of internal activity, which will fall in
VERIFICATION.
-suyash
| |
| David Lightstone 2006-05-07, 10:05 pm |
|
"Suyash Agnihotri" <suyash.agnihotri@gmail.com> wrote in message
news:1146824884.222730.38430@u72g2000cwu.googlegroups.com...
>I agree with the first part. PROTOTYPES / PROOF OF CONCEPT can be used
> for Validating the requirements. Even acceptance testing will be kind
> of validation activity.
>
> In simpler words where ever customer is involved (even in approvals of
> SRS) it is Validation.
Of what?
Prototype "validates" a concept
Acceptance "validates" completion of the development effort
The requirements are validated many times against many criteria.
>
> Whereas REVIEW is more kind of internal activity, which will fall in
> VERIFICATION.
>
> -suyash
>
| |
| James Bond 007 2006-05-07, 10:05 pm |
|
"Ananth the Boss" <anboss@gmail.com> wrote in message =
news:1146815824.664615.221540@j33g2000cwa.googlegroups.com...
>a tool is just a tool.only we stakeholders have thorough idea of
> problem.the tool serves as tracker of requirements.it all depends on
> how efficiently we feed the rqmts to the tool&how better we map the
> software requirements with the stakeholder rqmts or the product
> requirements.
>
I wouldn't trust anyone to validate my requirements, test my software, =
or give me advice on such matters who has such poor grammar. Capitalize =
your sentences and separate them properly. A run-on paragraph with no =
capitalization and one period at the end is very poor English grammar =
indeed.
| |
| Andrew Gabb 2006-05-07, 10:05 pm |
| puzzlecracker wrote:
> How do you validate a product against the requirements? What kind of
> the techniques used to guarantee that the final system is in line with
> the requirements specifications above.
You don't normally validate a product against written requirements.
If you mean against a spec, then this is technically verification,
not validation.
As other have implied, validation checks that the product will meet
the users' current needs, which means you need to know how the users
will use it, and what they need from the product. The specifications
should reflect this, but only in part.
Obviously you need to know a lot about the users to do validation,
and much of the validation is typically done by the users
themselves. As a guide, an opconcept or conops can help, but this is
only in part - if you don't understand how and why the product
will be used, you might as well forget validation.
FWIW, while testing is a major activity in verification, it's a not
a big issue in validation.
Andrew
--
Andrew Gabb
email: agabb@tpgi.com.au Adelaide, South Australia
phone: +61 8 8342-1021, fax: +61 8 8269-3280
-----
| |
| keith.mann@gmail.com 2006-05-09, 7:04 pm |
| The short answer: user acceptance testing. The users are the only
people who can tell you whether *your* product matches *their*
requirements. No matter how long you spend on up-front requirements
(and longer is in fact rarely better), their vision of the software is
going to be different from yours. The best way to mitigate the pain is
to start giving the users software to UAT as early as possible. Develop
iteratively, as they say.
|
|
|
|
|