Requirements and systems engineering

In summary, this conversation discusses the benefits and difficulties in taking a functional perspective on a problem. It also discusses the "functional perspective" and the trend of "agile programming."
  • #1
ashah99
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?
 
Physics news on Phys.org
  • #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:
  • Like
Likes Klystron
  • #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
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:
  • #7
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 FactChecker

FAQ: Requirements and systems engineering

1. What is the difference between requirements engineering and systems engineering?

Requirements engineering is the process of identifying, documenting, and managing the needs and expectations of stakeholders for a specific system or product. Systems engineering, on the other hand, is a broader discipline that focuses on the design, development, and management of complex systems. In other words, requirements engineering is a subset of systems engineering.

2. What are the key components of a requirements engineering process?

The key components of a requirements engineering process include requirements elicitation, analysis, specification, validation, and management. Requirements elicitation involves gathering information from stakeholders to understand their needs and expectations. Analysis involves analyzing the gathered information to identify key requirements. Specification involves documenting the requirements in a clear and unambiguous manner. Validation involves ensuring that the requirements meet the needs and expectations of stakeholders. Management involves tracking and controlling changes to the requirements throughout the development process.

3. How do you ensure that requirements are complete and accurate?

To ensure that requirements are complete and accurate, it is important to involve stakeholders from different backgrounds and perspectives in the requirements engineering process. This helps to identify any missing requirements or conflicting requirements. It is also important to use techniques such as prototyping and reviews to validate the requirements and ensure that they meet the needs and expectations of stakeholders.

4. What is the role of traceability in requirements engineering?

Traceability is the ability to track and document the relationships between different requirements and the system components that fulfill those requirements. It is an important aspect of requirements engineering as it helps to ensure that all requirements are met and that changes to requirements are properly managed. Traceability also helps to identify any potential impacts on the system when a requirement is changed or removed.

5. How does systems engineering support the requirements engineering process?

Systems engineering supports the requirements engineering process by providing a holistic view of the system and its components. This helps to identify any potential conflicts or dependencies between requirements. Systems engineering also provides tools and techniques for analyzing and validating requirements, such as modeling and simulation. Additionally, systems engineering helps to ensure that the final product or system meets the needs and expectations of stakeholders by considering the overall system design and functionality.

Similar threads

Replies
5
Views
1K
Replies
3
Views
4K
Replies
35
Views
5K
Replies
25
Views
4K
Replies
6
Views
2K
Replies
2
Views
3K
Replies
4
Views
2K
Replies
72
Views
11K
Back
Top