I am following verification and validation threads and I think an example might be helpful. I am not an experienced developer so I would like to know whether this would be correct:
- User equirement: I want to be save my friend’s name, address and phone number to the system
- Software Requirement specification: User wants to be able to enter and save a name, address, phone number.
- Technical analysis: web UI for data entering. Data will be saved into the SQL DB.
- Detailed design: UI elements: 3 fields of a string type, 1 button, object XYZ, dbConnection….
- Code: (actual code of UI, db scripts)
Is it like that? Could anyone correct or add what I am missing here?
As for verification, each phase can be verified against requirement (traceability). As for validation, the functional code should work as expected (save three attributes).
While this is some what theoretically true (I have to say this), it is completely wrong in all practical and real world scenarios.
Capture user needs and Why he wants to do a certain thing. This allows you to build just the software that user wants, eliminate waste that come as part of made-up requirements, technical requirements, nice to haves etc.
So instead of,
I’d rather like to have the below which emphasizes Why? the real need of the user
Now, I know I just need his name and address. Since this is for future I also want to store this information. So what I write next is a set of acceptance criteria to meet the above customer needs. If I can capture these as a set of executable specifications then it is even better as those are verifiable programmatically.
Ignore everything else. Traceability is unnecessary overhead. We need it if we are building software based on fabricated requirements.
Read the below