1. “Challenge the Dominant Paradigm”
Mission EngineeringTM - a transformational business analysis and system engineering approach
“Challenge the Dominant Paradigm”

2. Mission Engineering (ME) Defined
ME is an advanced requirements gathering and analysis method
ME is focused on capturing & translating the ‘intent’ of the customer’s mission needs into implementable system/software/data requirements
ME reduces interpretation of textual requirements by using visually robust products as the central communication device
ME provides notational linkage of the implementable requirements to the originating customer mission needs
ME is an engineering method that can be used with any system or software engineering processME is a repeatable method where all of the processes and artifacts can be used, or it can be tailored with only a subset of the overall method
ME analysis and artifacts support acquisition analysis, BOE costing and portfolio management.
Mission Engineering is, simply put, a very rigorous requirements analysis methodology. For example, if a program has to comply with CMM or CMMi, then the KPA for requirements analysis can use the Mission Engineering methodology. Additionally, it also provides a lot more engineering input than just requirements. Output from the Mission Eng method will feed virtually all process areas within system and software engineering lifecycles.
The focus of using Mission Eng is for the analysts to get to the intent of the domain need, and then to accurately articualte that intent into implementable engineering requirements and conceptual design.
ANALYSIS, COMMUNICATION & UNDERSTANDING

3. Why Was Mission Engineering Developed?
Deliver systems with greater user satisfaction
Speed up design and development time
Provide analytical defendable traceability from customer need to architecture design
Provide a better way to derive/illustrate COTS/GOTS/Technology integration requirements
Identify the risk…technical, operational and programmatic
Provide a more integrated and holistic view of the enterprise
Customers spend millions of dollars…purchase the best hardware, the best software, and the best engineers…and if the users don’t like or use the system…the system development was a failure

4. Mission Engineering and the DODAF Pyramid
Operational View
Identifies What Needs to be Accomplished and Who Does It
What Needs to Be Done
Information Exchanges Required to Get It Done
Who Does It
Operational Requirements and Capabilities
Systems that Support the Activities and Information Exchanges
Basic Technology Supportability
New Technical Capabilities
Specific System Capabilities Required to Satisfy Information exchange
Systems View
Relates Systems and Characteristics to Operational Needs
Technical Standards View
Prescribes Standards and Conventions
Technical standards Criteria Governing Interoperable Implementation/Procurement of the Selected System Capabilities

5. Community Community Program Office Mission Engineering CONCEPT
Community Analysis
Community Model
Interface Transaction Inventory
Visual Con Ops
Advocacy Products - CV
Business Rule Conflict
Risk Areas & Opportunities
Prioritization of EAR - Activities
Community
Client Information
Existing Ops Cons & Req Legacy systems Constraints
Mission Engineering
Community
Community Feedback
Launch & Learn via Portal
Operations Analysis
Enterprise Activity Roadmap
Concept Visualization Mission Process Mapping Technology Mapping
INPUT To…
Fault Isolation
Problem Isolation
Systems Analysis
Multiple Dimensional Requirement's Reqt’s Mapping to Activities
Derive Requirements
Risk Analysis
Requirement's Visualization
Operational Scenarios
CONCEPT
OPERATIONS
INPUT To…
ICD Identification
Actor/Organization Interfaces
INPUT To…
Field Documentation (Manuals)
Training Material Development
SPECIFICATION
INPUT To…Detail Design
Actor Inventory
Visualization & GUI design
Use Case Description
Activity / Sequence / etc…UML
COTS/GOTS/Custom Code Integration
Opportunities
DEPLOYMENT
Used To…
Validate design
ARCHITECTURE
VERIFICATION
INPUT To…
COTS/GOTS Integration
DESIGN
INPUT To…
Test Plan & Procedures
INTEGRATION
DEVELOPMENT
TEST
ACQUISITION / CONSTRUCTION

