Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations cowski on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

System Thinking Approach in Writting Aircraft Design Requirements

Status
Not open for further replies.

PriyaAlexander

Aerospace
Jul 26, 2011
14
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
 
Replies continue below

Recommended for you

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
 
"a fuzzy or a vague information about the customer need" ... the root of the problem.

 
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.

TTFN

FAQ731-376
Chinese prisoner wins Nobel Peace Prize
 
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.
 
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.

TTFN

FAQ731-376
Chinese prisoner wins Nobel Peace Prize
 
Sounds very effective process. I'm reflecting on each step, perhaps I can try this with a simple casestudy.

Thank you very much.
 
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.

TTFN

FAQ731-376
Chinese prisoner wins Nobel Peace Prize
 
Is your process refers IEEE 1220 standard or ISO/CEI 26702? How did I miss this !!!

Thank you once again
 
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?
 
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.

TTFN

FAQ731-376
Chinese prisoner wins Nobel Peace Prize
 
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
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor