CODEWITHSUNDEEP
documentationverification
John V
John V

Reputation: 5047

Requirement, design, code derivation

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:

  1. User equirement: I want to be save my friend's name, address and phone number to the system
  2. Software Requirement specification: User wants to be able to enter and save a name, address, phone number.
  3. Technical analysis: web UI for data entering. Data will be saved into the SQL DB.
  4. Detailed design: UI elements: 3 fields of a string type, 1 button, object XYZ, dbConnection....
  5. 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).

Upvotes: 0

Views: 89

Answers (2)

Aravind Yarram
Aravind Yarram

Reputation: 80166

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 want to be save my friend's name, address and phone number to the system...

I'd rather like to have the below which emphasizes Why? the real need of the user

I want to send a greeting card to my friend on his birthday.

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

Upvotes: 1

Augusto
Augusto

Reputation: 29827

I've never seen a good way to trace code to requirements outside a single sprint/time box. And also, you're missing testers from your list! Unless your testers are also your business analysts (I my experience professional testers find a lot of the requirements inconsistencies - aka bugs).

I think the best approach is to have everyone as involved as possible, so you can cross reference each person expectations often. If everyone works together, you don't need to implement a cargo-cult process where batches of information are transferred down stream in one way.

The simplest tool have traceability is your VCS, where each commit includes the ID of the user story/use case that the commit is related to.

Upvotes: 0

Related Questions