Systems Engineering - ATI
Systems Engineering - ATI
Systems Engineering - ATI
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Systems</strong> <strong>Engineering</strong> - Requirements<br />
NEW!<br />
January 11-13, 2011<br />
Beltsville, Maryland<br />
March 22-24, 2011<br />
Beltsville, Maryland<br />
$1690 (8:30am - 4:30pm)<br />
"Register 3 or More & Receive $100 00 each<br />
Off The Course Tuition."<br />
Summary<br />
This three-day course provides system engineers,<br />
team leaders, and managers with a clear<br />
understanding about how to develop good<br />
specifications affordably using modeling methods that<br />
encourage identification of the essential characteristics<br />
that must be respected in the subsequent design<br />
process. Both the analysis and management aspects<br />
are covered. Each student will receive a full set of<br />
course notes and textbook, “System Requirements<br />
Analysis,” by the instructor Jeff Grady.<br />
Instructor<br />
Jeffrey O. Grady is the president of a System<br />
<strong>Engineering</strong> company. He has 30 years<br />
of industry experience in aerospace<br />
companies as a system engineer,<br />
engineering manager, field engineer,<br />
and project engineer. Jeff has authored<br />
seven published books in the system<br />
engineering field and holds a Master of<br />
Science in System Management from USC. He<br />
teaches system engineering courses nation-wide. Jeff<br />
is an INCOSE Founder, Fellow, and ESEP.<br />
What You Will Learn<br />
• How to model a problem space using proven<br />
methods where the product will be implemented in<br />
hardware or software.<br />
• How to link requirements with traceability and reduce<br />
risk through proven techniques.<br />
• How to identify all requirements using modeling that<br />
encourages completeness and avoidance of<br />
unnecessary requirements.<br />
• How to structure specifications and manage their<br />
development.<br />
This course will show you how to build good<br />
specifications based on effective models. It is not<br />
difficult to write requirements; the hard job is to<br />
know what to write them about and determine<br />
appropriate values. Modeling tells us what to write<br />
them about and good domain engineering<br />
encourages identification of good values in them.<br />
Course Outline<br />
1. Introduction<br />
2. Introduction (Continued)<br />
3. Requirements Fundamentals – Defines what a<br />
requirement is and identifies 4 kinds.<br />
4. Requirements Relationships – How are<br />
requirements related to each other We will look at<br />
several kinds of traceability.<br />
5. Initial System Analysis – The whole process<br />
begins with a clear understanding of the user’s needs.<br />
6. Functional Analysis – Several kinds of functional<br />
analysis are covered including simple functional flow<br />
diagrams, EFFBD, IDEF-0, and Behavioral Diagramming.<br />
7. Functional Analysis (Continued) –<br />
8. Performance Requirements Analysis –<br />
Performance requirements are derived from functions and<br />
tell what the item or system must do and how well.<br />
9. Product Entity Synthesis – The course<br />
encourages Sullivan’s idea of form follows function so the<br />
product structure is derived from its functionality.<br />
10. Interface Analysis and Synthesis – Interface<br />
definition is the weak link in traditional structured analysis<br />
but n-square analysis helps recognize all of the ways<br />
function allocation has predefined all of the interface<br />
needs.<br />
11. Interface Analysis and Synthesis – (Continued)<br />
12. Specialty <strong>Engineering</strong> Requirements – A<br />
specialty engineering scoping matrix allows system<br />
engineers to define product entity-specialty domain<br />
relationships that the indicated domains then apply their<br />
models to.<br />
13. Environmental Requirements – A three-layer<br />
model involving tailored standards mapped to system<br />
spaces, a three-dimensional service use profile for end<br />
items, and end item zoning for component requirements.<br />
14. Structured Analysis Documentation – How can<br />
we capture and configuration manage our modeling basis<br />
for requirements<br />
15. Software Modeling Using MSA/PSARE –<br />
Modern structured analysis is extended to PSARE as<br />
Hatley and Pirbhai did to improve real-time control system<br />
development but PSARE did something else not clearly<br />
understood.<br />
16. Software Modeling Using Early OOA and UML –<br />
The latest models are covered.<br />
17. Software Modeling Using Early OOA and UML –<br />
(Continued).<br />
18. Software Modeling Using DoDAF – DoD has<br />
evolved a very complex model to define systems of<br />
tremendous complexity involving global reach.<br />
19. Universal Architecture Description Framework<br />
– A method that any enterprise can apply to develop any<br />
system using a single comprehensive model no matter<br />
how the system is to be implemented.<br />
20. Universal Architecture Description Framework<br />
– (Continued)<br />
21. Specification Management – Specification<br />
formats and management methods are discussed.<br />
22. Requirements Risk Abatement - Special<br />
requirements-related risk methods are covered including<br />
validation, TPM, margins and budgets.<br />
23. Tools Discussion<br />
24. Requirements Verification Overview – You<br />
should be basing verification of three kinds on the<br />
requirements that were intended to drive design. These<br />
links are emphasized.<br />
Register online at www.<strong>ATI</strong>courses.com or call <strong>ATI</strong> at 888.501.2100 or 410.956.8805 Vol. 104 – 23