EEE403 Systems Engineering

Notes (3rd 4th wks)

DoD Life Cycle

System System utilization

Concept Retirement
Development Production support
DoD Life Cycle
 System System utilization
Concept Retirement
Development Production support
LIFE CYCLE- INDUSTRY STANDARDs

System System utilization

Concept Retirement
Development Production support
System Life Cycle phases- Technical Processes

14 Technical Processes defined in INCOSE

Utilization
Concept Development System Development System Production Retirement
Support
Business/ Mission Analysis

Sys Reqs
Stakehlder needs /

Integration Transition Operation

Design Definition

Implementation
Definition
Reqs Definition

Disposal
Validation
Architect.
Verification Maintenance
Definition
Evolutionary Spiral
 System Life Cycle

System utilization
Concept System Production Retirement
Development support

Purpose: Reduce Risk

• Define the problem
• Identify need problem space
• Define boundaries
• Develop an acquisiton concept
• Identify potential solutions
• Explore preliminary concepts
• Capture requirements
• Select and define concept
• Estimate cost and schedule
• Estimate total life cycle cost
• Development strategy
 System Life Cycle

System utilization
Concept System Production Retirement
Development support

• Refine requirements
• Create a system design
• Develop and fabricate System
• Conduct verification testing
• Requirements developed for each SOI element
System Life Cycle : System production

System utilization
Concept System Production Retirement
Development support

• Conduct validation testing Setup (produce a few systems)

• Refine production line
• Integrate design changes
• Full scale production
• Begin deploying systems
• the system is produced or manufactured.
System Life Cycle : System production

System utilization
Concept System Production Retirement
Development support

• Utilization Stage: the system is operated in its intended

environment to deliver its intended services.
• Support Stage: the system is provided services that enable
continued operation.
• Retirement Stage: the system and its related services are
removed from operation
System Life Cycle : Another representation
Architecture decomposition and definition

Project
objectives Integration verification and validation
Is this what the project
wanted?

Architecture Integration and validation

Concept
formulation Integration verification and validation Integrate
(is this what we want to build?)

Decompose
and define

Detailed decompose Integration verification and Integrate

and define validation (are these right?)

Design and build the parts

Time
 Vee Diagram

INVESTMENT CONCEPT OPERATIONS AND

DECISION DESIGN MAINTENANCE

SYSTEM VALIDATION PLAN

OPERATIONS SYSTEM
CONCEPT VALIDATION

SYSTEM VERIFICATION PLAN SYSTEM

SYSTEM
VERIFICATION/
REQUIREMENTS
DEPLOYEMENT
SUBSYSTEM
HIGH-LEVEL VALIDATION PLAN SUB-SYSTEM
DESIGN VERIFICATION

UNIT / DEVICE
DETAILED TEST PLAN UNIT/DEVICE
DESIGN TESTING
What are the project objectives?
- Concept formulation PRODUCTION
MANUFACTURE AND
ON-SITE ASSEMBLY
Vee Diagram : Highlights

«V» Model is a clear roadmap for the

success of the system:
• Allows the breakdown of the complex
system into smaller parts,
• Reintegration and reassembly of the
pieces into a cohesive whole,
• traceability, requirements management,
and testing and validation become more
manageable.
• as the pieces are reintegrated into the
whole system, the “V” Model allows for an
iterative process
time
«Scheduled» Vee Diagram
1 System Engineering
Systems overview Lifecycle 11
1
definitions management
3 System Modeling 7 PFR
2 Requirements Languages MBSE Commissioning
Analysis Operations 10
SRR FRR
4 System Architecture 9 Verification and
Concept Generation validation

5 Detailed Design 8 System Integration

Concept generation Interface management
PDR
CDR
6 Design Definition
Multidisciplinary Optimization

12 Production and
Manufacturing
 System Life Cycle and «V» Diagram

System System Utilization

Concept Development Retirement
Development Production Support

INVESTMENT OPERATIONS AND

CONCEPT DESIGN Disposal
DECISION MAINTENANCE
SYSTEM VALIDATION PLAN
OPERATIONS SYSTEM
CONCEPT VALIDATION

SYSTEM VERIFICATION PLAN SYSTEM

SYSTEM VERIFICATION/
REQUIREMENTS DEPLOYEMENT
UNIT / DEVICE
HIGH-LEVEL TEST PLAN SUB-SYSTEM
DESIGN VERIFICATION
SUBSYSTEM
DETAILED VALIDATION PLAN UNIT/DEVICE
DESIGN TESTING
PRODUCTION
MANUFACTURE AND ON-
SITE ASSEMBLY
 System System Utilization
