Requirements and systems engineering

Click For Summary

Discussion Overview

The discussion revolves around requirements and systems engineering, particularly in the context of aerospace engineering. Participants share experiences and examples related to missed requirements, requirements gathering, and the implications of adopting a functional perspective in engineering design.

Discussion Character

  • Exploratory
  • Technical explanation
  • Debate/contested

Main Points Raised

  • Some participants reference the 737 MAX incidents as a case study involving missed or conflicting requirements and design failures.
  • One participant shares their experience with medical diagnostic instruments, highlighting the importance of specifying machine bias and precision in requirements, which were not adequately addressed in their project.
  • Another participant discusses challenges in agile programming, noting that undocumented requirements can lead to misalignment with actual user needs, as experienced with avionics displays.
  • Some participants compare NASA's thorough requirements analysis approach to SpaceX's trial-and-error methodology, suggesting that both have merits and drawbacks depending on the context.
  • There is a discussion about management's tendency to impose rigid standards, which can stifle flexibility and lead to poor outcomes, as illustrated by a participant's experience with excessive parameters in function calls.
  • One participant humorously reflects on the evolution of management attitudes towards software development, suggesting that historical perspectives have shifted significantly over time.

Areas of Agreement / Disagreement

Participants express a range of views on the effectiveness of different approaches to requirements and systems engineering, with no clear consensus on the best practices. The discussion remains open-ended, with multiple competing perspectives presented.

Contextual Notes

Participants note limitations in their experiences, such as the lack of specified requirements and the challenges of agile methodologies, without resolving these issues or reaching definitive conclusions.

Who May Find This Useful

This discussion may be of interest to students and professionals in systems engineering, aerospace engineering, software development, and those exploring the implications of requirements gathering and functional design approaches.

ashah99
Messages
55
Reaction score
2
Hi all, I am taking a course in systems engineering and we are discussing about requirements and functional architectures. Got me wondering, for the engineers here in the aerospace, do you have any interesting examples relating to missed requirements or to requirements gathering? What about benefits and difficulties in taking a functional perspective on a problem?
 
Physics news on Phys.org
How about the infamous 737 MAX incidents? It can be cast in anyone of several ways, missing requirements, conflicting requirements, faulty design, malfeasance, ... For purposes of student discussions, it should be a gold mine.
 
  • Like
Likes   Reactions: Lnewqban and FactChecker
What is a "functional perspective" (I do not know what you mean)?

At one time I did system design for medical diagnostic instruments. The variability of numbers reported by such instruments in actual use in the field is clearly of primary import (ask Elizabeth Holmes). This variability of the system in use contains essentially two pieces: accuracy (machine bias) and precision (repeatability). The requirements I inherited for my first foray specified only the maximum allowed total system variability, and being new to the field I took them at face value. Three years of sweat later the system (which did 47 different blood tests) met all specs. but the customer was not pleased because the (unspecified) machine bias part was higher than they anticipated although the overall variability met all standards and the FDA was happy.
 
This might not be for the introductory course, but there was (is?) a trend called "agile programming". I had an experience where we spent some man-months getting some avionics displays to look exactly like they wanted. The requirements were not written down and documented except that the code I made agreed with their wishes. We got it perfect. Then the REAL users (pilots) showed up and it turned out that they had completely different wishes. The program moved on to a new phase and I was not on it, so I do not know if they ever changed our code. Agile programming has that danger for people who are inexperienced with it. The requirements may not be well documented and reviewed.
 
Last edited:
  • Like
Likes   Reactions: Klystron
I think it is a wonderful topic for student exploration and discussion.

Another aerospace example is NASA's requirements+analysis approach to rockets and vehicles, compared to SpaceX's approach favoring trial and error. In software jargon, agile programming is analogous to trial and error.

Many examples of success and failure can be found for both approaches, so neither can be eliminated in all cases. True wisdom comes with understanding both and making a wise choice about which approach to use in a specific case. IMHO, that is the lesson that students should take away.
 
  • Like
Likes   Reactions: FactChecker
anorlunda said:
True wisdom comes with understanding both and making a wise choice about which approach to use in a specific case. IMHO, that is the lesson that students should take away.
True. But upper management HATES to leave those decisions up to the lower levels (possibly for good reasons). They prefer hard and fast "thou shalt" decrees. I have been in situations where very reasonable and flexible guidance (from Carnegie Mellon) was turned into hard and fast program standards that led to terrible code. In one program, the standards forced us to have so many parameters (hundreds) in our function calls that the compiler line-continuation limit was exceeded. But I digress.
 
Last edited:
FactChecker said:
But upper management HATES to leave those decisions up to the lower levels (possibly for good reasons). They prefer hard and fast "thou shalt" decrees.
Maybe that's why startups, populated with kids, with no adult around, thrive so well in some areas.

My sister, in middle age, worked for several startups that decided that they had grown enough to hire at least one adult to keep the lid on stuff.

When I was young and management was old, managers thought that software was witchcraft. They made no decrees of any kind, and seemed to wish that software and programmers didn't exist. Then some jerk went out and invented the wheel and everything changed. :wink:
 
  • Like
Likes   Reactions: FactChecker

Similar threads

Replies
0
Views
426
  • · Replies 2 ·
Replies
2
Views
3K
  • · Replies 3 ·
Replies
3
Views
2K
  • · Replies 5 ·
Replies
5
Views
1K
  • · Replies 14 ·
Replies
14
Views
3K
  • · Replies 102 ·
4
Replies
102
Views
3K
  • · Replies 3 ·
Replies
3
Views
5K
  • · Replies 35 ·
2
Replies
35
Views
8K
  • · Replies 25 ·
Replies
25
Views
5K
Replies
11
Views
4K