×
INTELLIGENT WORK FORUMS
FOR ENGINEERING PROFESSIONALS

Are you an
Engineering professional?
Join Eng-Tips Forums!
• Talk With Other Members
• Be Notified Of Responses
• Keyword Search
Favorite Forums
• Automated Signatures
• Best Of All, It's Free!

*Eng-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

#### Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

# System Thinking Approach in Writting Aircraft Design Requirements

## System Thinking Approach in Writting Aircraft Design Requirements

(OP)
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

### RE: System Thinking Approach in Writting Aircraft Design Requirements

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.

### RE: System Thinking Approach in Writting Aircraft Design Requirements

(OP)
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

### RE: System Thinking Approach in Writting Aircraft Design Requirements

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?

### RE: System Thinking Approach in Writting Aircraft Design Requirements

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

### RE: System Thinking Approach in Writting Aircraft Design Requirements

(OP)
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.

### RE: System Thinking Approach in Writting Aircraft Design Requirements

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.

### RE: System Thinking Approach in Writting Aircraft Design Requirements

(OP)
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

### RE: System Thinking Approach in Writting Aircraft Design Requirements

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: Eng-Tips.com Forum Policies  http://eng-tips.com/market.cfm?

### RE: System Thinking Approach in Writting Aircraft Design Requirements

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.

### RE: System Thinking Approach in Writting Aircraft Design Requirements

(OP)
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.

### RE: System Thinking Approach in Writting Aircraft Design Requirements

"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.

### RE: System Thinking Approach in Writting Aircraft Design Requirements

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: Eng-Tips.com Forum Policies  http://eng-tips.com/market.cfm?

### RE: System Thinking Approach in Writting Aircraft Design Requirements

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.

### RE: System Thinking Approach in Writting Aircraft Design Requirements

(OP)
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!!!

### RE: System Thinking Approach in Writting Aircraft Design Requirements

(OP)
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

### RE: System Thinking Approach in Writting Aircraft Design Requirements

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 ...

### RE: System Thinking Approach in Writting Aircraft Design Requirements

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.

### RE: System Thinking Approach in Writting Aircraft Design Requirements

(OP)
It is true. Before we establish the  Misssion, Goal and Objective statement for a project, there is something called stakeholder analysis. For instance, consider a strategic plan for an Asian market, in this case the customer interest would be entirely different and also their way of expressing it in their natural language. So what happens here is, you get a fuzzy or a vague information about the customer need. Therefore we need a feature based opinion mining or semantic analysis to get the subject/complement/object of the customer need. From here, system engineers translates the need into weight, cost requirements (mission). Then the story goes on with the capability measures with attributes (abrasion or distortion) and if possible innovation (removable) - customer delight

### RE: System Thinking Approach in Writting Aircraft Design Requirements

"a fuzzy or a vague information about the customer need" ... the root of the problem.

### RE: System Thinking Approach in Writting Aircraft Design Requirements

I actually referring to the formal requirements, but sure, the stakeholders rarely have solidified requirements, and occasionally, they do sneak one of their nebulous requirements into the formal requirements.

We used to have a whole seminar at my previous employer just on how to parse formal requirements.

### RE: System Thinking Approach in Writting Aircraft Design Requirements

(OP)
Let me revise requirement engineering process again

1-----> customer needs

2 --->formal requirements(contains "shall" statment)

3----->Technical or design requirements        (contains functional, performance, special quality....attributes)

4 ----> Design Specification.

### RE: System Thinking Approach in Writting Aircraft Design Requirements

That's a plausible overview.  Our process has about 12 steps between your 1 and 2:
1 customer expectations
> project and enterprise external constraints
> operational scenarios
> measures of effectiveness
> system boundaries and interfaces
> utilization environments
> life-cycle process
> top level functional requirements/analysis
> performance requirements/analysis
> modes of operation
> technical performance measures
> design characteristics
> human factors
2 requirements baseline
> specification interpretation
> compare against customer expectations
> compare against constraints
> identify and reconcile variances and conflicts
> validate requirements
System Requirements Review

Your mileage may vary; not all projects require every step.

### RE: System Thinking Approach in Writting Aircraft Design Requirements

(OP)
Sounds very effective process. I'm reflecting on each step, perhaps I can try this with a simple casestudy.

Thank you very much.

### RE: System Thinking Approach in Writting Aircraft Design Requirements

Effective, possibly; costly, definitely.

Very few organizations can stand to spend that much up front, particularly when there's a standing army of designers chomping at the bit to start design.

### RE: System Thinking Approach in Writting Aircraft Design Requirements

(OP)
Is your process refers IEEE 1220 standard or ISO/CEI 26702? How did I miss this !!!

Thank you once again

### RE: System Thinking Approach in Writting Aircraft Design Requirements

Our process is an aggregation of a bunch of different standards, including some of those mentioned.  However, it is not linked specifically to any one standard.

### RE: System Thinking Approach in Writting Aircraft Design Requirements

(OP)
So far so good. I've improved my requirement formulation via your 12 activities on a simple case study.
Some concerns on emergent behavior of the system, is there a way to capture the strong and weak emergence properties of the system?

### RE: System Thinking Approach in Writting Aircraft Design Requirements

Technically, properties fall into 3 broad categories, required, forbidden and irrelevant.  If they required, then they are fundamentally specified or are derived.  If they are irrelevant, then you don't care, and the specifications are silent on the subject.  If they are forbidden, then they are either an external or derived constraint, and the specification should state so.

Obviously, some properties are somewhere on the spectrum, and the systems engineer or designer must trade off against desirable properties that decrease when the undesirable properties also decrease.  Ultimately, that trade shows up as an explicit requirement, or as a design decision.

Our SE group is fond of, but not always remembering to, developing design decision memos, which explicitly state, outside of the requirements, what design decisions were made, and their rationales.  Additionally, some of that might be captured in the specification interpretation document, because the specifications are either unclear, ambiguous, or just plain silent.

Since my organization often gets formal, written requirements from the customer, we must often create SIDs to capture our understanding of what is often a woefully inadequate or incomplete or unclear specification from that customer.  You may ask why the customer wouldn't simply change the requirement when confronted with obvious inadequacies or outright errors?  That may be for reasons of extremely long signature/decision cycles or simple politics.

### RE: System Thinking Approach in Writting Aircraft Design Requirements

(OP)
very clear!!!

With simple techniques defined for each step, it took almost 10 days to complete the job partially and it is still in the process. And this is for a very simple system and indeed painstaking. Your points will aid me further down.

Thank you so much

#### Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

#### Red Flag Submitted

Thank you for helping keep Eng-Tips Forums free from inappropriate posts.
The Eng-Tips staff will check this out and take appropriate action.

Close Box

# Join Eng-Tips® Today!

Join your peers on the Internet's largest technical engineering professional community.
It's easy to join and it's free.

Here's Why Members Love Eng-Tips Forums:

• Talk To Other Members
• Notification Of Responses To Questions
• Favorite Forums One Click Access
• Keyword Search Of All Posts, And More...

Register now while it's still free!