Concept Development Retirement
Development Production Support
 Ch.5:
Techn. Mngmnt
Processes
Ch.4:
Technical Processes
 User Verification Acceptance
Delivery Requirements Tests
process
Verification
System System
Requirements Tests
System
Development
Phase Architectural Verification Integration
Design Tests

SW/HW
maintenance phase Component Verification
Component Bottom-Up Integration of
Development Tests what has been built
Top-Down Definition of
what is to be built
Successful Integration of systems Engineering and Program Management Processes Witte, INCOSE 14th Annual International Symposium Proceedings 2004
Technical Processes
Overview : Technical Process
4.1 Business or Mission Analysis Process
4.2 Stakeholder Needs and Requirements Definition Process Define the requirements
4.3 System Requirements Definition Process for a system
4.4 Architecture Definition Process
4.5 Design Definition Process
4.6 System Analysis Process transform the requirements
4.7 Implementation Process into an effective product
4.8 Integration Process
4.9 Verification Process permit consistent reproduction
4.10 Transition Process of the product where necessary
4.11 Validation Process
4.12 Operation Process Use the product to provide the required services
4.13 Maintenance Process
sustain the provision of those services
4.14 Disposal Process
System Requirements Engineering
• Requirement is a statement tahat identifies a system, product or process,
charactheristic or constraint which is unambiguous, clear, unique, consistent,
standalone (not groped) and verifiable and is deemed necessary for stakeholders
acceptability
• It is challenging, costly and the riskiest step of all.

Requirements engineering also called as:

- System analyist
- Software analyist
- Process analyst
- Project manager
- Business architect
- Process engineer
- Product manager
- Product owner
- Quality assurance analyst
- Consultant
 Requirements-definitions
Need: a thing that is wanted or required. Goals and objectives a business must
achieve, defined at the highest level may include capability needs.
Requirements are formal structured statements that can be verified and validated.
There may be more than one requirement defined for each need
NASA: Requirements describe the necessary functions and features of the
system we are to conceive, design, implement and operate.
• Performance
• Schedule
• Cost
• Other Characteristics (e.g. lifecycle properties)
Specification
Specifications are collection of requirements.
Requirements :are the things we need to do in order to achieve a need.
Needs : goals and objectives a business must achieve

Requirements:
traces back to user/stakeholder needs
traces forward and across to all other domains
 Without requirements
• Developers and designers don’t know what to do
• Customers dont know what to expect
• Testers won’t know what to test,
• Users can’t determine if his/her needs are satisfied

With invalid requirements

• A non useful, non satisfactory system will be produced
• Major change requests, schedule change and high cost
• Extra steps to perform simple tasks, making system harder to use
• Can lead to unnecessarily complicated, unusable system
Specification Standards
RVTM (req. Verification and traceability matrix)
The requirements Engineer:
- Collect and manage requirements
- System Advocate
- Patient
- Systems Thinker
- Flexible
- Communicaiton Skills
- Responsive
- Translate Terms
- Unbiased
- Independent pride/Ego
Propagation of Errors

Revision Objects, Functions and systems, Alan M. Davis, Prentice Hall, PTR, Englewood Cliffs, NJ, 1994
Propagation of Errors

Correct
Correct system mission
Correct design
Correct Programming correctable
specification Errors errors
Faulty design Imperfect
Faulty Systems based on uncorrectable System
specification Design based on Faulty design errors
Faulty specification
System based on Hidden errors
Faulty specification
Functional and Non-Functional requirements

Functional Requirements
Functional requirements are what you’re
going to build.
- Functional requirements are always
mandatory; they must be met by the
product unless the requirement is
changed.
- Without a functional system, you have
nothing for your users to use.
Non-functional Requirements
Non-functional requirements ensure a system or product
is actually usable,
- provides a great customer experience, is secure, and
complies with legal regulations
- Standardization requirements
- Compatibility requirements
Non-functional requirements are not often decomposed
into more detailed requirements. They are typically
verified by inspection of the product and its
documentation. Non-functional requirements will be
mandatory if dictated by contractual or regulatory
requirements.
Non-Functional requirement types
1. Performance Focuses on the system's speed, efficiency, and workload. I.e., how fast
does the system respond?
2. Scalability Ensures the system can respond to changes in demand. I.e., how will the
system pull on additional resources?
3. Reliability Defines the system’s availability and the tolerance for failure I.e., what’s
the target uptime?
4. Resilience Defines how quickly a system can recover if it fails. I.e., how does the
reset process work?
5. Security Focuses on how the system is kept secure, stores data, and responds to
attacks. I.e., what are the security protocols of the site?
6. Usability Specifies how systems should operate for the customer/end-user. I.e.,
how many clicks to get to a certain place?
7. Maintainability Ensures the system is easy to upgrade and troubleshoot. I.e., what
format is the error log?
8. Modifiability Defines how the system can be changed if required. I.e., how can users
customize certain features? How can developers adjust the code?
9. Localization Specifies how a system will adapt to the user’s location. I.e., how will the
system detect and display different languages/currencies?
10. Regulatory Ensures the system is legally compliant. I.e., how does this system
comply with ISO27001?
Requirements Gathering
Data shows that inaccurate requirement gathering is one of the key reasons up to 70%
of projects fail. Yet, beneath that stat is the real problem: Teams focus too much on
functional requirements (what the system does) and forget about the non-functional
aspects (how the system does it).

