Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 34

SYSTEMS ENGINEERING – SYE360S

GRADUATE OUTCOMES PROJECT ASSESSMENT RUBRIC


Applied Project: Test T3 (*See subject guide page 4 to 7) Project Name: APPLIED
PROJECT

STUDENT NUMBER: Insert your student number here STUDENT SURNAME: Insert Surname and Initials here

GRADUATE ATTRIBUTE
BELOW MEETS EXCEEDS
ASSESSMENT FOR WRITTEN MAXIMUM MARK MARGINAL
EXPECTATIONS EXPECTATIONS EXPECTATIONS
REPORT. ALLOCATION (25-49%)
(0-24%) (50-74%) (75 – 100%)
*(Average mark awarded per GA 4 & 7)
1. Investigation (ELO 4):
Evidence of:

 Comprehensively
researched system, its 20
implications & application
to organisations, industry
sectors etc.

 Analysis, Design &


Structure of the system. 20

3. Impact of Engineering
Activity (ELO 7):-
Evidence of:

 Significance of the system 20


studied to organisation’s
supply chain, productivity,
etc, & the relationship
therein etc.

 Impact Systems
Engineering has on the
system deployment, 20
optimisation, &
sustainability.

 Interventions that minimize


/ mitigate the impact
engineering has on 20
organisational practice &
society.

TOTAL: 100% 100


Student Meets Graduate Attribute (Yes or No): YES NO
OFFICE USE
Lecturer
Date: 13 May 2022
signature: NGETICH WK

Moderator
Date:
signature:

External Moderator
Date:
signature:
TITLE e.g., ROTOR SYSTEMS ENGINEERING

{DELETE THIS before submission. The title should be one sentence; free from all elaboration and
superfluous detail that gives a clear, complete, and formal description of the project report.}

By

SURNAME and INITIALS e.g., NG’ETICH W K


Student Number: 123456789

Full Time

Project Report
Submitted in fulfillment of the requirements for the

Subject:

SYSTEMS ENGINEERING: SYE360S

Qualification:

D3INDS: INDUSTRIAL ENGINEERING

In the
Faculty of Engineering and the Built Environment

Department of Industrial and Systems Engineering

At the

CAPE PENINSULA UNIVERSITY OF TECHNOLOGY

Lecturer: NGETICH WK

Cape Town: Bellville Campus

Submitted: 27 May 2022


{Change with your information and Delete all RED sections before submission.}
DEPARTMENT OF INDUSTRIAL Revision History
Revision: 02
AND Approved
Date:
08/03/22

SYSTEMS ENGINEERING Approved By


Programme Coordinator
Faculty of
Engineering and the INSTRUCTIONS MANUAL/GUIDE - Lecturer: WK Ngetich

Built Environment
SYSTEMS ENGINEERING Signature:

2022 COURSE CODE


SYE360S
Research scope: Investigate and apply Systems Engineering (Systems thinking and analysis) to improve product / service
delivery and optimise the supply chain of a task or environment.
Assessment weight: 20% (Refer to subject guide).
Applied project specifications:
1. Provided is a product with no more than 4 to 5 components with a minimum of 4 to 5 functional allocation levels
that falls in the category of system types – ‘product system’. The design specifications are as follows:
 Product name: ‘Ergonomic Footrest’
 Product features: This is an adjustable ‘under the desk’ aid that provides ergonomic sitting position for the user. It
has a limited set height, but complimented by a tilt design to set your desired, comfort angle. The tilt design feature is
a mechanism that allows for more of dynamic effort and less of static effort by allowing the user to to move their feet
back to front for ease of static strain. This under desk footrest can be angled to support your feet at the correct position
and allows more movement of your feet to improve circulation. The design feature makes it ideal for all types of
physique.
 Product parts design and specifications: Base material (4cm thick): Plywood and rubber coating, Frame: ½”
