ISO 62304 - Software requirements content

[tazer]

Hi all,
This is my first message in the board.
I am relying on your indulgence.

In my team, we had a discussion on paragraph 5.2.2.
In this paragraph it is written: "...` shall include in the software requirements: a) ... i) ... ".
2 positions emerged:
1 / in the SRS we must determine for each requirement its category (a, b, ..., i). Then the requirement must be writen as four columns:
"ID" "Title" "Description" "Requirement Content"

2 / This is only a description of the requirements that must be integrated into the SRS. Then the requirement must be writen as only 3 columns:
"ID" "Title" "Description"

In both cases, a paper Requirement_Traceability_Matrix ensures traceability between SRSID, riskID, VV ....

What is your opinion on the question?

 

[mihzago]

The standard does not specify how a requirement should be described; however the requirement must be complete, unambiguous, unique (not conflicting), and testable.

ID helps with traceability. Title isn't really needed, but is probably useful when searching or browsing requirements. Not sure what's the different between the "description" and "requirement content"; I assume it's some additional narrative describing the purpose or a rationale for a requirement. Certainly helpful, but I wouldn't say a must.

 

[yodon]

In my team, we had a discussion on paragraph 5.2.2.
In this paragraph it is written: "...` shall include in the software requirements: a) ... i) ... ".

Good response from mihzago. I'd like to add that the paragraph you're citing starts with "As appropriate..." so the intent, I believe, is to ensure that you have considered all those requirements types, not so much that you necessarily have all those categories (if not applicable).

And the standard doesn't require that you have a *separate* software requirements document. I've seen cases where the software requirements are included in system requirements and identified through special tags / attributes.

 

[tazer]

Thank you both for your answers.
I also agree with mihzago.

And the standard doesn't require that you have a *separate* software requirements document. I've seen cases where the software requirements are included in system requirements and identified through special tags / attributes.

Exact, but in our case, the system is broken down into several sub systems that have their own documentation.