Non-functional requirements ensure you provide a good user experience and that
your product performs at a level that your customers, clients, and stakeholders
expect.
You won’t “forget” to think about performance issues or test reliability. But are you
planning for localization, regulatory issues, or maintainability?
A good product manager needs to consider all ten non-functional requirements
during the development phase.

https://plan.io/blog/non-functional-requirements-nfrs/
Quality Attribute Requirements
Quantify user’s expectations and turn vague words into solid, actionable statements from
which to build product.

Example:
Before → ‘If it would load really fast.’
After → ‘The page will load in under 1 second’

Before → ‘If the text size was so small you couldn’t read it.’
After → ‘Text size will be 16px’

Remember to continually reference back to your functional requirements to understand

the context and what the customer needs to achieve.

Functional requirement:
As a user, I want to land on the homepage, so I can begin using the product.
Non Functional Requirement:
• What would make it great? If it would load really fast.
• What would make it bad? If the text size was so small, you couldn’t read it.
just discovered two Quality Attribute Requirements (QARs)!
Characteristics of Requirements Statements
Complete; the requirement sufficiently describes the necessary capability,
characteristic, constraint, or quality factor to meet the entity need without
needing other information to understand the requirement.
Consistent; the set of requirements contains individual requirements that
are unique, do not conflict with or overlap with other requirements in the
set, and the units and measurement systems they use are homogeneous.
The language used within the set of requirements is consistent, i.e., the
same word is used throughout the set to mean the same thing.
Necessary; the requirement defines an essential capability, characteristic,
constraint, and/or quality factor.
Appropriate; the specific intent and amount of detail of the requirement is
appropriate for the level entity to which it refers (level of abstraction).
Correct; the requirement must be an accurate representation of the entity
need from which it was transformed.
Characteristics of requirements statements
Feasible; the requirement can be realized within entity constraints (e.g., cost,
schedule, technical, legal, regulatory) with acceptable risk
Comprehensible; the set of requirements must be written such that it is clear as to
what is expected by the entity and its relation to the system of which it is a part.
Able to be validated; It must be able to be proven the requirement set will lead to the
achievement of the entity needs within the constraints (such as cost, schedule,
technical, legal and regulatory compliance).
Unambiguous; the requirement is stated in such a way that it can be interpreted in
only one way.
Singular; the requirement should state a single capability, characteristics, constraint,
or quality factor.
Verifiable; the requirement is structured and worded such that its realization can be
proven (verified) to the customer’s satisfaction at the level the requirements exist.
Conforming; the individual requirements should conform to an approved standard
template and style for writing requirements, when applicable.
How to Write a SMART Requirement ?

SMART Requirements are effective. They ensure that you

do what’s needed to achieve your goals.

5 simple steps to set smart requirements:

1.Specific: Determine what you want.
2.Measurable: Identify what success is.
3.Achievable: Make sure your goal is reasonable.
4.Relevant: Ensure goals to align with overarching goals.
5.Time-bound: Set a deadline and create a schedule.
Specific
Specific goals are well defined and clear on what needs to be accomplished. What
exactly do you want to achieve? The more specific the description, the less room
there is for interpretation between a good and bad result.

Bad: Talk to customer list about the product beta.

Good: Get written commitment from 25 customers to enter the product beta.

