System Thinking Approach in Writting Aircraft Design Requirements

[PriyaAlexander]

Hello,

I am currently pursuing a course degree in System engineering and I am a designer and aircraft engine performance analyst by profession.

Capturing the customer requirement is a critical issue in developing the right design specification for the system under context. There are tools currently available in Requirement engineering discipline where people from different background try to "teach how the system should work" to the designer. The tools are mainly SySML, UML, FFD and so on. From my point of view these tools are not very effective in bringing out the physical laws governing the system function. As a result, the function so developed or defined using these tools misleads the designer and hence the design.

I'd like to know the comments or remarks from other designer in Requirement management field about these tools and is there a best way to express the top-level functional requirements of the system?

Thank you

 

[IRstuff]

I think we're still a ways off from having a tool that does more than capture logic-based functional requirements. That's mainly because logic-based functional requirements is really about the only common ground that is shared amongst some very disparate systems. Just consider how a single tool might be able to handle your aircraft performance requirements as well an electro-optical camera system requirements; these have extremely different performance parameters and physics-based models.


TTFN

FAQ731-376
Chinese prisoner wins Nobel Peace Prize

 

[PriyaAlexander]

Well stated and thank you.
The general consensus is, there is no one single tool that could satisfy all the stakeholders in the loop. For a customer it doesn't matter how does it work and it is important for a designer to know how innovative work can add value to the business core value. Taking about innovation or quality that works depends on how the design requirements are formulated. It is a purely team wide mental acitivity wherein a good quality ideas forge in. So we need a standard process flow activity in sequence to tap the hidden decisive design parameters. By STANDARD I mean common to all the system and I think one way to investigate is to understand the behavioral aspects of the system (PATTERN). If there is standard design pattern rules, then writting a realistic and meaningful requirement could be as simple as possible.

Do you agree this?

thank you

 

[SWComposites]

is it me just being an old stress guy, but does

"there is no one single tool that could satisfy all the stakeholders in the loop. For a customer it doesn't matter how does it work and it is important for a designer to know how innovative work can add value to the business core value. Taking about innovation or quality that works depends on how the design requirements are formulated. It is a purely team wide mental activity wherein a good quality ideas forge in. So we need a standard process flow activity in sequence to tap the hidden decisive design parameters. By STANDARD I mean common to all the system and I think one way to investigate is to understand the behavioral aspects of the system (PATTERN). If there is standard design pattern rules, then writing a realistic and meaningful requirement could be as simple as possible."

just sound like management gobbledygook BS? Is this some sort of exercise to see how many buzzwords and management fad terms can be crammed into a single paragraph? or do systems engineers always talk like this?

 

[SAITAETGrad]

SWComposites: go w/ D. All of the above.

 

[PriyaAlexander]

Well, most system engineers are former aerospace engineers who advance into systems engineering. They must take into account management in addition to other STRESS factors.

 

[IRstuff]

It's just an abstract desirement, which, unfortunately, is not commensurate with reality. In most aerospace systems, the functional requirements that can be expressed in terms of UML, sequence diagrams, etc., generally occupy less than 10% of a system specification, while the remainder consists of performance requirements, environmentals, SWaP, and design and construction. None of the remainder are particularly expressable as "functions," e.g., "the housing shall provide the functions of environmental protection, EMI shielding, mechanical support of the optical windows," etc.

The reality is that 99.9% of the UML-based systems engineering effort is expended on that 10% of the specification, since those requirements are actually what UML was designed to express, e.g., "The system shall perform system initialization followed by asynchronous generation of SysReady within 30 seconds of application of power."

For my company, it's the other 90% of the system where innovation occurs.

TTFN

FAQ731-376
Chinese prisoner wins Nobel Peace Prize

 

[PriyaAlexander]

