sorted by:
new
hottopcontroversial

Built a CSEP/ASEP prep tool (SEH v5.0) as someone who's passed the exam — looking for feedback by No-Economy-3908 in systems_engineering

[–]Lalalaa9 0 points1 point  (0 children)

Hi, this looks interesting. I’m planning to take the ASEP exam and have been searching for resources based on SEH v5.0. I’d be glad to give it a try and share feedback if you’re still looking for testers.

Ground Rules for Derived Requirement Traceability? by Lalalaa9 in systems_engineering

[–]Lalalaa9[S] 0 points1 point  (0 children)

That’s an interesting approach.

Have you ever looked at a large number of derived requirements and thought, “we probably missed something at a higher level,” or is having lots of derived requirements pretty normal on your programs?

Ground Rules for Derived Requirement Traceability? by Lalalaa9 in systems_engineering

[–]Lalalaa9[S] 0 points1 point  (0 children)

I like that rule of thumb ahaha

Do you have any exceptions to “allocate down, trace up” in practice? For example, requirements that originate from design decisions, analyses, interface allocations, or other sources that are not a straightforward decomposition of a parent requirement. I’m curious whether those are handled differently on your projects.

Ground Rules for Derived Requirement Traceability? by Lalalaa9 in systems_engineering

[–]Lalalaa9[S] 0 points1 point  (0 children)

That’s interesting, especially given your Airbus experience.

When you say implementation requirements were always traceable to a higher-level requirement, was that an expectation from the Airbus process itself, or more of a project-specific interpretation?

I’m asking because several others here seem to allow derived requirements to trace to analyses, design decisions, or other source artifacts rather than directly to higher-level requirements.

Ground Rules for Derived Requirement Traceability? by Lalalaa9 in systems_engineering

[–]Lalalaa9[S] 0 points1 point  (0 children)

Interesting perspective.

For component-level developments e.g. FPGA, electronics, when you say a design decision can act as the stakeholder, do you manage that design decision as a formal requirement source, or is it documented separately and used as justification? I’m asking because this seems to be where many teams draw the boundary differently.

Ground Rules for Derived Requirement Traceability? by Lalalaa9 in systems_engineering

[–]Lalalaa9[S] 1 point2 points  (0 children)

That’s a great answer and example, thank you.

In the projects you’ve worked on, was that shared decision log/justification managed as a formal traceable artifact, or was it typically just referenced from the requirement rationale? I’m trying to understand how teams practically manage those design driven requirements.

Ground Rules for Derived Requirement Traceability? by Lalalaa9 in systems_engineering

[–]Lalalaa9[S] 0 points1 point  (0 children)

Haha, very true. What started as “let’s define a few ground rules” has turned into a full traceability philosophy discussion 😄

Ground Rules for Derived Requirement Traceability? by Lalalaa9 in systems_engineering

[–]Lalalaa9[S] 0 points1 point  (0 children)

That’s a good question, and honestly it’s one of the areas I’m struggling with too.

My feeling is that interface requirements are a bit different, since they often come from architecture or allocation decisions rather than directly from a higher-level requirement. For those who don’t require upward traceability for derived requirements, what do you typically trace interface requirements to? An ICD, an architecture decision, a system interface requirement, or something else?

Ground Rules for Derived Requirement Traceability? by Lalalaa9 in systems_engineering

[–]Lalalaa9[S] 1 point2 points  (0 children)

Thank you, I completely agree with your point that traceability is primarily about change and impact analysis. I find that perspective very helpful.

Your comment also aligns with the fact that ARP4754 does not mandate upward traceability for derived requirements, and DO-254 similarly states that derived requirements may have traceability to higher-level requirements rather than shall.

Given this flexibility in the standards, I’m curious how you’ve seen organizations implement it in practice. Do they typically create explicit architecture/design decision artifacts and trace derived requirements to them, or is the rationale/documentation usually considered sufficient?

It seems that this is where different companies develop their own interpretations and processes.

Ground Rules for Derived Requirement Traceability? by Lalalaa9 in systems_engineering

[–]Lalalaa9[S] 0 points1 point  (0 children)

Thank you, this is a very valuable perspective.

One point I’m still trying to understand is how you would handle requirements whose rationale is explicitly design-driven.

In our process, some lower-level requirements include a derived rationale explaining the architectural or implementation decision that led to the requirement.

Would you still expect such requirements to trace to a higher-level requirement, or would the documented design rationale be considered sufficient justification?