Thank you for the elaborate explanation. I had a question in terms of specifying a requirement as a relationship between the inputs and outputs of a function. Many times, the relationship is not straight forward and we would need to define some intermediate signals to connect the inputs and outputs together. My question is whether it is ok to write requirements for these intermediate signals in the SRS? If yes, what impact does this have on the SWE.6 qualification tests?
@Narayan Narvekar thank you for your question! You are right. Sometimes you need to cover complex functions by using intermediate signals. In our opinion, there are two ways of dealing with this: 1. If these signals are visible outside of the software you should add requirements. 2. If these are internal signals only, they are likely part of the solution and should not be documented as a requirement but rather as part of architecture. We hope this helps you further! :)
How I ask the difference between feasibility and technical implication? In my opinion, feasibility might already include if a technical solution is feasible?
@Hui Jin Your assumption is correct. The check on feasibility checks on technical, but also managerial implications of a technical solutions. Please keep in mind that any doubts about the feasibility are a risk and should be tracked accordingly. We hope this answers your question!
Hi Davide, thank you for your comment, we are glad that you appreciate the video. We checked the link, it seems that it works correctly.... here you can download the whitepaper for free: www.kuglermaag.com/fileadmin/05_CONTENT_PDF/05_WHITEPAPER/whitepaper_automotive-spice_en_swe1_software-requirements-analysis.pdf
Hi, for me the descriptions of sys2 and swe1 are too similar. In general I don't understand where the difference between system and software lies. Especially if the product is software only
Hi Marcos, I understand your point, but if you check the processes you will see that they are very similar. In most cases the term "system" was exchanged by "software", so it is not surprising that the presentation of the standard does not show a lot of difference. However, looking at the implementation of the processes, you have to approach them differently. For SYS.2 you are looking at the system as a black box and define requirements. For SWE.1, it is the software only which is a black box. In some systems there is not a lot of difference, but for instance in ADAS systems, where camera input is preprocessed by FPGAs or ASICs, there is a big difference between system and software requirements. In your case, if there is software development only you can skip the system-level processes. Actually, note 2 in SWE.1BP1 reflects that. I hope this helps. If not, feel free to contact us. Kind regards Bhaskar
Thank you for the elaborate explanation. I had a question in terms of specifying a requirement as a relationship between the inputs and outputs of a function. Many times, the relationship is not straight forward and we would need to define some intermediate signals to connect the inputs and outputs together. My question is whether it is ok to write requirements for these intermediate signals in the SRS? If yes, what impact does this have on the SWE.6 qualification tests?
@Narayan Narvekar thank you for your question! You are right. Sometimes you need to cover complex functions by using intermediate signals. In our opinion, there are two ways of dealing with this:
1. If these signals are visible outside of the software you should add requirements.
2. If these are internal signals only, they are likely part of the solution and should not be documented as a requirement but rather as part of architecture.
We hope this helps you further! :)
How I ask the difference between feasibility and technical implication? In my opinion, feasibility might already include if a technical solution is feasible?
@Hui Jin Your assumption is correct. The check on feasibility checks on technical, but also managerial implications of a technical solutions. Please keep in mind that any doubts about the feasibility are a risk and should be tracked accordingly. We hope this answers your question!
very good explanation, but unfortunately the link to the English withepaper doesn't wok :(
Hi Davide, thank you for your comment, we are glad that you appreciate the video. We checked the link, it seems that it works correctly.... here you can download the whitepaper for free: www.kuglermaag.com/fileadmin/05_CONTENT_PDF/05_WHITEPAPER/whitepaper_automotive-spice_en_swe1_software-requirements-analysis.pdf
Hi, for me the descriptions of sys2 and swe1 are too similar. In general I don't understand where the difference between system and software lies. Especially if the product is software only
Hi Marcos,
I understand your point, but if you check the processes you will see that they are very similar. In most cases the term "system" was exchanged by "software", so it is not surprising that the presentation of the standard does not show a lot of difference. However, looking at the implementation of the processes, you have to approach them differently.
For SYS.2 you are looking at the system as a black box and define requirements. For SWE.1, it is the software only which is a black box. In some systems there is not a lot of difference, but for instance in ADAS systems, where camera input is preprocessed by FPGAs or ASICs, there is a big difference between system and software requirements.
In your case, if there is software development only you can skip the system-level processes. Actually, note 2 in SWE.1BP1 reflects that.
I hope this helps. If not, feel free to contact us.
Kind regards
Bhaskar
Good narrative Baskar.
We're glad you like it!
very good explanation sir, waiting for more videos
Thank you, we will upload soon new ASPICE videos!