project

Description

i have a template of my project..
this is my topic ….”

A system that will autonomously monitor a
multi-acre field to detect, remove and eliminate small trees from
pasture land without destroying the pasture or harm livestock

.”

Project Title
Author
Table of Contents
1
Introduction ……………………………………………………………………………………………………………. 4
2
Needs Analysis ………………………………………………………………………………………………………… 4
2.1
3
Operations Analysis ……………………………………………………………………………………………. 4
2.1.1
Analysis of Projected Needs………………………………………………………………………….. 4
2.1.2
Stakeholders ………………………………………………………………………………………………. 4
2.1.3
Operational Objectives ………………………………………………………………………………… 5
2.2
Functional Analysis …………………………………………………………………………………………….. 5
2.3
Feasibility Definition …………………………………………………………………………………………… 6
2.4
Needs Validation ……………………………………………………………………………………………….. 6
2.5
System Operational Requirements ………………………………………………………………………. 7
2.5.1
Operational Scenarios ………………………………………………………………………………….. 7
2.5.2
Operational Requirements Statements ………………………………………………………….. 8
Concept Exploration…………………………………………………………………………………………………. 8
3.1
Operational Requirements Analysis ……………………………………………………………………… 8
3.1.1
4
Operational Scenarios ………………………………………………………………………………… 10
3.2
Performance Requirements Formulation ……………………………………………………………. 10
3.3
Implementation Concept Exploration …………………………………………………………………. 12
3.4
Performance Requirements Validation ……………………………………………………………….. 12
Concept Definition …………………………………………………………………………………………………. 13
4.1
Performance Requirements Analysis ………………………………………………………………….. 13
4.2
Functional Analysis and Formulation ………………………………………………………………….. 14
4.3
Functional Allocation………………………………………………………………………………………… 14
4.4
Concept Selection…………………………………………………………………………………………….. 14
4.5
Summary of Final Concept ………………………………………………………………………………… 15
4.5.1
Operational View ………………………………………………………………………………………. 15
4.5.2
Logical View ……………………………………………………………………………………………… 15
4.5.3
Physical View…………………………………………………………………………………………….. 15
4.5.4
Standards View …………………………………………………………………………………………. 16
4.5.5
Data and Information View…………………………………………………………………………. 16
4.5.6
Manufacturing View ………………………………………………………………………………….. 16
4.5.7
Cost View …………………………………………………………………………………………………. 16
2|Page
4.5.8
5
Reliability View ………………………………………………………………………………………….. 16
References ……………………………………………………………………………………………………………. 16
3|Page
1 Introduction
Introduction to the problem the project is intended to address. Be brief. Describe the system
you are designing in terms of functionality (ie. What the system does). If there is a predecessor
system, briefly explain what it does, and then very briefly explain what it needs to do that it
currently does not do, that your project will address. It should not be simply an exact repetition
of the problem statement you were given; there should be some evidence that you understand
why the problem has not been trivially solved already.
If you find yourself describing how your new system will do this, or describing technologies that
your system will use to solve this problem, you not doing this step correctly! There will be a
time for this much later in the project, but not here or in the needs analysis.
2 Needs Analysis
2.1 Operations Analysis
2.1.1 Analysis of Projected Needs
Describe the need for a new system. What is driving the need for the system? Is it a deficiency
in the current system? Is it a need for better sales? Is it a need to add new technology to a
system? Is the current system becoming obsolete?
Describe the deficiencies in the current system, if there is one.
This section should explore these matters in more depth than the Introduction.
2.1.2 Stakeholders
Identify all the people and organizations that would care if a solution to this problem is
developed. Some may be glad the system is being developed because it will make their lives
better in some way. Others may be concerned about the impact the new system will have on
other existing systems and processes. In some cases there may be people who are negatively
impacted. In each case, identify the stakeholder and the concerns they have about how the
“problem” could be solved.
T ABLE 1: S TAKEHOLDERS
Stakeholder
Description
What they care about
4|Page
2.1.3 Operational Objectives
Describe your analysis process for determining the operational objectives.
Determine the operational objectives for the system. The objectives should have these
properties as stated in the book:
• Objectives should address the end state of the operational environment or scenario — it
focuses on what the system will accomplish in the large sense.
• Objectives should address the purpose of the system and what constitutes the satisfaction
of the need.
• Taken together, objectives answer the “why” question — why is the system needed?
• Most objectives start with the infinitive word “provide,” but this is not mandatory.
The objectives should describe what you want the system to do or how you want it to function.
The list will generally start with the main things you want the system to do for the primary user,
but to the extent possible you want to address the needs of the other stakeholders. It may not
be possible for the system to address all the perceived needs of all the stakeholders, but you
should have at least identified those needs and discussed why it is not practical to address them
in the system.
T ABLE 2: O PERATIONAL O BJECTIVES L IST
Objective # Objective
OO-1
OO-2
OO-3
OO-4
OO-5
Put the objectives in an objectives tree like Figures 6.3 & 6.4 (functions are not part of the tree).
Draw a system context diagram (like figures 3.2 and 3.3). Remember that the context diagram
primarily answers the questions What functionality is INSIDE my system?, What functionality is
OUTSIDE my system that my system interacts with?, and What kinds of interactions are there at
the system boundary?
This is a good reference on how to develop operational objectives.
http://www.ops.fhwa.dot.gov/publications/fhwahop10027/chap_2.htm
2.2 Functional Analysis
Describe how you performed the functional analysis.
5|Page
Define functions necessary to meet objectives. High level functions are stated in a very general
way in Table 3.2. Start with the objectives from the previous section and determine what
functions are needed to achieve each of those objectives.
Draw a block diagram showing the interactions with the environment from the system context
diagram and the functions needed in the system.
2.3 Feasibility Definition
Describe the feasibility of the system. To do this you should relate your system ideas to the
current system and the available technology. Could a feasible system be developed? For the
functions defined in Functional Analysis, is it possible to design a system that has those
functions?
T ABLE 1: F UNCTION FEASIBILITY
Function
Existing System
New System
High Cost (Y/N)
2.4 Needs Validation
In the section you should demonstrate that the there is a need for a new system and it is
feasible to meet that need at an affordable cost and at an acceptable risk.
Describe the major scenarios in which the system will function and system responses. Develop
system performance parameters and measures of effectiveness (MOE) for each of the
scenarios. There will likely be more than one MOE for each scenario. The MOEs are metrics of a
system’s overall performance and always refers to the system as a whole.
T ABLE 2: T ABLE OF MOE S
MOE # Metric
MOE-1
MOE-2
MOE-3
MOE-4
MOE-5
Units
Conditions (Scenario #)
6|Page
2.5 System Operational Requirements
This section is the primary product of Needs Analysis and is the input to the next phase of
development (Concept Exploration).
2.5.1 Operational Scenarios
The book states that each scenario usually has the 5 items within it. The outline here shows
what those items are. The number of scenarios needed is dependent on how the project
system will be used. Also, the type of content is also dependent on the project. It could be
mostly text or it could be text with many diagrams.
Later in the design process we will revisit scenarios, but inside the system. They will be
related to, but NOT be identical to the scenarios presented here.
2.5.1.1 Scenario 1
2.5.1.1.1 Mission Objectives
What are the mission objectives this scenario is attempting to address? These may be
operational objectives from those identified above, or may be even higher level
objectives in which the system being designed may be only one small element. One
scenario may address multiple objectives, and an objective may be partially or fully
addressed by more than one scenario.
2.5.1.1.2 Architecture
What is the structure being assumed by the scenario sequence description below? This
is NOT the structure of the system to be designed (we haven’t gotten there yet!) but the
structure of the people, organizations, and larger systems in which this sequence of
steps that will use our system will play out.
2.5.1.1.3 Physical Environment
What is being assumed about the environment outside the system in the scenario
sequence description below?
2.5.1.1.4 Competition
What forces or entities are actively resisting, impeding, or threatening the successful
execution of the scenario and/or the completion of the higher level mission?
2.5.1.1.5 General Sequence of Events
What is the sequence of steps by which the outside actors accomplish their purposes at
least partially by using the project system?
2.5.1.2 Scenario 2
Using the system to accomplish a different mission objective…
2.5.1.2.1 Mission Objectives
7|Page
2.5.1.2.2 Architecture
2.5.1.2.3 Physical Environment
2.5.1.2.4 Competition
2.5.1.2.5 General Sequence of Events
2.5.2 Operational Requirements Statements
This section should be a list of operational requirements. They are things the system must be
able to do in order for all of the scenarios above to work. They generally should involve more
detail than the operational objectives presented earlier. They must be stated in measurable
terms, at least in the sense that it must be possible to definitively say whether the requirement
has been met or not. The rationale for all requirements must be stated. Some will address a
single operational need, while others result from the interaction of multiple needs. Operational
requirements are described on p. 145 in the text.
T ABLE 3: O PERATIONAL R EQUIREMENTS S TATEMENTS
OR #
Operational Requirement
OR-1
OR-2
OR-3
OR-4
OR-5
OR-6
Rationale
3 Concept Exploration
3.1 Operational Requirements Analysis
Analyze the Operational Objectives defined in the Needs Analysis. This may be difficult to do
since simulation etc. will not be possible. You should start with the list of operational
requirements from the end of Needs Analysis. For each requirement, look to see it meets the
following statements.
1. Is the requirement traceable to a user need or operational requirement?
2. Is the requirement redundant with any other requirement?
3. Is the requirement consistent with other requirements? (Requirements should not
contradict each other or force the engineer to an infeasible solution.)
4. Is the requirement unambiguous and not subject to interpretation?
5. Is the requirement technologically feasible?
6. Is the requirement affordable?
7. Is the requirement verifiable?
8|Page
T ABLE 4: O PERATIONAL R EQUIREMENTS A NALYSIS
With reference to the table of operational requirements, and the operational objectives, each
requirement will be analyzed as stated in each column. The full question to be answered is stated
below:
1. Is the requirement traceable to a user need or operational requirement?
2. Is the requirement redundant with any other requirement?
3. Is the requirement consistent with other requirements?
4. Is the requirement unambiguous and not subject to interpretation?
5. Is the requirement technologically feasible?
6. Is the requirement affordable ($)?
7. Is the requirement verifiable?
Requirement
1
2
3
4
Number
Traceable Redundant
Consistent
Unambiguous
OR-1
OO-#
OR-2
OR-3
OR-4
OR-5
OR-6
5
Feasible
6
Affordable
7
Verifiable
T ABLE 5: U PDATED O PERATIONAL R EQUIREMENTS
UOR #
Operational Requirement
UOR-1
UOR-2
UOR-3
UOR-4
UOR-5
UOR-6
UOR-7
UOR-8
For all the requirements as a set, look to see if they meet the following statements.
1. Does the set of requirements cover all of the user needs and operational objectives?
2. Is the set of requirements feasible in terms of cost, schedule, and technology?
3. Can the set of requirements be verified as a whole?
T ABLE 6: O PERATIONAL O BJECTIVE TO O PERATIONAL R EQUIREMENT M APPING
OO # Objective
UOR # that relates to the OO
OO-1
UOR-#
OO-2
OO-3
OO-4
OO-5
9|Page
OO-6
OO-7
At the end of this analysis you should have an updated set of operational requirements.
T ABLE 7: F INAL O PERATIONAL R EQUIREMENTS
UOR #
Operational Requirement
FOR-1
FOR-2
FOR-3
FOR-4
FOR-5
FOR-6
3.1.1 Operational Scenarios
Taking the operational scenarios from Needs Analysis, update the scenarios here.
3.2 Performance Requirements Formulation
Examine the functional decomposition of the system. Develop a functional diagram like figure
7.6 in the text. Look at the coffee maker example in the text.
1. Are there operational objectives that require sensing or communications? If so, this means
that signal input, processing, and output functions must be involved.
2. Does the system require information to control its operation? If so, how are data generated,
processed, stored, or otherwise used?
3. Does system operation involve structures or machinery to house, support, or process
materials? If so, what operations contain, support, process, or manipulate material
elements?
4. Does the system require energy to activate, move, power, or otherwise provide necessary
motion or heat?
10 | P a g e
F IGURE 1: F UNCTIONAL F LOW B LOCK D IAGRAM FOR A POOL CONTROLLER EXAMPLE .
Develop a table of system performance characteristics. Look at the functional block diagram
and define how well it should do those functions. Make sure you consider constraints when
coming up with the performance characteristics. These performance characteristics are looking
internal to the system and specifying how well it must perform internal functions.
T ABLE 8: P ERFORMANCE R EQUIREMENTS
Performance Function
Characteristic
Requirement
Number
PR-1
PR-2
PR-3
PR-4
PR-5
PR-6
PR-7
PR-8
PR-9
PR-10
Requirement
11 | P a g e
3.3 Implementation Concept Exploration
You must come up with a minimum of 5 concepts. Look at your functional decomposition and
examine if there are different ways to do the functions that you have in your functional
decomposition. If there are any advanced technologies you can examine how those can be
implemented in your system. Do not throw out concepts at this phase. Also think about the
predecessor systems in how you will be modifying those systems. Label the concepts in some
way so you can track which one is which. Look at the figure below to think of a spectrum of
concepts.
F IGURE 2: S PECTRUM OF S YSTEM I DEAS
3.4 Performance Requirements Validation
Develop the performance requirements by examining the concepts that were developed in the
previous section. Describe how these performance requirements satisfy the system operational
requirements. The performance requirements may not be much different than those developed
under the performance requirements formulation section.
T ABLE 9: V ALIDATED P ERFORMANCE R EQUIREMENTS
Performance Function
Characteristic
Requirement
Requirement
Number
VPR-1
VPR-2
VPR-3
VPR-4
12 | P a g e
VPR-5
VPR-6
VPR-7
VPR-8
VPR-9
VPR-10
4 Concept Definition
4.1 Performance Requirements Analysis
This will have the final requirements for your system for this project. Make sure you consider
the full system life cycle when finalizing the requirements. Put the requirements here and
briefly indicate how each requirement id measureable/testable. The measurability/testability
may have been done previously but make sure it is here.
T ABLE 10: P ERFORMANCE R EQUIREMENTS AND T ESTABILITY
Performance Characteristic
Requirement
Requirement
Number
PRT-1
PRT-2
PRT-3
PRT-4
PRT-5
PRT-6
PRT-7
PRT-8
PRT-9
PRT-10
PRT-10
Testable
T ABLE 13: A LLOCATION OF P ERFORMANCE R EQUIREMENTS TO S UBSYSTEMS
Subsystem
Characteristic
VVV Subsystem
List of Requirements that are applicable to VVV subsystem
WWW Subsystem
List of Requirements that are applicable to WWW subsystem
XXX Subsystem
List of Requirements that are applicable to XXX subsystem
YYY Subsystem
List of Requirements that are applicable to YYY subsystem
ZZZ Subsystem
List of Requirements that are applicable to ZZZ subsystem
13 | P a g e
(If it is easier, this allocation table could have rows for requirements and columns for
subsystems, with marks for those subsystems that each requirement is allocated to.
Remember that many requirements are allocated to multiple subsystems.)
4.2 Functional Analysis and Formulation
Recall that the “systems engineering method divides the design task into two closely coupled
steps: (1) analyzing and formulating the functional design of the system (what actions it needs
to perform) and (2) selecting the most advantageous implementation of the system functions
(how the actions can best be physically generated).” In Concept Selection the functional
definition should be done to the system components levels. In the previous section the
functional definition should have been done to the subsystem level.
In this section, supply more details to the functional block diagram of your system and make
refinements where necessary. Start with the functional flow block diagram from the
Performance Requirements Formulation section in Concept Exploration.
4.3 Functional Allocation
The result of this section is a set of concepts where each concept is described by a pictorial or
other physical description for providing a more realistic view of the system candidate. A
diagram of the concept is the best way to describe a concept. Just a paragraph of what is in the
concept is not very good. Your concepts should show how (physical items) they system will
perform the functions in the functional flow diagram from the previous section.
If you did not do any concept screening in Concept Exploration then you should have all your
concepts shown here with more details. Number or label each concept and include a diagram
and some text describing the concept.
4.4 Concept Selection
Analysis of the concepts in terms of
• • operational performance and compatibility,
• • program cost,
• • program schedule, and
• • risk in achieving each of the above.
Your operational performance and compatibility should be tailored to your system. For
instance, the example from the slides for the syringe had items like “ease of handling”, “ease of
use”, and “dose metering accuracy.” It didn’t just have “operational performance and
compatibility.” Think of the operational objectives when looking at what to put in the weighted
trade-off matrix.
You must include a trade-off analysis that has a numerical weighting to determine your final
concept.
14 | P a g e
T ABLE 4: T RADE – OFF MATRIX
Concept 1
Criteria
Weight
Rating
Concept 2
Score
Rating
Score
Concept 3
Concept 4
Concept 5
Rating
Rating
Rating
Score
Score
Score
4.5 Summary of Final Concept
So that it is clear what your final concept is for this project you will summarize the concept in
this section. You can put the Functional Allocation information here for your concept. You must
have at least 3 architectural views of the chosen concept. The main three mentioned in the
book are described. Other views are also mentioned.
4.5.1 Operational View
This representation is from the users ’ or operators ’ perspective. This view would include
products that address operational system phases, scenarios, and task flows. Information flow
from the users ’ perspectives might also be addressed. User interfaces would also be described.
Example products that might be included in this view would be operational figures or graphics,
scenario descriptions (including use cases), task flow diagrams, organization charts, and
information flow diagrams.
4.5.2 Logical View
This representation is from the manager ’ s or customer ’ s perspective. The logical view would
include products that define the system ’ s boundary with its environment and the functional
interfaces with external systems, major system functions and behaviors, data flow, internal and
external data sets, internal and external users, and internal functional interfaces. Example
products for this view would be FFBDs, context diagrams, N2 diagrams, IDEF0 diagrams, data
flow diagrams, and various stakeholder – specific products (including business – related
products).
4.5.3 Physical View
This representation is from the designers ’ perspective. This view would include products that
define the physical system boundary, the system ’ s physical components and how they
interface and interact together, the internal databases and data structures, the information
technology (IT) infrastructure of the system and the external IT infrastructure with which the
system interfaces, and the standards in force in its development. Example products include
15 | P a g e
physical block diagrams down to a fairly high level of detail, database topologies, interface
control documents (ICDs) , and standards.
4.5.4 Standards View
4.5.5 Data and Information View
4.5.6 Manufacturing View
4.5.7 Cost View
4.5.8 Reliability View
5 References
These are the acceptable types of references and acceptable formats. Make sure you have
references and that you refer to them in the text. If you use images or other material from a
reference you need to have that shown in your document.
Article in a collection
[1]
A.J. Albrecht, “Measuring Application-Development Productivity,” Programmer Productivity Issues
for the Eighties, 2nd ed., C. Jones, ed., IEEE CS Press, 1981, pp. 34-43.
Article in a conference proceedings
[2]
M. Weiser, “Program Slicing,” Proc. 14th Int’l Conf. Data Eng. (ICDE 98), IEEE CS Press, 1998, pp.
439-449.
Article in a journal or magazine
[3]
I.E. Sutherland, R.F. Sproull, and R.A. Schumaker, “A Characterization of 10 Hidden-Surface
Algorithms,” ACM Computing Surveys, Mar. 1974, pp. 1-55.
Entries in a blog:
[4]
M. Sahami, “About the Google Education Summit,” blog, 26 Oct. 2007,
http://googleblogspot.com/2007/10/about-google-education-summit.html.
[5]
“Reinforcement Learning is Cool,” blog, 24 Oct. 2007, http://smartmachines.blogspot.com/2007/10/reinforcement-learning-is-cool.html. (no named author)
To cite the blog itself:
[6]
The Official Google Blog, Google, http://googleblog.blogspot.com. (Google is listed as the publisher
here.)
[7]
M. Watson, Artificial Intelligence Blog, http://markwatson.com/aiblog.
Book
[8]
W.M. Newman and R.F. Sproull, Principles of Interactive Computer Graphics, McGraw-Hill, 1979, p.
402.
[9]
M.A. Arbib, ed., The Handbook of Brain Theory and Neural Networks, MIT Press, 1998.
Book series
[10] Y. Yao et al., “Web Intelligence (WI): Research Challenges and Trends in the New Information
Age,” Web Intelligence: Research and Development, LNAI 2198, N. Zhong et al., eds., SpringerVerlag, 2001, pp. 1-17.
16 | P a g e
Dissertation or thesis
[11] B. Fagin, “A Parallel Execution Model for Prolog,” doctoral dissertation, Dept. Computer Sciences,
Univ. of California, Berkeley, 1987.
Online-only publication
[12] F. Kaplan, “From Baghdad to Manila: Another Lousy Analogy for the Occupation of Iraq,” Slate, 21
Oct. 2003; http://slate.msn.com/id/2090114/.
Web site
[13] R. Bartle, “Early MUD History,” Nov. 1990; http://www.ludd.luth.se/aber/mud-history.html.
Patent
[14] M. Hoff, S. Mazor, and F. Faggin, Memory System for Multi-Chip Digital Computer, US patent
3,821,715, to Intel Corp., Patent and Trademark Office, 1974.
Pending publication
[15] R. Lee, “New-Media Processing,” to be published in IEEE Micro, Nov./Dec. 2006.
Specification
[16] MPEG-21 Overview, ISO/MPEG N5231, MPEG Requirements Group, Oct. 2002.
17 | P a g e

We offer the bestcustom writing paper services. We have done this question before, we can also do it for you.

Why Choose Us

  • 100% non-plagiarized Papers
  • 24/7 /365 Service Available
  • Affordable Prices
  • Any Paper, Urgency, and Subject
  • Will complete your papers in 6 hours
  • On-time Delivery
  • Money-back and Privacy guarantees
  • Unlimited Amendments upon request
  • Satisfaction guarantee

How it Works

  • Click on the “Place Order” tab at the top menu or “Order Now” icon at the bottom and a new page will appear with an order form to be filled.
  • Fill in your paper’s requirements in the "PAPER DETAILS" section.
  • Fill in your paper’s academic level, deadline, and the required number of pages from the drop-down menus.
  • Click “CREATE ACCOUNT & SIGN IN” to enter your registration details and get an account with us for record-keeping and then, click on “PROCEED TO CHECKOUT” at the bottom of the page.
  • From there, the payment sections will show, follow the guided payment process and your order will be available for our writing team to work on it.