Certainly, this is the limitation set forth in expressing “a well-formed” requirement. Your example: the housing [system] shall provide the functions of environmental protection, EMI shielding, mechanical support of the optical windows [Action] can be reframed as “During xx time phase [condition], the housing [System X] shall provide life support [functions] for crew and payload [Target] for a duration of XX years [Value. This is as per NASA and INCOSE SE standard. It is possible to cascade from this single requirement to more than 50 plausible functional, performances, interface requirements and so on.

Per se, the design solution space should not be restricted via through this requirement. We need physics based models to assess the pros and cons of our decision so as to avoid needless functional requirement. Again, it is not a question of reinventing the wheel, it is a quest to find the better way to express, design and implement. At requirement level definition as you rightly stated, we don’t have a proper tool to look at the problem in a big picture neither an answer. In fact, this has turned my attention very deeply and now investigating the psychological aspects of the system

 

[GregLocock]

There's a bit of confusion here in my opinion. First you have to capture all the customer requirements. Secondly you have to generate a set of formal design functions from them that can be cascaded to your design teams.

I doubt any formal one size fits all process can really handle the first step.

The second relies on an experienced project team, not a piece of software.



Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376

http://eng-tips.com/market.cfm?

 

[IRstuff]

Perhaps the issue is with what the definition of "function." A function, in my thinking, is something that actively produces a measureable reaction when given a measureable stimulus. I think UML is all about actions and agents and responses. In fact, standard UML doesn't even deal with internal actions, only external actions at an interface boundary.

A window has a "function" in ordinary English, but it, by itself, is purely a passive element, which is not something that is dealt well with UML, so it's not a "function" in UML. In fact, all the requirements that describe a window are more precisely defined as "properties" rather than functions. You cannot devolve "the paint shall be battleship gray" into a "function" and do stuff with it in a functional description language universe.

TTFN

FAQ731-376
Chinese prisoner wins Nobel Peace Prize

 

[PriyaAlexander]

So we are having different interpretation of the problem definition. Stating the problem is more difficult than stating the solution. This is what happening in current design department. We receive a customer need and there is an intermediator to translate this need into a system requirements as a capability measures of the system (function) regardless if he is right or wrong. The design team finally twist their head 360° trying to understand what is the rationale behind the requirement and consequently waste time.

Well, this is a never-ending process. The beauty of system engineering is, I like the concept of system thinking wherein we identify the rationale from the need to functional system requirement full stop.As an example say window is a system and has a property like color, dimension, material, shape, layout and so on. It depends on entity like paint,human resources, some standards, ergonomics and so on. This will lead to innovation if one considers to have a window that shall be removable. From here we move into detailed specification, which is the job of domain expert & designer, with performance measures and identify its interface, RAMS after some trade-off analysis.

How we think is how we learn, communicate and implement. The designer mind is fused with lot of design alternatives and tools like UML, SysML certainly restricts their design solution space. I am not sure about the fact that these tools are the only way to communicate to the customer in a plain simple english lanaguage showing them the sequence of use cases. For me techniques like QFD and TRIZ are very interesting. Currently, the questions is how the system engineer can help the designer to write the right design specification? My answer to them was talk to the designer before writing the system requirement and you are fortunate if they have moment to spare.

 

[IRstuff]

"Stating the problem is more difficult than stating the solution"

That's often the case. A solid, air tigght requirement would take a paragraph, but is often expressed as a single sentence. Nonetheless, most requirements analysis tools are "functional," because they are invariably written by computer scientists or mathematicians. The general purpose requirements tools like DOORS, only bookkeep requirements, and don't even begin to deal with requirements analysis and decomposition.



TTFN

FAQ731-376
Chinese prisoner wins Nobel Peace Prize

 

[GregLocock]

Sorry I may have confused things, I was using the word 'function' in its general sense, not a formal X=f(y1,y2,y3...) one.

The reality is that for most projects the customer requirements are a whole mishmash of prior history, actual specific wants, and vague wishy washy desires. Capturing the prior history and experience is the most boring and most essential part of the process in my opinion. Otherwise you'll make exactly the same mistake as the previous project.

Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376

http://eng-tips.com/market.cfm?

 

[PriyaAlexander]

Here comes "Model Based System Engineering" (MBSE), what does the future hold?

The attachment has something to say!!!

 

[IRstuff]

Basically, more of the same. I don't necessarily wish to rain on anyone's parade, but the reality is quite different than anything that INCOSE or CMMI certifications.

MBSE is merely a slightly more formalized description of things that we already do, as embodied in ANSI632 or IEEE12207 or DoD-SEF or MSFC HDBK-1912. The concept of doing requirements analysis and modelling is embodied in every systems engineering process manual that I've ever had to slog through for the last 20 years.

And, as demonstrated in Figure 3-2 of your citation, the basic paradigm of the PMTE modelling is action/reaction, which does not address system "properties," which is often a sizable portion of a system's requirements specification. Moreover, while these PMTE tools are "vendor neutral," they are not model neutral, i.e., I can't arbitrarily plug in my model for laser rangefinder performance because there isn't even an input for something like that.

Even in Telelogic's flagship requirements management tool, DOORS, the typical contract and user actually use less than 10% of the capability and scope of the tool. This is particularly even more difficult when different revisions of DOORS are nearly completely incompatible with each other. DOORS cannot readily take the output from my performance simulation tools and incorporate them into the requirements management and tracking, because there really is no simple model for addressing performance requirements that are affected by the environmental requirements. The basic modelling tools don't even exist, and one would have to roll their own, because the amount of money invested in the development of such tools would make them proprietary.

As for certifications, organizations certified at CMMI 5, which is the highest achieveable level, do not, at the everyday organizational level, come close to adhering to their alleged capability maturity level. I know this because we've dealt with two companies with CMMI 5 certifications, and in both cases, their processes were actually no better than ours, with our measly CMM 3 certification.

TTFN

FAQ731-376
Chinese prisoner wins Nobel Peace Prize

 

[PriyaAlexander]

Bingo! I go with it. We could expect a revised version of standards in the coming years and I don’t know what modified PMTE definition it will carry to address the key challenges in design process.

My current work is to find an approach that allows the design synthesis to be a part of the SE process.
Well, requirements appear in different facets and there should be a method to determine the system behavior. We first need requirement decomposition as a classification of performance requirements, for sure. If we are talking about the aircraft weight then it can be decomposed by assigning weights to different modules (partionable) and this is different from a requirement which is very specific like engine weight (allocable). And if the requirement is about range then the decomposition process becomes computationally intensive (non-allocable) because it is the interaction of many properties like noise margin, threshold Signal-to Noise ratio and so on. It depends on the level of abstraction that we are handling.
If for the functionality of the system is examined, for example the fuselage has a property relating to the number of passengers it can carry and its shape is determined by the mission statement or higher level requirement. Its lower constituent’s sub-systems like barrel segment, floor beams, bulkheads, skin stiffener element do not exhibit this capability on their own. Similarly, the geometry of the wing and nacelle are affected by the engine choice. At a conceptual level, it is just a 2D model not 3D so that we can play around the design solution space.

My concern is, the traditional SE tools creates a stasis in design process via a sequence of formal definition which carries nothing for a designer and you made it clear. I have to stick to the rules and assess how these tools can improve the problem definition or perhaps come out with a technique like TRIZ!!!


Thanks for sharing your insights.

 

[KENAT]

For aircraft design you could look at Dan Raymers work to see how it addresses some aspects you're talking about.

Posting guidelines faq731-376

http://eng-tips.com/market.cfm?

(probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484​

 

[PriyaAlexander]

I got the hard copy of Dan Raymer's Conceptual Design approach and indeed it is an excellent source book.I have used it in writing top level requirements for high lift system.

Thank you for the support

 

[rb1957]

personally i don't think the difficulty is with problem definition ... the difficulty with defining the problem is to be sure that you capture all the design requirements.

The difficult thing, IMHO, is solving the problem, ie designing the solution. part of this difficulty is many of the design requirements are conflicting, or at least need a trade off to get to the "optimal" solution; consider weight vs cost, consider material cost vs manufacturing cost.

going back to your simple example of a window, the design spec will say at least weight, cost, and size (and maybe things like optical properties/distorsion, abrasion, ...). with weight and cost there'll be hard targets, but soft targets (benefits (profits) if you get lower than the target, penalties if you exceed them ... if it's 1 lb heavy we'll charge you $10, but being 1 lb heavier makes it $20 cheaper for you to make, and being a good partner you'll pocket the $10 you made).

Then you mentioned a removable window ... a whole different problem to define and to solve ...

 

[IRstuff]

They are equal part of the puzzle. That's why there's a rather large period of time before System Requirements Review even occurs. In some specifications, you literally need an English BA to slice and dice and understand what the requirement is. In other cases, the requirement is too nebulous to design from and someone has to parse it, and develop the entire concept of operations before anyone can even start putting lines on paper.

TTFN

FAQ731-376
Chinese prisoner wins Nobel Peace Prize