Software Quality Assurance & Engineering

Module Reflection  ·  MSc Computer Science (Conversion)  ·  Author: Orville Fernandes

What I Brought In

My background in cloud engineering gave me some practical exposure to software processes: working within CI/CD pipelines, managing deployments, and dealing with the consequences of inadequate quality controls in production systems. I had applied software engineering practices and had some understanding of it from my BSc. COM7113 gave me some more theoretical scaffolding around the subject and understanding on why it mattered, though the subject matter itself I found harder to get excited about.

The Module

The teaching was well structured and connected to the assessments. Sessions covered requirements engineering, UML and system modelling, design patterns, software testing, sociotechnical systems, and dependability. The module leader brought the same quality and enthusiasm to this module as she had to COM7112, which made classes engaging, and made me excited to attend. The content is inherently theoretical, and I found it difficult to sustain engagement with it in the way I could with a module that involved building something. That is an honest reflection on my own preferences rather than a criticism of the teaching.

The Coursework

Two assessments were set in the same scenario: the team has been engaged by Tesla to re-engineer their Full Self-Driving emergency braking system, following the NHTSA safety investigations into FSD failures. CW1 required a validated requirements and specification document; CW2 requires a full project and quality plan.

Our group chose to narrow our scope to the Autonomous Emergency Braking subsystem specifically. That decision was deliberate: the broader FSD system is enormous, and attempting to produce meaningful requirements for it within 1,500 words would have produced something superficial. By focusing on AEB, we were able to go into some level of depth. The final submission ran to 80 pages with 23 appendices, with the main text meeting the word count requirement. We produced functional and non-functional requirements, use case and UML diagrams, a validation table, and a change request process. Despite that volume of work, it still felt like we had only scratched the surface. That feeling is, I think, inherent to the domain.

Critical Reflection

The challenge with this coursework is one I want to be honest about. Writing credible, specific requirements for a safety-critical autonomous vehicle system requires automotive domain knowledge: actual braking distances, sensor response thresholds, failure rates, the specifics of ISO 26262 functional safety levels (Broy, 2006). That knowledge exists in public literature, but becoming fluent enough in it to write truly authoritative requirements takes time that a 10-week module does not provide. The scenario is ambitious, arguably more so than the format allows for. A 1,500-word requirements document for a system of this complexity will always feel incomplete, not because the student has failed, but because real requirements specifications for safety-critical systems run to hundreds of pages produced by teams of specialist engineers over months (Sommerville, 2016).

I do not think this makes the coursework a poor choice. Engaging with a scenario this demanding forces a level of research and critical thinking that a simpler brief would not. But it does mean the assessment rewards students who either have prior domain exposure or invest heavily in background research, and that bar is not made explicit in the brief. CW2 is ongoing at the time of writing, and we are approaching the project and quality plan with that same commitment to depth.

Learning Outcomes

LO1 – Software engineering approach to safety-critical systems: Addressed through CW1. Scoping the AEB subsystem, producing structured functional and non-functional requirements, and applying UML modelling all required applying a systematic software engineering approach to a genuinely complex, real-world safety problem.

LO2 – Critical analysis and requirements specification: Addressed through CW1. The validation table, traceability between requirements and use cases, and the change request process all reflect the requirements management practices covered in the module. The depth of the appendices demonstrates engagement beyond the minimum.

LO3 – Quality management and professional, legal, and social issues: Being addressed through CW2, which is in progress at the time of writing this.

References

Broy, M. (2006) 'Challenges in automotive software engineering', Proceedings of the 28th International Conference on Software Engineering (ICSE 2006), Shanghai, 20–28 May. New York: ACM Press, pp. 33–42.

International Organization for Standardization (2018) ISO 26262: Road Vehicles – Functional Safety. 2nd edn. Geneva: ISO.

Sommerville, I. (2016) Software Engineering. 10th edn. Boston: Pearson Education.

Marks