Line 31: |
Line 31: |
| | | |
| == Primary Roles and Responsibilities == | | == Primary Roles and Responsibilities == |
− | === Plan and implement the RobotX project === | + | ===Requirements Management=== |
| + | Requirements are the foundation of the program and requirements management process helps ensure delivery of capability that meets intended mission performance objectives. |
| + | Performance objectives are identified in operational terms at the system level during implementation of the Requirements Definition and Requirements Analysis processes. |
| + | |
| + | The Subsystems Integrator these responsibilities: |
| + | *maintain a current and approved set of requirements |
| + | *thoughtful analysis and management of requirements insuring for system sustainability |
| + | *synchronization with the program’s Configuration Management process to mitigate unintended or unanticipated consequences due to change |
| + | *rigorous documentation of changes to the system performance specification |
| + | |
| + | ===Process Responsibilities=== |
| + | The PM should keep leadership and all stakeholders informed of cost, schedule, and performance impacts associated with requirement changes and requirements growth. |
| + | |
| + | Through the Requirements Management process, the Systems Engineer tracks requirements changes and maintains traceability of end-user needs to the system performance specification and, ultimately, the delivered capability. |
| + | |
| + | As the system design evolves to lower levels of detail, the Systems Engineer traces the high-level requirements down to the system elements through the lowest level of the design. |
| + | |
| + | The Systems Engineer also establishes and maintains a Requirements Traceability Matrix (RTM) that captures all requirements in the system performance specification, their decomposition/ derivation and allocation history, and rationale for all entries and changes. |
| + | |
| + | ===Risk Management=== |
| + | The Systems Engineer is responsible for prioritizing identified technical risks and developing mitigation actions. The Program Manager reviews and approves the risk priorities and mitigation plans and ensures that required resources are available to implement the mitigation plans. |
| + | |
| + | Activity |
| + | Intent Is to Answer the Question |
| + | |
| + | Risk Identification |
| + | |
| + | What can go wrong? What is the future root cause? |
| + | |
| + | Risk Analysis |
| + | |
| + | How big is the risk? What is the probability of occurrence? What is the consequence of occurrence? |
| + | Risk Mitigation |
| + | |
| + | What is the program approach (cost, schedule, and technical) for addressing this potential root cause or unfavorable consequence? |
| + | |
| + | How can the planned risk mitigation be implemented? How do we ensure that successful risk mitigation occurs? |
| + | |
| + | Risk Monitoring |
| + | |
| + | How are risk management plans going? |
| + | |
| + | ===Configuration Management=== |
| + | Configuration management is the means by which the results of the systems engineering effort are documented and tracked as changes occur. |
| + | |
| + | The Configuration Management process allows technical insight into all levels of the system design and is the principal methodology for establishing and maintaining consistency of a system’s functional, performance, and physical attributes with its requirements, design, and operational information throughout the system's life cycle. |
| + | |
| + | |
| + | Configuration Management consists of five interrelated functions that, when collectively applied, allow the program to maintain consistency between product configuration information and the product throughout its life cycle. |
| + | |
| + | The following are the five Configuration Management functions: |
| + | |
| + | Configuration Management Planning and Management is a formal document and plan to guide the Configuration Management program that includes items such as: |
| + | |
| + | Personnel |
| + | Responsibilities and Resources |
| + | Training requirements |
| + | Administrative meeting guidelines including a definition of procedures and tools |
| + | Baselining processes |
| + | Configuration control and Configuration status accounting |
| + | Naming conventions |
| + | Audits and Reviews |
| + | Configuration Identification |
| + | Configuration Change Management |
| + | Configuration Status Accounting |
| + | Configuration Verification and Audit |
| + | |
| + | ===Interface Management=== |
| + | The Interface Management process helps ensure that developers document all internal and external interface requirements and requirements changes in accordance with the program’s Configuration Management Plan. |
| + | |
| + | Developers also should communicate interface information to their counterparts responsible for affected systems and system elements, and should plan for coherent testing to verify expected performance and ultimately operational performance. |
| + | Interface management is an iterative process. As knowledge of the system and system elements increases during design activities, verifiable lower-level requirements and interfaces are defined and refined. |
| + | |
| + | Developers should assess impacts of the originally defined capabilities and interfaces, performance parameter thresholds and objectives, and the overall system when defining and modifying interfaces. |
| + | |
| + | important that the nature of the interfaces be carefully documented to ensure proper function and interoperability. |
| | | |
| ==Integration Plan== | | ==Integration Plan== |