When setting goals, you must be specific about what you are trying to accomplish.
Distinct and simple objectives erase ambiguity and establish a clear direction.
Specific objectives are easy to follow – you can draw a straight line from where
you are now to where you want to end up
Measurable
Measurable goals clearly identify how you'll evaluate whether or not you are
successful or not. It is critical to have the option to quantify the achievement of
the objective. This doesn't need to be in the conventional sense, as on a numeric
scale or a measurement, it simply must be quantifiable in some sense
Eating healthier is not a goal, however eating vegetables twice a day and dessert
only once a month, is.
Bad: Run a product beta to get feedback from customers.
Good: Onboard 10 customers into product beta and deliver a list of product
feedback suggestions.

bad example, it's not measurable enough what success looks like. How many
customers do you need in order to get great feedback from your product data? If
the customers are invited to the beta but do not participate, is that still
considered success?
Good example: By defining a number of customers as well as a clear deliverable of
product feedback suggestions, this goal becomes Measurable.
Achievable
Inachievable goals discourage, but achievable, realistic smart goals
motivate. To ensure you’re not setting yourself up for failure, consider how
to accomplish the goal and if you have the tools/skills needed.

Bad: Meet with all customer CEOs during product beta.

Good: Schedule meetings with 3 or more our customer CEOs during beta.

How likely is it to achieve this goal? it's often very difficult to get a meeting
on the calendar with CEOs so meeting with an entire customer list could
be very unrealistic. By adjusting the goal to scheduling with 3 or more, this
creates room for making the goal Attainable.

A SMART objective must be assignable to somebody be it yourself, your

group, or individual colleagues towards achieving this objective.
Relevant
ideal approaches is to help your representatives connect their objectives back
to the more extensive group and expansive objectives. That is, ensure your
work is adding to the master plan.

Relevant goals are important to you and will make a material impact on
achieving your larger objectives. Does it make a difference to your overall
objectives if this goal is met? While many goals are worthwhile expenditures of
time, it may not always be the right timing or match to current needs.

Example
If the primary focus for your business is getting beta feedback prior to an
official launch, an example of an irrelevant goal would be sponsoring industry
conferences during the beta period.
Timely
Goals need to be time-related. It's not profitable to set a due date
excessively far later on for a straightforward undertaking, or a
ridiculously short due date for something complex and tedious.

Time-based goals lock goals into a specific timeframe and specify

when they will be completed by. This also ties into the M for
measurable goal because in order for a goal to truly be measurable, it
needs to be time-based.
Good: Onboard 10 customers into product beta by end of Q1.

Bad: Onboard 10 customers into product beta.

While the "bad" example is actually very measurable and quite

specific, it doesn't specify by when. By changing the goal to be clear
on when the goal needs to be achieved, it becomes Time-Based.
SMART Example 1:
Create a Marketing Plan for a New Business Within 1 Month

When starting a new business, there are plans within plans to make. Creating the marketing
plan for the new company is an important SMART goal.

•Specific: We need to create a marketing plan that has a specific

outline we can follow to ensure we covered the most important
information.
•Measurable: Each week of the month, we will finalize 25% of the
plan’s details to ensure completion within one month.
•Achievable: One month should be plenty of time to do all the market
research and company analysis required to create a good marketing
plan.
•Relevant: Without a solid plan for marketing, the company is missing
a crucial component to success.
•Time-bound: The time limit is one month.
SMART Example 2:
Increase New Customer Reviews by 30% Year Over Year

Most companies’ growth these days has to do with the brand awareness your business has in the
market. One of your most important goals in brand cultivation is your brand awareness growth
throughout the year.
One SMART goal example for this: The number of new customer reviews we get must increase
30% on a year-over-year (YoY) basis.

•Specific: Increase customer reviews by 30%.

•Measurable: We measure our progress through monthly reporting,
and it shows if we reach our target or not.
•Achievable: We increased our customer reviews last year by 20%.
We believe the 30% target is achievable.
•Relevant: Based on our research to date, an increase in the number
of customer reviews corresponds with increased sales in our top
growth channels.
•Time-bound: This is a YoY comparison.
SMART Example 3:
Increase Website Traffic 25% by December 2023
If your website is successful, you already are aware of your overall conversion rates,
both in terms of click-throughs from search engines and social media and in terms of
sales generated per click-through. Increasing your website traffic will increase your
sales, as long as your sales conversion rate remains relatively constant, in this SMART
business goals example.

•Specific: To increase the number of visitors that come to our site by 25%.
•Measurable: Increase our annual visitors from 100,000 to 125,000.
•Achievable: Our inbound marketing team has solid social media and content
creation strategies in place. We can hire additional experts as needed to
increase our visibility and our website traffic.
•Relevant: The more traffic we have, the more money we make and the
larger our reach.
•Time-bound: We want to complete this goal by December 2023.