Developing originating requirements: defining the design decisions

Abstract

A process for developing originating requirements is described.Originating requirements are the cornerstone upon which the systems engineering process is based. These requirements do not just appear, but involve a great deal of work using several important systems engineering tools: the operational concept, the external systems diagram, and the objectives hierarchy. In addition, this work provides a unified perspective on what requirements are, an appropriate taxonomy for originating requirements and an outline of the originating requirements document. This paper should serve as a discussion point for refining what may be the most important systems engineering activity. Pragmatic Principle 1 [INCOSE]Know the problem, the customer, and the consumer 1. Become the "customer/consumer advocate/surrogate" throughout the development and fielding of the solution. Begin with a validated customer (buyer) need-the problem.3. State the problem in solution-independent terms. Know the customer's (or buyer's) mission or business objectives.5. Don't assume that the original statement of the problem is necessarily the best, or even the right one.6. When confronted with the customer's need, consider what smaller objective(s) is/are key to satisfying the need, and from what larger purpose or mission the need drives; that is, find at the beginning the right level of problem to solve.7. Determine customer priorities (performance, cost, schedule, risk, etc.).8. Probe the customer for new product ideas, product problem/shortfalls, identification of problem fixes. 9. Work with the customer to identify the consumer (user) groups that will be affected by the system.

Set‐based design: The state‐of‐practice and research opportunities

“…Using this logic, we are able to include a large number of relevant documents within this review that may have otherwise been missed, enabling a more comprehensive assessment of SBD. We refer to this set of documents as Group B from this point forward 1,66–122 . We provide the complete listing for all Group B documents in Table 2.…”

Establishing and processing client requirements-a key aspect of concurrent engineering in construction

“…1994 ); and stated in a format that makes it easy to trace and correlate design decisions to the original intentions of the client ( Perkinson et al . 1994 ; Buede 1997). …”

“…This can be accomplished if client requirements are: precisely defined to remove any ambiguities (Gause & Weinberg 1989;Kott and Peasant 1995); reflective of all the perspectives and priorities represented by the client; stated in a solution-neutral format (i.e. without reference to a design solution) that can be understood by the different disciplines working on a project (Perkinson et al 1994); and stated in a format that makes it easy to trace and correlate design decisions to the original intentions of the client (Perkinson et al 1994;Buede 1997).…”

2 A Requirements Driven Approach to Synthesis of Military Satellite Communications Payloads

“…The common situation is that the client's requirements, including estimated communication traffic, are vague and possibly contradictory. Requirements generation is the subject of many papers such as (Buede 1997) and (Carson 1995) and is not described here. Examples of partially defined requirements are shown along the top of the figure in italics.…”