Requirements and systems engineering

  • #1
60
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?
 

Answers and Replies

  • #2
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 Lnewqban and FactChecker
  • #3
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.
 
  • #4
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:
  • #5
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 FactChecker
  • #6
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:
  • #7
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 FactChecker

Suggested for: Requirements and systems engineering

Back
Top