Software Requirements Analysis | Automotive SPICE SWE.1

Hi folks! you will learn the aspects while performing software requirements analysis according to Automotive SPICE I’m a principal assessor and trainer for Automotive SPICE I’m a very experienced assessor and have conducted more than 140 formal assessments also I have trained more than 250 assessors.

I like training and therefore here I am to help you understand Automotive SPICE. Okay, let’s get started! Why should you document the requirements? As a rule, you already have system requirements or customer requirements so why invest time and effort to document additional requirements? In a project, you want to deliver the agreed results on time within budget and in the quality required by the customer.

Software Requirements Analysis

If you do not document your requirements you may overlook the functionality or completely misinterpret your customers’ expectations. This causes additional effort, costs, and delays. You can also overlook aspects of your software that are essential to the functionality or non-functional aspects of your software.

This can lead to false starts or even additional development cycles. This process has strong links upstream to assist two system requirements analysis, SYS.3, system architectural design and, downstream, to software architectural design SWE.2 and qualification test SWE.6. Other processes with strong dependencies are project management MAN.3 and configuration management SUP.8 for instance because of release management and SUP.9 defect management and SUP.10 change request management.

The connection here is that defects identified in the tests have to be addressed and bug fixes and change requests have to be addressed in the regression tests. To ensure all this Automotive SPICE requires considering the following three major points. Number one, you need to consider more than just your customers’ requirements.

An important reason for documenting your software requirements is that you need to consider more than just your customers’ expectations. The software has to meet standards norms regulations and internal requirements which all increase the number of the overall requirements for documentation purposes.

Map the system requirements or in the case of software development only, the customer and other stakeholder requirements to your software requirements. Those reflect your internal view of the software. The software requirements, in turn, form the basis for the software qualification test and all downstream processes like for instance software architecture.

The software requirements describe the software as a black box. What should the software do not how should it do something? So we identify the following: The software requirements describe what are the signals that the pins of the micro reach what the software should do with these signals and what output signals we expect at the pins of the microcontroller.

Part of this approach is also to structure the requirements in such a way that they are meant for the internal organization and support the distribution of the requirements to the different areas of interest. This ensures that each organizational unit knows which requirements are relevant to it this classification may be achieved by attributes like for instance classifying requirements according to ISO 26062.

It could be a functional structure to support distribution to functional groups and other means. Number two: make sure you analyze and understand the implications of your requirements. Another aspect of this process as the name suggests is the analysis of requirements the requirements should be analyzed for feasibility or risk. These two are closely linked.

If you are not really sure about the feasibility of a requirement there is an inherent risk because it may take time to find a solution or there may be no solution at all. Obviously, there is a strong link to the estimates which we have to perform in project management specifically in MAN.3 BP5. Another topic to analyze is testability.

Of course, the support of the testers can be used to ensure this often the testers are also asked to review the requirements. Additionally, the analysis should cover technical implications this includes the assessment of dependencies between requirements. I included an example in the video on SYS.2 system requirements analysis.

Finally, the analysis should also cover the business aspects of the requirements. It should therefore be determined how the implementation of the various requirements affects costs and timeline. Now you can say that you cannot document all this in the requirements database. Remember that Automotive SPICE does not say where you document this.

For example, you could cover the first part of the analysis feasibility and risks in the requirements database, the technical implications in the corresponding and linked change requests, and the impact on costs and schedule in your project management tools. Number three: ensure traceability and consistency.

This process also requires that you ensure traceability between your software requirements the system requirements and the system architecture. However, Automotive SPICE explicitly states that redundancy is not required you can decide whether you prefer traceability to the system requirements to the system architecture or a combination between the two.

It depends on which approach supports your development in the best way not on which approach is easier for you. Traceability can be established through hyperlinks such as doors through specific traceability tools such as Rectify, through traceability mattresses, or through other manageable means which are supported by your company’s tool landscape.

The purpose of traceability is to support consistency checks like for instance to verify completeness and correctness of the software requirements b to support the impact assessment in case of change requests or defects and c to support the reporting of the implementation status of the software requirements.

The other part of this point is to ensure consistency. Consistency means that you prove the completeness and correctness of your software requirements against the system requirements respectively system architecture. This can only be established by a review.

If you skip this review you may have incomplete or even faulty software requirements. The worst part is that you may not even notice the defects in the software qualification test because the test is performed against the software requirements. If these are faulty your test may not even show for its behavior so do not skip this review.

Do you want to learn more about software requirements analysis? We have prepared a more detailed white paper that you can download for free by clicking on the link below. If you are interested in automotive spice you might consider subscribing to this channel we are providing expert knowledge on a regular basis. And don’t forget to share this video with your colleagues! Finally, thanks for watching good luck and goodbye! See you.

For more article.

DSF Blogging Network

DSF launches its blogging network to help people reach high-quality knowledge worldwide easily by our DSF Blogs. We are spreading the news to this entertaining world through this platform. So that not only readers even writers can contribute with us. Best platform for gathering information about different trending topics in this world. Contact us
Back to top button