6. Mission Engineering – What it will do, what it won’t do
Mission Engineering WILL:
Provide your program with enough functional requirements and preliminary design content to get you to your programs Preliminary Design Review (PDR) gate
Provide your program with a ‘conceptual’ design of the system/application
Provide your program with high level business process flows that are linked to requirements
Provide data architects with a preliminary first draft data dictionary
Provide software architects with a complete workflow analysis, functional behaviors and interface points for COTS integration
Provide Business Process Analysts with lower level (level 5) process flows and business rules
Provide Test engineers with a first draft of the system test procedures
Provide Test engineers with multiple Mission and Capability functional threads
Provide Trainers with input to both standup and/or computer based training course material development
Provide system engineers and architects with preliminary interface definitions and architectural behaviors
Provide stakeholders (Customers) with an easily understood view of what will be developed and how it will be used
Provide your program high quality, rigorous, analytical business and engineering content…if you have the right team
Mission Engineering will NOT:
Provide your program with detailed design; e.g. logical model, physical model, UML
Provide you with ‘system’ level requirements; e.g. –ilities (maintainability, scaleability, etc), network protocals, etc
Provide you with hardware requirements
Provide you with network requirements, etc
Be useful to the program if you do not have the right team working on the analysis.

7. Phases of Mission Engineering
Customer Need Engineering Reqt’s
ANALYSIS, COMMUNICATION & UNDERSTANDING

8. Mission Engineering Phase I – Community Analysis Process
INPUTS
Goals
Processes
Products
Existing Documents
User Types
TEAM
Customer
Domain Analysts
Mission Eng Analyst
Desktop Multimedia Producer
Core Products
Community Interface Model
Transaction Inventory
Actor Inventory
Background Information
Additional Products
Visual Operations & Requirements Spec
Concept Visualizations
Advocacy Material
Requirements
Standardized Architectural Views e.g. C4ISR
Value Engineering
Input To:
Arch Analysis
Program Marketing
Training
Reqt’s Analysis
ICD Development

9. Community Analysis – Advocacy & Understanding
Analyze and Define:
Mission Customers, Mission Partners
Mission Roles: Analyst, Consumer, Collection Manager
Information transactions
Information developed & delivered among roles
Value Chain & Capabilities
ME Traceability
Develop Information Transaction Inventory
EAR Activity
When transacted
Network Domain
Transaction ID
EAR Service Area
Develop Concept Visualization
Info Received From
Info Type
Info Sent From
Develop Community Model
Develop understanding and advocacy for Customer's Goals and Transformation

11. Phase 1 Summary of content
At this point, we should have developed:
First draft of community model
Beginning of the actor list
Beginning of the tools (COTS/GOTS) list
Supplier list
Customer list
Partner list
Information Transaction table
TIME Elapsed: 1 to 3 weeks
Additionally, if the program desires, we should also begin the story board for the concept visualization work

12. Mission Engineering Phase II – Operations Analysis Process
TEAM
Customer
Domain Experts
Business Analysts
Mission Eng Analyst
Information Architect
System Arch
Additional Products
Business/Mission Process Analysis
Technology Evaluation Matrix
Mission Threads/Product Threads
Actor and Activity Matrix
Requirements Analysis
C4ISR Views
Output To:
Community Model Updates
ME Phase 3
BPR activities
Program Marketing
Strategic Acquisition
Core Products
Enterprise Activity Roadmap
Activity Goals & Descriptions
Capability Descriptions
Enterprise Activity Function Map
Mission Process Models

13. The Enterprise Activity Roadmap is developed in an Integrated Product Team environment
Work with stakeholders on the mission of the organization and the product & service value chain scenarios from a task flow perspective.
Identify high level “Mission or Operational” Service Areas
Identify “functional activities” involved within the system workflow…logical groupings
Create an inventory illustrating the actor functional activities required in the performance of their mission or in production of a product or service

14. Enterprise Activity Roadmap defined…
Operational Services
Functional Activities
Increment 1
Increment 2
Increment 3
Commercial Tool A
Commercial Tool B
Legacy App 1
Activity Name:
Activity Code:
Actor Class;
Actor:
Pre-:
Post-:
COTS/GOTS:
Arch service:
Source:
No Tool ID