Chrome plated steel tube, 4x Rubber feet: (Length = 2” by Diameter = ½”), 4x Standard Nuts and bolt: (¼ inch #20).
 Product dimension: Length = 50cm, width = 40cm, adjustable height = 10cm - 30cm, weight = 3.2kg, and tilt = 0 0 -
200
 Schematic diagrams:
2. Give a detailed introduction and background of your system, motivating why you chose this system.

[Tip: Develop an adequate introductory overview of the technological, industrial, & / or organisational context of the study.
Clear statement of the topic of your system i.e. what is the broad issue investigated? Give sufficient reasons for selecting
the issue being studied i.e., the rationale for the study. It should be clear why the study is required in the chosen area, &
what value this will bring to not only the environment (user, business etc.) in which it is being undertaken, but to the
profession. Importance of the study: Indicate how the study will refine, revise, or extend existing knowledge in the area
investigated.]

3. Give a detailed and concise background to your study.

[Tip: Identify a specific problem / issue on for example the operational level of the organization which has an impact on the
performance. Show evidence (reports, graphs, process deviation, cost implication), which will show justification why you
are doing the study.]

4. Apply systems engineering thinking as a methodology to how you intend investigating and assessing your study project,
following, and documenting all the 7 steps to Systems Engineering (SE).

5. Develop a brief literature review of your study.

[Tip: Adequate overview & critical analysis of the relevant literature sources correctly referenced. Keep the number of
literature sources to a minimum of 10 using standard literature sources (i.e., Textbooks, Journal Articles, Websites, etc.)
Indicate what research has already been done on this topic or in this area of study. Main theories, models and methods
that currently exist. Reference using the correct referencing syntax according to the Harvard method.]

6. Conclusion and Recommendation.

[Tip: Recommendations (listed), should not only be feasible, but also viable and supported by a comprehensive example
cost benefit analysis where applicable. Each recommendation should be cross-referenced to the supporting evidence
contained in the cost and benefit analysis.]

Note: (This project is individual based)

Use provided structure template in the end of this manual. Your report must comply with ALL report-writing requirements. It
must include a standard cover page (provided), a contents page, proper page numbering, an introduction, the body, a proper
conclusion, & proper referencing / bibliography. Include pictures, sketches, drawings, diagrams, etc. in your text & any other
relevant material. Label each correctly. Use appendices as required and properly reference all your work. Use the Harvard
method. Ensure you use a proper layout, which shows spaces between headings & text as well as spaces between paragraphs.
Pictures or sketches included within the text must be properly labeled. Proofread your assignment for proper sentence structure,
grammar, spelling and punctuation. Font is Arial, size 12; the body must be 10 - 15 pages, no less, no more. Electronic
submission format (See BB).
Due Date: 13 May 2022, by 24H00 No Late Projects Will Be Accepted. Late projects will be awarded a “0” (ZERO).
Table of contents: (Add / remove headings, subheadings, and page no. as required Page
List of tables v
List of figures vi
1. INTRODUCTION TO XXX SYSTEMS ENGINEERING PROCESS e.g., 1
1.1. Background to the study (Project manual specifications) 1
1.1.1. Study objectives 2
2. TOPIC OF YOUR STUDY (Chapter1) e.g., 3
2.1. What are systems 3
2.1.1. Brief history of systems 3
2.2. What is systems engineering 3
2.3. System structure (product / service) 4
3. PRODUCT / SERVICE MARKET (Chapter1 and 2) e.g., 5
3.1. Xxx market 5
3.1.1. Xxx market analysis 5
3.1.2. Xxx supply chain analysis 8
4. THE SYSTEM ENGINEERING PROCESS (Chapter 2, 3 and 4) 9
4.1. Systems planning architecture 9
4.1.1. Program management plan 10
4.1.2. Definition of program requirements 10
4.1.2.1.Functional flow diagram 10
4.1.2.2.Functional analysis and allocation 11
4.1.2.3.Program specification tree 12
4.1.3. System requirements traceability 14
4.1.4. The Quality Function Model (QFD) 15
4.1.5. Technical Performance Measurements (TPMs) 16
4.1.6. System design requirements 17
4.1.7. System testing evaluation and validation 18
5. CONCLUSIONS AND RECOMMENDATIONS 19
5.1. Conclusions 19
5.2. Recommendations 19
REFERENCES (In alphabetical order) 20
BIBLIOGRAPHY (In alphabetical order) 20
ANNEXURE A 21

vii
List of Tables: (Add / remove table headings and page numbers as required) Page

Table 1. Situational factors determining IS in the organization 1

Table 2. SWOT analysis of a computer system 6

viii
List of Figures: (Add / remove figure headings and page numbers as required) Page

Figure 1. Situational factors determining IS in the organization 1

Figure 2. Linear hydraulic actuator 2

Figure 3. Computer system diagram 4

Figure 4. System structure diagram for a computer 4

Figure 5. Computer product life cycle phases 7

Figure 6. Example of a Cost Break Down Structure (CBS) 7

Figure 7. The evolution from mission need to functional analysis 9

Figure 8. Online shopping user FFD 11

Figure 9. Trade-off analysis process 12

Figure 10. Example 1 of a PST 13

Figure 11. Example 2 of a PST 13

Figure 12. Example of a PST showing relational ties 15

Figure 13. Example House of Quality QFD 16

Figure 14. Example TPM requirements allocation 17

Figure 15. Example design morphology 18

Figure 16. Example House of Quality QFD 21

Figure 17. Example TPM prioritization matrix 22

ix
1. INTRODUCTION TO YOUR PRODUCT / SERVICE NAME SYSTEMS ENGINEERING
PROCESS

(Introduce every heading and subheading first before discussing anything else following it).

This section discusses the summary of you report. Its normally written last after you complete
the report. This allows you to summaries the whole study here.

ALL Main headings should appear on their own page. Subheadings may flow over to the next
page. Be consistent with writing etc. If you use “e.g.,” do not use “example” and vis versa. ALL
paragraphs must be set to “justify”. Use of bold, Italics, underline, and justification: Headings
should be bold if possible, otherwise underlined (but not both).

Use of Tables and Figures: Tables and figures are exhibits and numbered sequentially using
font 10. They should be placed as close as possible after their first mentioned as possible.
The table number as well as heading of each exhibit must appear aligned left directly on top of
the exhibit. The figure number as well as heading of each exhibit must appear centred with
the heading centred directly beneath the exhibit. See examples below.

Centralization

In-House Outsourced

Decentralization

Figure 1: Situational factors determining IS in the organization (Adapted from Tan, 1994)

Table 1: Situational factors determining IS in the organization (Adapted from Tan, 1994)
Product type A Product type B Product type C

(Conclude every heading and subheading first before leaving to start another heading or
subheading).

1.1. Background to the study (Project manual specifications)

(Introduce every heading and subheading first before discussing anything else following
it).

What is this study about? What is the purpose of the study? The purpose of systems
engineering is to produce systems that satisfy the customers' needs, increase the
probability of system success, reduce risk, and reduce total-life-cycle cost. Contextualise

Page 1 of 35
your section here. Give a detailed introduction and background of your system, motivating
why you chose this system.

Show a detailed drawing of your product / service here. Showing all components.
Example.

Figure 2: Linear hydraulic actuator (extracted from Gonzalez, 2015: 17)

Develop an adequate introductory overview of the technological, industrial, & / or


organisational context of the study. Clear statement of the topic of your system i.e., what
is the broad issue investigated? Give sufficient reasons for selecting the issue being
studied i.e., the rationale for the study. It should be clear why the study is required in the
chosen area, & what value this will bring to not only the environment (business) in which it
is being undertaken, but to the profession.

Importance of the study: Indicate how the research will refine, revise, or extend existing
knowledge in the area under investigation.

(Conclude every heading and subheading first before leaving to start another heading or
subheading).

1.1.1. Study objectives

(Introduce every heading and subheading first before discussing anything else
following it).

 Define what the study aims to achieve in very brief bulleted statements.

 These statements should align with the various topics / headings you will
discussing below.

(Conclude every heading and subheading first before leaving to start another
heading or subheading).

Page 2 of 35
Page 3 of 35
2. TOPIC OF YOUR STUDY (Chapter 1 and 2)

(Introduce every heading and subheading first before discussing anything else following it).

From section one, build on that by giving more precise detail and concise background to your
study.

Identify a specific problem / issue on for example the operational level of the organization
which has an impact on the performance. Show evidence (reports, graphs, process deviation,
cost implication), which will show justification why you are doing the study. E.g., pareto charts
etc.

(Conclude every heading and subheading first before leaving to start another heading or
subheading).

2.1. What are systems

(Introduce every heading and subheading first before discussing anything else following
it).

Literature review.

(Conclude every heading and subheading first before leaving to start another heading or
subheading).

2.1.1. Brief history of systems

(Introduce every heading and subheading first before discussing anything else
following it).

Literature review.

(Conclude every heading and subheading first before leaving to start another
heading or subheading).

2.2. What is systems engineering

(Introduce every heading and subheading first before discussing anything else following
it).

Literature review. Apply systems engineering thinking as a methodology to how you


intend investigating and assessing your study project, following, and documenting all the

Page 4 of 35
7 steps to Systems Engineering (SE). You may use the various models here. E.g., Vee
model.

(Conclude every heading and subheading first before leaving to start another heading or
subheading).

2.3. System structure (product / service)

(Introduce every heading and subheading first before discussing anything else following
it).

What does the system look like? Illustrate it based on its functionality. Example.

Figure 3: Computer system diagram (adapted from Blanchard, 2011: 120)

Describe, discuss, and draw this system and its structures i.e., something like a Bill of
Material (BOM) also called a system breakdown structure.

Systems are organised into a hierarchy consisting of elements. These elements often
again consist of subsystems. Below these subsystems, we can distinguish assemblies,
subassemblies, components, and parts. The parts are the lowest level of separately
identifiable items. There are often also links between elements i.e., relation links.
Example.

Page 5 of 35
Computer

Hardware Software Support

Eletcronics Data Processing Hardware Repair

Information
Mechanics Management Software
System

Power Data

Battery

Figure 4: System structure diagram for a computer (adapted from Blanchard, 2011: 120)

(Conclude every heading and subheading first before leaving to start another heading or
subheading).

Page 6 of 35
3. PRODUCT / SERVICE MARKET (Chapter1 and 2)

(Introduce every heading and subheading first before discussing anything else following it).

Introduce what will be discussed in this section here. Discuss the product or service
environment.

(Conclude every heading and subheading first before leaving to start another heading or
subheading).

3.1. Xxx market

(Introduce every heading and subheading first before discussing anything else following
it).

To understand the system objective / function, we need to study the market. Using the
system 4Ms, consider your market. Recall that a market is a place where the demand and
the supply of a product come together. This is not always a physical place. But a service
space such as the internet, which can be considered a market too.

Every market is supplied and managed through a supply chain. Describe the basic
building blocks of your supply chain.

(Conclude every heading and subheading first before leaving to start another heading or
subheading).

3.1.1. Xxx market analysis

(Introduce every heading and subheading first before discussing anything else
following it).

So how do you describe a market? To do that, you must look at certain properties.
Every market has certain customers, products, function, and technology in it.

Split your market up into a market segmentation. Every sub-group of the market is
called a market segment. Companies often apply different marketing strategies to
different market segments. Using the Multidimensional Market Definition (MMD)
technique, describe your three segments i.e., the customer, the function, and the
technology / material of the product. This will extend the report into a supply chain
discussion.

Together with an MMD we need to position our product / service onto the market.

Page 7 of 35
To do that in an optimal way, we need to perform a Market Analysis. An important
tool to perform a market analysis, is the SWOT analysis. We want to give our
product a certain position on the market. In a SWOT analysis, we look at the
Strengths, the Weaknesses, the Opportunities, and the Threats caused by this. If
we know these four things, we might be able to improve the position of our product
on the market. E.g.
Table 2: SWOT analysis of a computer system (Adapted from Blanchard, 2011: 120)
POSITIVE NEGATIVE

STRENGTHS WEAKNESSES

1. Read/Write performance. 1. No grid computing.


2. Serverless architecture. 2. Limited processing size (10
INTERNAL

MB.).
3. Replication and encryption.
3. Windows operating system.
4. No extra equipment is required.
4. Library required for Information
5. Use of the TCP / IP protocol.
Management Systems.
6. Easy scalability-Load balancing.
7. Universally applicable.
OPPORTUNITIES THREATS

1. Horizontal scalability on 1. Internet and electricity.


demand. 2. Firewall and port dependency.
EXTERNAL

2. Reduce hardware costs. 3. Limited test environment.


3. Offline operation. 4. Static IP address change
4. Suitable for cloud architecture. 5. Temporarily.

Page 8 of 35
There is another way to examine the position of our product in the market. We can
also look at the Product Life Cycle (PLC). This cycle describes the sales of the
product, while it is on the market. E.g.

Figure 5: Computer product life cycle phases (adapted from Blanchard, 2011: 120)

Discuss all the phases as they affect / are affected by your product / service.

Estimate a Life Cycle Cost (LCC) using a Cost Break Down Structure (CBS)
Example.

Figure 6: Example of a Cost Break Down Structure (CBS) (adapted from Blanchard, 2011: 120)

(Conclude every heading and subheading first before leaving to start another
heading or subheading).

Page 9 of 35
3.1.2. Xxx supply chain analysis

(Introduce every heading and subheading first before discussing anything else
following it).

Visualize your Supply Chain (SP) here. An example of such a Supply Chain. In a
Supply Chain, the steps a product goes through, before it reaches the market, are
displayed. Starting at the raw material suppliers. The raw materials are turned into
basic parts by pure manufacturers. These basic parts are eventually assembled,
and ready to be supplied to the market.

Illustrate / draw your basic SP here.

(Conclude every heading and subheading first before leaving to start another
heading or subheading).

Page 10 of 35
4. THE SYSTEM ENGINEERING PROCESS (Chapter 2, 3 and 4)

(Introduce every heading and subheading first before discussing anything else following it).

Discuss what is required and documented in this section subheadings. I.e., the customer and
life cycle needs, system specifications, design Specifications, verification specifications,
verification report, and feasibility reports. You will need to show the tools used here like the
functional flow diagrams etc.

Show a description of how this process will evolve. Refer to figure 3 Blanchard (2011: 32).

The chapter will also highlight the progression from the system need to final functional
analysis as shown below. This is an example to help you clarify the discussion that will follow
here.

Figure 7: The evolution from Mission need to functional analysis (adapted from Blanchard, 2011: 89)

(Conclude every heading and subheading first before leaving to start another heading or
subheading).

4.1. Systems planning architecture

(Introduce every heading and subheading first before discussing anything else following
it).

Introduce your use of the System Planning Architecture, and SEMP etc.

(Conclude every heading and subheading first before leaving to start another heading or
subheading).

Page 11 of 35
4.1.1. Program management plan

(Introduce every heading and subheading first before discussing anything else
following it).

Describe your project plan here. What methodology are you using? How will you
execute it? Show a project plan timeline with all the resources documented (recall this
from your project management classes).

(Conclude every heading and subheading first before leaving to start another heading
or subheading).

4.1.2. Definition of program requirements

(Introduce every heading and subheading first before discussing anything else
following it).

Examine the kind of functions your system has. Discuss how requirements are to
be generated i.e., QFD model, and how you should deal with resources. Shows
what you will do below.

(Conclude every heading and subheading first before leaving to start another
heading or subheading).

4.1.2.1.Functional flow diagram

(Introduce every heading and subheading first before discussing anything


else following it).

From your system structure, develop a functional flow diagram. Every


system has functions: It should do certain things. To accomplish these
functions, several steps (sub-functions) need to be taken. A good way to
visualize this, is by using a Functional Flow Diagram (FFD) such as the one
shown below.

Page 12 of 35
Figure 8: Online shopping user FFD (extracted from Chourey and Sharma, 2016: 2196)

(Conclude every heading and subheading first before leaving to start


another heading or subheading).

4.1.2.2.Functional analysis and allocation

(Introduce every heading and subheading first before discussing anything


else following it).

FFDs are not enough to explain and illuminate everything you need to know
about the subsystem and system functions. For example, where which
functions are related to each other to meet system objectives. In that case, a
Functional breakdown of the structure to group functions becomes useful.

In an FAA, a function is split up into several sub-functions. Grouping of sub-


functions that if completed allow, to perform the actual function.

The process will involve a decision-making tree of sorts where you decide
based on subsystem objectives against system need. This will take the form
of a trade-off analysis process as seen below.

Page 13 of 35
Figure 9: Trade-off analysis process (extracted from Blanchard, 2011: 94)

(Conclude every heading and subheading first before leaving to start


another heading or subheading).

4.1.2.3.Program specification tree

(Introduce every heading and subheading first before discussing anything


else following it).

Remember that a PST is a tool used to generate system requirements set


by the customers during your project objectives and mission needs analysis
phase. Examples of tools to achieve these can be.

Page 14 of 35
Figure 10: Example 1 of a PST (extracted from Blanchard, 2011: page?)

Another example.

System Mission

Technical
Mission
mission
constraints
obejctives

Mission at
Mission Lean mission Inventory
optimum lead Costs Lead time
throughput delivery management
time

Etc. Etc.

Figure 11: Example 2 of a PST (extracted from Blanchard, 2011: page?)

Consider discussing the following when generating PSTs.

PSTs analyse the stakeholder requirements to check completeness of


expected services and operational scenarios, conditions, operational modes,

Page 15 of 35
and constraints. They define the system requirements and their rationale.
Following which they classify the system requirements using various
subsystem groupings and incorporate the derived requirements (coming
from architecture and design) into the system requirements baseline.

Note that PSTs establish the upward traceability with the stakeholder needs
and requirements which will form the basis for the next heading, to ensure
bi-directional traceability between requirements at adjacent levels of the
system hierarchy. This will allow for system verification for quality and
completeness of each system requirement and the consistency of the set of
system requirements. The verification allows for validating the content and
relevance of each system requirement against the set of stakeholder
requirements.

Another important aspect to PSTs is identifying potential risks (or threats and
hazards) that could be generated by the system requirements, which are
synthesized, recorded, and managed for potential associated risks.

(Conclude every heading and subheading first before leaving to start


another heading or subheading).

4.1.3. System requirements traceability

(Introduce every heading and subheading first before discussing anything else
following it).

Following the PST generation, it is important to document the relationships among


various requirements at different system levels. Since requirements often originate
from other requirements that have parent and children, the relation between these
requirements needs to be summarized in a graphical representation that looks like
a PST and a matrix table. They trace forward, backward, and bidirectionality of
requirements to ensure they meet system objectives. It is a quality assurance
process.

Because the current trends pertaining to increasing globalization, greater


outsourcing, and the increasing utilization of external suppliers, variations often
occur in implementing different practices and standards. Thus, potential risks
emerge when PSTs are generated, and traceability ensures compliance to system
individual objectives against overall system objective.

Typical example. Questions arising may be where a requirement has no parent,


then something has is wrong or further requirements need to be added.

Page 16 of 35
Figure 12: Example of a PST showing relational ties (extracted from Blanchard, 2011:
page?)

(Conclude every heading and subheading first before leaving to start another
heading or subheading).

4.1.4. The Quality Function Model (QFD)

(Introduce every heading and subheading first before discussing anything else
following it).

The next step in the preliminary process design after PST and traceability is to
establish prioritisation of important system functions based on the market analysis
done previously.

Assuming our list of requirements the question one should ask is which
requirements are more important than others? To determine this, we need a QFD
diagram. See example below. The QFD compliments the technical performance
measurements (TPM) needed to generate further requirements for the PST based
on how important a functionality is.

Page 17 of 35
Figure 13: Example House of Quality QFD (extracted from Blanchard, 2011: page?)

Refer to various article of the House of Quality (HOQ) on blackboard and annexure
A for examples.

(Conclude every heading and subheading first before leaving to start another
heading or subheading).

4.1.5. Technical Performance Measurements (TPMs)

(Introduce every heading and subheading first before discussing anything else
following it).

The design requirements require a set of parameters to be set on the maximum


and minimum design requirements for the resources that will be used in the system
design. This process requires a TPM. A guide for the TPM matrix will take the
following form. Refer to annexure A results of the TPM allocation. Following this a
TPM is drawn.

Page 18 of 35
Example.

Figure 14: Example TPM requirements allocation (extracted from Blanchard, 2011: page?)

(Conclude every heading and subheading first before leaving to start another
heading or subheading).

4.1.6. System design requirements

(Introduce every heading and subheading first before discussing anything else
following it).

The previous sections have now provided you with a foundation upon which to
base the detailed design decisions that go down to the component level. i.e., the
definition of the detailed design-to requirements for the various lower-level
elements of the system.

You need to generate a description of subsystems, units, assemblies, lower-level


components, software modules, people, facilities, elements of maintenance and
support, and so on, that make up the system and address their interrelationships.

This will be done by preparing specifications and design data for all system
components; and integrate the selected (after choice of best alternative analysis –
see trade off analysis figure) components into a final system configuration.

Using a selection of resources system component tree / structure.

Page 19 of 35
Figure 15: Example design morphology (extracted from Blanchard, 2011: page?)

(Conclude every heading and subheading first before leaving to start another
heading or subheading).

4.1.7. System testing evaluation and validation

(Introduce every heading and subheading first before discussing anything else
following it).

Now that we have a design for our system. This design must match the
requirements. The verification process will test, evaluate, and validate the design as
meeting mission objective(s). Discuss verification methods by considering test type
1, 2, 3, & / or 4.

(Conclude every heading and subheading first before leaving to start another
heading or subheading).

Page 20 of 35
5. CONCLUSIONS AND RECOMMENDATIONS

(Introduce every heading and subheading first before discussing anything else following it).

Describe the summary of your project here. You may show the full SE flow here with all the
components you discussed in a summary form. Briefly mentioning what will be discussed in
the conclusion and recommendation section below. This is a summary introduction of what
you will say in detail in your subheadings below.

(Conclude every heading and subheading first before leaving to start another heading or
subheading).

5.1. Conclusions

(Introduce every heading and subheading first before discussing anything else following
it).

What were your findings? What does the system product or service finally look like? Did
you achieve the design of the system and the product spec you intended to study? This
section needs you to discuss if you achieved your objectives stated in section 1, study
objectives.

(Conclude every heading and subheading first before leaving to start another heading or
subheading).

5.2. Recommendations

(Introduce every heading and subheading first before discussing anything else following
it).

Based on your objectives in the conclusion. What are the recommendations you for the
system and product / service you were designing? Here you are expected to show the
final product of the SE process. It can be a table showing broad system specifications that
the system will operate under etc, a figure of your final design product / service design
etc.

(Conclude every heading and subheading first before leaving to start another heading or
subheading).

Page 21 of 35
REFERENCES (All references used and shown in the report. In alphabetical order. Do not
bullet, number etc.)

Aguero, V., 2001. “Cubesats: A Technology and Science Mission Low-cost Test Bed,”
AIAA/USU Conference on Small Satellites, Aug. 13-16, 2001, Logan, UT, SSC01-VIIIb-3.

Blanchard, B.S., 2004. System engineering management. John Wiley & Sons.

Chourey, V. and Sharma, M., 2016, September. Functional flow diagram (FFD): Semantics
for Evolving Software. In 2016 International Conference on Advances in Computing,
Communications and Informatics (ICACCI) (pp. 2193-2199). IEEE.

Gonzalez, C., 2015. What’s the Difference Between Pneumatic, Hydraulic, and Electrical
Actuators?. Machine design, 17.

Heidt, H., Puig-Suari, J., Moore, A., Nakasuka, S. and Twiggs, R., 2000. CubeSat: A new
generation of picosatellite for education and industry low-cost space experimentation.

Tan, M., 1994. Establishing mutual understanding in systems design: An empirical study.
Journal of Management Information Systems, 10(4), p.159.

BIBLIOGRAPHY (All references used but NOT shown in the report. In alphabetical order. Do
not bullet, number etc.)

Asundi, S.A. and Fitz-Coy, N.G., 2013, March. CubeSat mission design based on a systems
engineering approach. In 2013 IEEE Aerospace Conferenc (pp. 1-9). IEEE.

Blanchard, B.S., Fabrycky, W.J. and Fabrycky, W.J., 1990. Systems engineering and
analysis (Vol. 4). Englewood Cliffs, NJ: Prentice hall.

Haskell, G. and Rycroft, M.J. eds., 2012. International Space Station: the next space
marketplace (Vol. 4). Springer Science & Business Media.

Page 22 of 35
ANNEXURE A (Label your tables and figures here)

Document Quality Function Diagram (QFD) using the House of Quality (HOQ) approach.
:

Activity: Assessing product requirements for a wooden desk.

HOQ: Model: Example

Figure 16: Example House of Quality QFD (extracted from Blanchard, 2011: page?)

Analysis: 1. Record the product attributes. These are the properties of the product, as seen by
the customer. (Looks of the desk, the ease in use, the strength, etcetera).

2. Indicate the importance of the product attributes, according to customer. This


goes on a scale from 1 to 5. (The customer could, for example, want a very
efficient desk. Thus, ease in use gets a 5, while the looks get a 2).

3. Compare product design to other similar products. To do this, find out what our
customer thinks of those other products. Do this for all product attributes. (So, for
example, we must know what our customer thinks of the looks, the ease in use
and the strength of that brand new desk).

4. Continue by setting the objectives for the product. This is again on a scale from 1
to 5. (How good do we want our desk to look? How strong should it be?) Once we
have done this, we can also fill in the remaining columns on the right of the QFD.
This eventually gives us the weight of the product attributes.

Page 23 of 35
5. Start by writing down the technical parameters. These are the parameters, as
seen by the designers. (Examples are the thickness of the wooden planks, the
number of supporting beams, the wood type, the paint quality, etcetera).

6. Next fill in the middle part of the QFD. Here, we insert the effect of the technical
parameters on the product attributes. This can be either strong (9), medium (3),
low (1) or non-existing (0).
For example, the thickness of the wooden planks effects the strength a lot (9), but
it effects the looks only a bit (3 or 1). Also, the quality of the paint effects the looks
quite a bit (9 or 3), but it does not affect the strength at all (0).
Once we know the effects, we multiply them by the weight (determined at step 4)
to find the importance.

7. Next fill in the fields of the bottom rows, by simply adding up all the values of the
columns above them.

8. We can also indicate the correlation between the technical parameters. They can
affect each other in a strong way (9), a medium way (3) a light way (1) or not at all
(0). This is done for every pair of technical attributes. (For example, the number of
supporting beams in the desk effects the thickness of the wooden planks. More
supports means that the planks can be lighter).

Results: 9. Based on the analysis, we give actual values to the technical parameters. (We
can, for example, decide that we want wooden planks of exactly 1 cm. thick).

TPM The results of the QFD HOQ generate the prioritization of technical performance
allocation: measures (TPMs) matrix. Example.

Figure 17: Example TPM prioritization matrix (extracted from Blanchard, 2011: page?)

Page 24 of 35
ANNEXURE B (Label your tables and figures here)

Page 25 of 35

You might also like