Requirements and systems engineering

Click For Summary
SUMMARY

This discussion centers on the critical role of requirements gathering and functional architectures in systems engineering, particularly within the aerospace sector. Participants shared experiences highlighting the consequences of missed or poorly documented requirements, such as the 737 MAX incidents and challenges faced in medical diagnostic instrument design. The conversation emphasizes the dichotomy between NASA's rigorous requirements analysis and SpaceX's trial-and-error approach, advocating for a balanced understanding of both methodologies to inform decision-making in engineering projects.

PREREQUISITES
  • Understanding of systems engineering principles
  • Familiarity with requirements gathering techniques
  • Knowledge of agile programming methodologies
  • Awareness of functional architecture concepts
NEXT STEPS
  • Research NASA's requirements analysis approach in aerospace engineering
  • Explore case studies on the 737 MAX incidents and their implications
  • Learn about agile programming best practices and pitfalls
  • Investigate functional architecture frameworks and their applications
USEFUL FOR

Systems engineers, aerospace professionals, software developers, and students studying requirements engineering and functional architectures will benefit from this discussion.

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
301
  • · 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
2K
  • · Replies 3 ·
Replies
3
Views
5K
  • · Replies 35 ·
2
Replies
35
Views
8K
  • · Replies 25 ·
Replies
25
Views
5K
Replies
11
Views
4K