15. Functional Breakdown of COTS/GOTS tools
There are two ways to map tools to the activity roadmap; complete tool or tool function.
For instance, in the illustration below, lets assume the yellow icon represents the Microsoft Office Tool.
As the MS Office tool, you can see exactly what activities have been identified that the MS Office tool will be used or integrated.
Or, if you break MS Office into its high level component functions, (e.g. , Notes, Tasks, Contacts, Calendar), you would see which activities will use MS Office, but, you could also then see which component of MS office as well.
You would have:
OL-C – outlook-calendar
OL-E – outlook-
OL-N – outlook-notes
Add COTS/GOTS component as an attribute to activity

16. Mission Process Map (MPM) Overview
A Mission Process Map (MPM) shows the BPR results in the context of a Mission thread. The steps in the MPM are mapped directly to the Activities in the Roadmaps and Service Areas in the Community Model
Activities mapped to the Roadmap
Service Area Identifier

17. Phase 2 Summary of content
At this point, we should have:
First draft of every enterprise ‘segment’ activity roadmap
Full definition of each service area
Written all goals and descriptions for all activities
Begun to prioritize the activities per client needs, implementation schedule and funding
A number of Mission Process Maps completed, may include state changes
A candidate set of Capability Vignettes completed or identified
Full description of each actor role
Mapped actor roles to activities
Functional breakdown of tools
Mapped Tools/functions to activities
Listed ‘source’ for each activity, e.g. document, legacy, person
Final draft of the Community model with Service areas shown
TIME Elapsed: 2 to 6 weeks

18. Mission Engineering Phase III – Systems Analysis Process
TEAM
Domain Experts
Architects – SW, DB, SYS, SEC, Info
Mission Eng Analyst
Mission Eng Facilitator
Additional Outputs
System Requirements
Enterprise Requirements Documents
Business Process Analysis
Requirements Mapping
Requirements Traceability Matrix
Requirements Visualization
Information Architecture
Output To:
Tool Evaluation
Testing Procedures
Training
Architecture
Field Documentation
SW Detailed Design
DB Design
BPR
Core Outputs
Functional Requirements
Data Elements and Attributes
Multidimensional Requirements View
Data Tables/Relationships
Business Rule to Function Mapping

19. System Requirements – Workflow, Interfaces, Behaviors
Multi-Dimensional Requirements View (MRV)
Created in an IPT environment of stakeholder, developers and integrators
Captures the activity workflow of people and systems
Captures the behaviors between functions, applications and data
Derives new requirements from integrated architecture analysis
Provides framework to map existing legacy requirements
Requirements Visualization
EAR
MRV
Service Area
Define operational functional steps – activity workflow
Activity
Map ops functions to system layer applications
Web viewable; DOORS, RequistPRO
Map data created & data read to functions
Derive new requirements, map existing requirements
Central Repository
Derive and/or Map business rules to functions

20. MRV ‘SET’….For each functional activity…

22. MRV to RV development…”test drive the requirements prior to development”

23. MRVs explained & link to rest of program
Business Segment User Role
Business Segment Activity
Business Segment Service Area
Activity Functional Steps
Architecture Segments – Application COTS/GOTS interface
Data Store Name – Read / Write
Activity Functional Requirements
Activity Function Business Rules
Maps Activity / Requirements to Capabilities on CDR
Criteria for Tech Evaluation
Input to Software Design
Input to Test Procedures
Input to Training Scenarios
Input to User Experience
Input to Information Architecture
Input to TE Business Process Analysis
DOORS Database

24. Phase 3 Summary of content
At this point, you should:
Begin development of the integrated Ops and Requirements Document
Completed a first draft of the prioritized MRVs
Defined performance goals for each MRV to the level required
Can begin development of the data dictionary from each MRV
Analyze the COTS/GOTS functional interfaces for integration
Updated the Community model
Updated the Activity Roadmaps
Updated the Business process flows
TIME Elapsed: 1 to 3 MRVs per day

