1 / 6

Requirements Definition

Requirements Definition. Marcin Pilinski Chris Koehler Colorado Space Grant Consortium. Requirements Level. Anatomy of Requirements. Mission Statement (aka Mission Goal) A very general description of the problem being addressed by the system. G. Step 1: General definition .

iain
Télécharger la présentation

Requirements Definition

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. Requirements Definition Marcin Pilinski Chris Koehler Colorado Space Grant Consortium

  2. Requirements Level Anatomy of Requirements Mission Statement (aka Mission Goal) A very general description of the problem being addressed by the system. G Step 1: General definition. Subjective description and a few numbers Mission Objectives 3 to 5 general statements elaborating the Mission Statement. O Objective Requirements Quantify each objective: when, what, where, for how long 0 Step 2: Numbers and ranges. Focus in on defining the problem. System Requirements The system as a whole must perform to this set of specifications in order to meet the objective requirements, mission objectives, and mission statements 1 Subsystem Requirements Each subsystem must perform to these specifications in order to meet the criteria defined above. This part is done separately for each subsystem i.e. power, mechanical, computer, science, thermal. Step 3: Subsystems. Repeat step 2 for every subsystem, tracing from system requirements. 2

  3. An Example from Class: Icarus Goal (G1) The BalloonSat Aquintus shall ascend to an altitude of approximately 100,000 feet to carry out scientific experiments that will measure tilt of the satellite, forces acting upon it, wind speed, and solar energy to better understand the conditions in which high altitude observatories would be in. Goal (G1) The BalloonSat Aquintus shall ascend to an altitude of approximately 100,000 feet to carry out scientific experiments that will measure tilt of the satellite, forces acting upon it, wind speed, and solar energy to better understand the conditions in which high altitude observatories would be in. Goal (G1) The BalloonSat Aquintus shall ascend to an altitude of approximately 100,000 feet to carry out scientific experiments that will measure tilt of the satellite, forces acting upon it, wind speed, and solar energy to better understand the conditions in which high altitude observatories would be in. O1 (comes from G1) Construct BalloonSat to improve understanding of HA conditions at X-100,000 ft for under $YYY dollars by MM/DD/YYYY. O2 (comes from G1) Measure tilt in one axis and forces in the range of X mN to YmN as a function of altitude in the range of X-100,000. O3 (comes from G1) Measure wind speed perpendicular to one face of the BalloonSat and solar energy as a function of altitude.

  4. 2. Objective Requirements and System Requirements Before Starting the next level… (system level or level 1 in this scheme) Ex. • A requirement must be NECESSARY,must have a clear need • A requirement must be TRACEABLE • A requirement must HAVE A METHOD OFVERIFICATION • A requirement must be ATTAINABLE • A requirement must be CLEAR

  5. 2. Objective Requirements and System Requirements General Guidelines and Wisdom For the Young Engineer • A requirement defines the “WHAT” not the “HOW” • “HOW” defines the implementation, i.e. the solution • “WHAT” defines the functionality which is the first thing you need before starting anything! • A requirement has some standardized wording • shall: denotes a requirement which must be verified, use it in every requirement “there is no try, only do or do-not” • should: denotes a goal for which a best effort will be made • will: denotes a factual or explanatory statement • A requirement is succinct, strong, and gets to the point fast • Avoid “or” statements and “if” stipulations • No wordiness, a brief statement saying WHAT the system shall do. • DO NOT use the following words or ones like it: A FEW WEASEL WORDS TO AVOID: Adequate, Always, Bad, Better, Clearly, Easily, Efficient, Etc., Every, High, Ideal, Large, Maximize, Maximum, May, Most, Minimize, Minimum, Must, Never, Normal, Rapid, Real-time, Satisfactory, Significant, Simultaneous, Small, Sometimes, Sufficient, User-friendly, Worse… These words introduce ambiguity, doubt, and deception… …an engineer craves not these things.

  6. References “Requirement Weasel Words”, Robert Halligan, Project Performance Pty Ltd “Requirement and Verification”, Whitnell, LASP “UNP Program Management Tips”, Brian Engberg, Air Force Research Laboratory

More Related