1 / 9

Chapter 8: Requirements analysis & allocation (pt. 1)

Chapter 8: Requirements analysis & allocation (pt. 1). ISE 443 / ETM 543 Fall 2013. Requirements analysis and allocation (RAA) is critically important.

kirestin-adkins
Download Presentation

Chapter 8: Requirements analysis & allocation (pt. 1)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 8: Requirements analysis & allocation (pt. 1) ISE 443 / ETM 543 Fall 2013

  2. Requirements analysis and allocation (RAA) is critically important All of the later elements of systems engineering are carried out with one dominant question in mind: Are we in fact satisfying the system requirements in the best possible (most cost-effective) manner? Poor requirements are perhaps most mentioned issue when examining reasons why systems engineering and development efforts ultimately result in lack of performance as well as cost and schedule overruns. RAA must be a central focus for the systems engineering effort.

  3. There are two primary perspectives on RAA in the US • DoD (see also exhibit 8.1, pg. 234) • Define/derive/refine performance requirements (what item must do and how well) • The (systems engineering) process shall define and analyze performance and functional requirements, define and design system elements to satisfy those requirements, and establish the final configuration. • NOTE: adding or changing requirements is a difficult task • NASA (see figure 8.2, and on the following page) • Requirements, in addition to being analyzed, are allocated to system functions and subfunctions.

  4. NASA’s flow down of requirements

  5. There are a number of requirements formats • Your turn ... look at pp. 238 – 242 • NASA EOSDIS • DoD I-CASE • Coast Guard MOISE • Within your group review the format and commentary and identify the key characteristics of how requirements are organized. • Compare your results with one other group and agree on 2 or 3 characteristics to share.

  6. Function based – organized based on system function NASA – based on functionality of the systems; CG – based on product. Either approach is acceptable – base your organization on what makes the most sense. Abbreviations are capitalized. Every subsection has an overview, followed by standards. Headings can start with letters or numbers. key characteristics of requirements formats

  7. How requirements statements are worded is critical • For example, • The most important requirements are stated as “shall,” to indicate mandatory requirements. • The next most important requirements are stated as “shall, where practicable.” • The next most important requirements are stated as “preferred” or “should.” • The next most important requirements are stated as “may.” • Or, • Minimum features • Desirable features • Highly desirable features • The reason for this will become clear when we talk about traceability and allocation next time. • Minimum or mandatory requirements • Optional requirements

  8. Writing appropriate requirements takes practice Your turn ... review the examples on pp 243-244 Identify 2 characteristics of well-written requirements that you believe are important. Share these with one other group and discuss. Agree on 2 or 3 characteristics to share.

  9. Quantitative not qualitative Sets performance boundaries Bullet points when more than one attribute is listed in the requirement key characteristics of requirements statements

More Related