Introduction

The international council of systems engineering (INCOSE) has created 14 processes that a systems engineer could do to to develop a systems along with the other skills and jobs.

The first process is Business or mission analysis process which collects information on what we are going to build based on what the enterprise/business/money people want.

Inputs > Processes > Output

Inputs	Processes	Output
– Organisation strategic plan – ConOps – Source documents – Lifecycle constraints – Project constraints – Stakeholder requirements traceability	> Prepare for business or mission analysis > Define the problem or opportunity space > Characterise the solution space > Evaluate alternative solution classes > Manage the business or mission analysis	= Business or mission strategy = Major stakeholder identification = Preliminary lifecycle concepts = Problem or opportunity statement = Business requirements = Alternative solution classes = Preliminary validation criteria = Preliminary MOE needs = Preliminary MOE data = Business requirements traceability = Business or mission analysis record

Needs not Wants

Before we get to into the inputs > process > outputs of this stage we need to clear up some words to avoid confusion down the road or even write now. First wants and needs. A Want is something that we would like to have whilst a need is something we have to have. Systems Engineers only care about needs not wants – we are engineering here people. The reason for the clarity on this is from a need (a must) we can develop a requirement – it needs to do this or something bad happens/we miss out on something/the nasty man drinks our milkshake (look it up).

Needs to Requirements

Requirements are the foundations for the systems that will be built. We are able to manage the requirements through breaking them down into 5 levels.

Business Level	Need	Requirements	Specification Document	INCOSE Process
Enterprise	Enterprise needs	Enterprise Requirement to meet strategy	Overall business strategy
Business Management	Business unit needs	Business unit requirements to improve business	Business requirements specification (BRS)	Business or Mission Analysis
Business Operations	Stakeholder needs	Operations requirements to improve operations	Stakeholders requirements specification (StRS)	Stakeholders needs and requirements
System	System needs	System requirements needed to make it operate successfully	System requirements specification (SyRS)	System requirements + Architecture definition
System Element	System Element need	System element requirements that it needs to perform to meet system need	System element requirements specifications (SERS)	System requirements + Architecture definition

For the majority of SE work that you will see you won’t have to deal with all these levels and certainly not at the same time. The enterprise level is normally set for a couple of years or longer depending on the industry. The system element is often set either by a component prebuilt or will be defined as the system’s elements are built out.

The key to needs and requirements is to keep track of them and who they come from and why. This can be done with a simple form of stakeholder request – reason – date. When we start this don’t get sucked into the detail as we’ll get that as we go.

Inputs

Organisation strategic plan

The organisation you are working with will have some idea on what they want to do and a way of achieving it. This doesn’t have to be something big and fancy but it does need to make sense and the leaders of the organisation have to stick to it or make changes when things change. This is normally a presentation with some form of support document with numbers to explain the intention.

ConOps

There are two similar words when it comes to trying to capture at the high level what we are trying to achieve in the ConOps or concept of operations is often used along side “operational concept”.

ConOp (concept of operations) – description of how, at an organisational level, the leadership intend the organisation to operate. This includes a description of the organisation’s assumption or intent in regard to operation with the existing systems and future one. Due to the current and future states the ConOp is a strategic document.

OpsCon (operational concept) – describes how the system work from the operator’s perspective. The OpsCon summarises the needs, goals, and characteristics of the system’s user and operator community, along with the system context and system interfaces.

Source documents

The organisation will have all sorts of document on the system of interest (SOI) and other artefacts that will be useful when setting the business or mission intent to develop a new system.

Lifecycle constraints

Before starting the development the system will have a natural lifecycle for a whole bunch of reasons that are defined by the environment that system is in and how it is used. Good to set this early including the cost of running the system over the period and any disposal costs if there are any.

Project constraints

Similar to the system lifecycle the project will be limited by time, skill, environment and probably, just probably money. The project constraints will affect the product development approach.

Stakeholder requirements traceability

Elaboration

1.1. Nominate Major Stakeholder

1. Business or mission analysis process > 2. Stakeholder needs and requirements process