Requirements Analysis of New/Changed Regulations

[kontiki99]

I've been struggling with tools or methodology for extracting the requirements from complex cross-referenced regulations.

Sure, I can make a table, paraphrase the requirement, in one column, point to the regulatory reference in another, and list the defining spec in a third.

The part that really bothers me it ensuring I have captured them all. I guess I want to be sure I have unwound all the cross references to ensure I captured everything on the relevant "pathways" and can document why the non-relevant reference pathways are not applicable. Sometimes those facts change over time too. Anybody have the same issue, know of tools or good guidance?

Thanks,

 

[IRstuff]

Not really. Most requirements management tools are more in the "management" arena, i.e., bookkeeping the stuff you actually figure out, rather than doind anything in the way of figuring out the requirements to begin with.


Unfortunately, I think that until some really solid expert or artificial intelligence systems get developed, we still have to depend on a good systems engineer to do the collation and allocation.

TTFN

FAQ731-376

 

[rb1957]

talk (early) to whoever is approving the mod (the certification authority, maybe your local FAA office, maybe someone internal to your org, ...).

as the previous poster says there is no listing (as far as i'm aware) that says "if you're doing this, you need to address these requirements"

a problem we have (in our company) is if the electrical guys are doing (leading, principally involved in) a mod, they'll gloss over the structural side of the mod ... but constant whining is havng a +ve affect !

 

[Sparweb]

as the previous poster says there is no listing (as far as i'm aware) that says "if you're doing this, you need to address these requirements"

I once looked through the hand-written notes of an old-timer who really had done this for himself. A binder with projects such as engine changes, interior conversions, various instrument types. Basically example certification plans for what he thought were the standard run-of-the-mill projects he had to review. Unfortunately he didn't share it with me!

Steven Fahey, CET

 

[DHambley]

I have had to do a few worse-case analysis for some products going into Boeings 787. Wow, talk about "complex cross-referenced regulations"!

It was definately not a one-week job for a project engineer to perform, but eventually I wound up with many columns on an Excel spreadsheet. DO-160E parapraph X refers to part X of D6-15050, which is satisfied by the tests called out in section Y of the whoknowswhat document. etc etc.

In the task of tying each of our performance parameters to a specific spec, I found several instances of D6-16050 cross referencing back onto itself.

Expect many columns in your spec doc to finally ge a clear path from each performance measure to an actual industry spec.

 

[kontiki99]

I appreciate the responses to the OP.

I work for an operator so my requirements analysis needs to be very broad.

Our airplane fleet is one aspect of an overall business plan. We don’t typically get much help from the business side, they seem to have no clue whatsoever. The company operation may be a bit too silo-ed (new word?).

In one mod we met regulatory requirements for operations in a certain region, but overlooked the CRAF revenue stream. We had to go back and make some fast updates to fleets that didn’t operate in the affected region right now to avoid loosing that revenue.

Other business implications might be Operational, like fuel savings associated with efficient operations.

Then there is what I call unwinding the regulations, and it’s not always US regulations too.

Then if there are STCs involved we need to work with the requirements for technical approval.

If there are contracts and realistic continuous airworthiness support requirements above the nominal FAA ICAW we need to capture those requirements too. That might be shop support software licensing subscriptions etc.

Then as we work toward a hard target we should be trying to look beyond that regulatory compliance date to how the system architecture will evolve beyond the "clutch" date. If it’s related to a new fleet acquisition, we want to try to see out as far as the useful life of the airplane at least for trends.

We will usher in the FAA’s Next Gen effort in a series of stair steps not all in one leap. A little research is all it takes to set things up for relatively painless growth to the far term target as well as tomorrows deadline.

Of course I do like to assume the company will exist 10 years down the road. I’m not sure the business people always believe so.

After capturing the requirements there is the (verification validation) end IRStuff calls the management stuff.

 

[Sparweb]

It sounds like you've been charged with much more than just airworthiness to consider. If your job description includes considerations of operational efficiency, and project planning into the next 10 years, then you are looking at a team effort at least to sort through the mountain. How about a team with members that come from each of the "silos" that comes together regularly to move the plan forward. Then action has to be delegated to people with the ability and time to do it.

Regulations change (Transport Canada is currently undergoing a paperwork overhaul, for example) and often accidents come out of the blue that throw your near-term plans into the dump.

Long-term planning can be a useful tool for controlling impulsive ideas. Finding 6 people working on a side-line project because of a comment made by the VP will divert them from the bigger project. If you have to confront the CEO with this as a "problem" it's better to have a solution in the form of the planning document he's already signed.

I'd be very surprised if you found a template that you could use. First because of the complexity of what you want, and second because any compnay that comes up with one will jealously guard their hard-earned labour. Especially if it works well enough to help the bottom line.

Steven Fahey, CET