25. The Linkage Multidimensional Requirements View (MRV) Community Model
Requirements to Architecture View (RAV)
Activity
Perform Ballistic Missile Optimization
ACT Code: OP-PBMOP
Actor: PA, PL
Arch CSCI: OPTIMZ
COTS/GOTS: ILOG, IMEA, JMEM, MEM, MGPS
CSCs
Mission Ops Activity Roadmap
Missile Defense Mission Thread
Why the plus products? Visibility into the program, visibility into the design, and visibility into how a user will interact with ISPAN. Our plus products, artifacts of the Mission Engineering Methodology, help us to Analyze, Understand and Communicate how the ISPAN system will meet the needs of its users and the community. DODAF does a great job at standardizing views that can be shared across the DOD community for integration. But, we felt that we needed to add a few new views to the DODAF framework to provide additional clarity and insight into the ISPAN Program, and to help us design a system that deliver greater usability. We analyzed the SOO and the TRD and derived our high level AV-1 Community Model. From our analysis of the SOO and TRD, coupled with our experience in developing both Commercial and Government Portals, we were were able to create our Activity Roadmaps for Mission Ops, IT Mgmt and Core services. Each activity has a one-for-one relationship to our Multidimensional Requirements Views, and from there we can derive and create Mission Threads, Prototypes, CSCI Structures and all of the required UML views needed for our detailed design. Let me show you a little more detail….next slide….
MCP
0042 Deliver Basic Detailed Planning Optimization

26. Multidimensional Requirements View (MRV) Requirements Viz & Tech Demos
Communications
NGA Community Model
Activity Roadmaps
User Groups from NGA Mission Segments; GIO, Corp, Funct, ITM
Users work with Geoscout to determine activity and service needs
Business Processes from each Mission Segment
1 for 1 relationship of user activity to MRV
Users support Business Process Analysis & Mission Process Mapping
Users drive Ops function needs in MRV-member of design team
Stakeholder Insight
Users validate Information Architecture
Users evaluate prototypes and tools
Multidimensional Requirements View (MRV)
Requirements Viz & Tech Demos
Activity Mapping to Mission Threads & Business Processes
NSGI Site Map

27. Mission Engineering Summary
Now
Next
After Next
Capability Delivery Roadmap
BLOCKS
Capabilities
User & Stakeholder
Input
Business Cases
Developer Input & Ideas
Legacy System
Requirements
Strategic Analysis
Capability Value Chains
INPUT
PRESENTATION & ANALYSIS
User Validated Operational Concept
Training Input
Requirement’s Validation: Mapping Requirements to Functionality
Information Architecture
Business Objects
Use Case Input
Activity Diagrams
Interface Design
Sequence Diagrams
Risk Identification
Technology Evaluations
Etc…
Test Plan & Procedures
Deferred / Derived
Requirements
BPR Tasks
OUTPUT
Converting Needs into Requirements , Communicating Results

28. Booz Allen Has Successfully Applied Mission Engineering to a Wide Range of Clients and Products
Project Name
Client
Project Name
NGA
Integrated Exploitation Capability (IEC)
NRO
XOComm
Air Force
Space Based Blue Force Tracking
NGA
Big Idea
DISA
Traces2
NSA
Stone Mason
Joint Staff
Airborne ISR Requirements Based Allocation
DIA
HUMINT/CI Comms Architecture Eval
DIA
JIVA
DISA
Meteorological Info System Terminal (MIST)
SPAWAR
Strike Fighter Training System (SFTS)
NGA
GeoScout

29. Value and benefits of using Mission Engineering
Fosters Communication and Understanding
Translates mission needs into engineering requirements
Reduces interpretation of textual requirement
Illustrates user functions within work flow
Illustrates COTS/GOTS/Custom code integration/interfaces
Supports the early identification of risk; technical, business and program
Supports product/artifact reuse across the system/software engineering lifecycle
Support the development of test and training material
Supports development of DODAF views