ISO 15504 - 'Embedded Systems' - Software Requirements vs. System Requirements

[sujoy]

Hi,

When describing the "system" requirements for an embedded system, the functionalities which are to be provided by software are also described. However, ISO 15504 asks for a separate software requirements also. How will the software requirements differ from those described in the system requirements?


Regards,
Sujoy

[Marc]

Anyone knowledgeable on this topic?

[RobDavisPE]

Originally Posted by sujoy

Hi, When describing the "system" requirements for an embedded system, the functionalities which are to be provided by software are also described. However, ISO 15504 asks for a separate software requirements also. How will the software requirements differ from those described in the system requirements?
Regards, Sujoy

ISO 15504 (also known as SPICE, i.e. Software Process Improvement and Capability Determination) is a framework for the assessment of software processes. It was developed by the International Organization for Standardization (ISO). ISO 15504 can be used in two contexts: process improvement, and supplier evaluation.

To answer your question, having a separate set of software requirements is usually not an issue at most companies. If it appears to be an issue, and especially if your company uses ISO 15504, then you want to ask management that under ISO 15504 allow you to spend time to develop a list of software requirements (in addition to system requirements).

"Separate" does not and should not mean any new conflict or any new contradiction. Just because ISO 15504 asks for separate software requirements, systems requirements are NOT going to and should not contradict any of your software requirements.

Additionally, because systems engineers usually take a high-level approach, it is unlikely that the (low-level) software requirements under ISO 15504 are going to contradict any (high level) system requirements.

In the unlikely event there's a conflict, it can be brought to a meeting and negotiated. Just because ISO 15504 asks for separate software requirements, (high-level) systems requirements should not contradict any of your (low-level) software requirements.

I hope this helps.

Regards,

Rob
Software QA Engineer

[Paul Mc]

Originally Posted by RobDavisPE

ISO 15504 (also known as SPICE, i.e. Software Process Improvement and Capability Determination) is a framework for the assessment of software processes. It was developed by the International Organization for Standardization (ISO). ISO 15504 can be used in two contexts: process improvement, and supplier evaluation.

To answer your question, having a separate set of software requirements is usually not an issue at most companies. If it appears to be an issue, and especially if your company uses ISO 15504, then you want to ask management that under ISO 15504 allow you to spend time to develop a list of software requirements (in addition to system requirements).

"Separate" does not and should not mean any new conflict or any new contradiction. Just because ISO 15504 asks for separate software requirements, systems requirements are NOT going to and should not contradict any of your software requirements.

Additionally, because systems engineers usually take a high-level approach, it is unlikely that the (low-level) software requirements under ISO 15504 are going to contradict any (high level) system requirements.

In the unlikely event there's a conflict, it can be brought to a meeting and negotiated. Just because ISO 15504 asks for separate software requirements, (high-level) systems requirements should not contradict any of your (low-level) software requirements.

I hope this helps.

Regards,

Rob
Software QA Engineer

is a framework for the assessment of software processes.

Hi Rob,
it's been "recommended" by am OEM that we should go for this accreditation, for process improvement, though we know very little about it! a couple of questions:
1. do you need to be a software guru to audit against it?
2. how long to implement? we're a Tier1 auto electonics co. ~420employees with ~ 50 R&D engineers
3. Main tangible benefits you have found?
4. any pitfalls to watch out for?

[Paul Mc]

Has anybody any experience in implementing this software standard within the automotive supply industry??