Systems Engineering and Integration Project Paper


Project Description

This project will be based on the design and analysis of an original system of your choice. Your system must either be a new system that has not been implemented before or is a modification/improvement of an existing system. Your project should focus on the end-to-end solution of a problem.

– my project title is ( TELEMEDICINE ).

– on these two files i already did ( , Scope Template)/

– in the IT518- System Requirements Template project 3 file has the further work.(which you must complete it.

– i need it looks an organize whole work which means your work complete the previous work.

– if you need other pages from the book , please let me know.

avoid plagiarism

my professor question is


Developing well-designed, tested, functional and reliable systems depends on a number of different processes. Today, producing and maintaining large systems is a task that is almost exclusively performed by teams of people. Not surprisingly, a significant portion of success in such projects does not strictly depend on technical abilities alone but on a number of other factors such as proper design, planning, estimation, people communication, activity coordination, project scope management, etc. This project will provide you the opportunity to experience and deal with almost every possible facet of the systems engineering process.

Systems Engineering and Integration
An analysis of telemedicine: Project scope
Project Objective, Overview, and Justification
The salient objective of the project is to create a feasible solution system in
telemedicine. The system is Video convention structure (VCS). It applies the internet to
connect hardware devices such as phone to enable sharing of high-quality images and sound
(Radiol, 2012). The system relies on mobile or wireless network infrastructure. Hence, it is
flexible and affordable to users
List of Functionality / Scope Items
The following is the list of the items in the scope of the creation of the system
(Radiol, 2012):
Wireless or mobile networks
Computer or PCs
VCS gateway
VCS systems
VCS widespread stakeholders
VCS software
End point centers
Time Frame
The project is estimated to take eight weeks. The project time frame will be
subdivided into 3 phases. The first is seeking approval from the Local Governance Council,
ensuring all the regulatory procedures are followed to the latter. This process may take two
weeks. The second is the reconnaissance, which will take one week and involve establishing
research tools, study area, and study plan (Synn, 2011). The third stage is collecting data,
which is expected to take two weeks. The fourth stage is data entry, analysis, and report
writing. This will take three weeks.
Target Customer
The target customers are medical institutions in general. However, the most promising
clients are medical unions and collaborative physicians. The reason for this is that the entities
might need to constantly share information with each other at the same time but the
geographical distance constraints them (Radiol, 2012). Also, the physicians with the intention
of applying VCS to remain in touch with patients are viable.
Modeling Application Cross Reference
(This section is required for all Modeling Applications)
The VCS system works like a distributed operating system. The network has an
overhead known as the gateway (Radiol, 2012). The rest of the infrastructures such as the
PCs and phones are connected to the gateway for easier conferencing by participants.
High-Level Risks
(This section required for New Applications and Significant Changes only)
The high risks of the project are built on the fact that it is a new undertaking. It will
require enormous resources. Hence, only success can justify by it not a failure (Radiol, 2012).
Outstanding Issues
The outstanding issue is that the system calls for a collection of users. It would be
difficult for individuals that want to apply it independently to utilize it without other users
(Radiol, 2012). Hence, it is intrinsically a collective system.
(This section is required for New Applications and Significant Changes only)
The assumption is that medical practitioners are ready for the system. Since, the group
has always wanted to share medicinal knowledge collectively (Dinesen, 2016). Moreover, it
is assumed that physicians might find it worthy to communicate to different patients with the
same illness at the same time.
(This section is required for New Applications and Significant Changes only)
The constraints have to do with the gathering of resources to fulfill the project. Also,
it might take a considerable time to acquire authoritative mandate to carry on with the project
(Synn, 2011).
(This section is required for New Applications and Significant Changes only)
The project relies on the availability of resources. Also, it requires permission from
relevant authorities (Dinesen, 2016). Furthermore, all stakeholders with essential knowledge
concerning the system will have to coordinate.
Critical Success Factors
(This section is required for New Applications and Significant Changes only)
The critical success factor will rely on the existing knowledge of such systems.
Correspondingly, the availability of all the required resources will determine the success rate
(Radiol, 2012).
Policy Impacts
The project might lead to implementing of policies that encourage technological
inventions for telemedicine. In this way, the field will keep on developing (Radiol, 2012).
Moreover, it will perpetually accommodate other innovations
Procedure Impacts
(This section is required for New Applications and Significant Changes only)
The project has to deal with procedural impacts. Developers have to consult the
relevant authorities (Dinesen, 2016). Also, the procedure should involve seeking appropriate
sources of capitals for completion of the project.
Legal Impacts
(This section is required for New Applications and Significant Changes only)
The project has to operate based on the stipulated legal guidelines. Furthermore, any
adverse effects of the project should be clearly stipulated (Dinesen, 2016). Hence, the
stakeholders will have an excellent opportunity to start and complete it.
Controls Impacts
(This section is required for New Applications and Significant Changes only)
The project needs coordination among resource providers. It requires the availability
of relevant authorities and other stakeholders (Radiol, 2012). Thus, it is vital to have apparent
channels of communication.
Training and Rollout
(This section is required for New Applications and Significant Changes only)
The project will have initial training of the stakeholders to fathom their specific input.
It will enable the feasibility of the project (Radiol, 2012). Afterward, it will roll out on the set
date of initiation.
Notes and Information
The project is one of the finest innovations of the 21st century. Once it is completed it
will contribute to easier undertakings in telemedicine. Thus, it requires sufficient and
essential support.
Dinesen, M. S. (2016, March). Personalized Telehealth in the Future: A Global
Research Agenda. J Med Internet Res. Retrieved from
Radiol, K. J. (2012, January). Emerging Technologies for Telemedicine. Retrieved
Synn, E. (2011). Innovation in ICT-Based Health Care Provision. Int. J. Healthc. Inf.
Syst. Inform., 2011. 6(2): p. 14-27.
Project Name: System Requirements Specification (version 1.0)
To use this template:
Replace any red italicized text with your own text. You may remove or add sections as needed for your
particular projects.
Enter the project name in the title and footer (and change the document version number, if necessary).
If your document is very long, break each numbered chapter into its own document section, beginning it
on a new page. This will make it easier to replace/update
Delete these instructions and any other italicized instructions.
Prepared by:
Document status: __ Draft __ Proposed __ Validated __ Approved
1. Introduction
This document contains the system requirements for project name. These requirements have been
derived from several sources, including brief listing of most important sources.
1.1 Purpose of This Document
This document is intended to guide development of project name. It will go through several stages during
the course of the project:
Draft: The first version, or draft version, is compiled after requirements have been discovered, recorded,
classified, and prioritized.
Proposed: The draft document is then proposed as a potential requirements specification for the project.
The proposed document should be reviewed by several parties, who may comment on any requirements
and any priorities, either to agree, to disagree, or to identify missing requirements. Readers include endusers, developers, project managers, and any other stakeholders. The document may be amended and
reproposed several times before moving to the next stage.
Validated: Once the various stakeholders have agreed to the requirements in the document, it is
considered validated.
Approved: The validated document is accepted by representatives of each party of stakeholders as an
appropriate statement of requirements for the project. The developers then use the requirements
document as a guide to implementation and to check the progress of the project as it develops.
1.2 How to Use This Document
We expect that this document will be used by people with different skill sets. This section explains which
parts of this document should be reviewed by various types of readers.
Types of Reader
In this section, list the different types of reader this document is aimed at. For example, Flash
programmers, graphic designers, end-users, project managers, etc. For each type of reader, clearly state
which sections are most pertinent to them, and which may be safely skipped.
Technical Background Required
Describe here the technical background needed to understand the document in general, and any
particular expertise or understanding that is needed for specific sections.
Overview Sections
List here the sections that should be read by someone who only wishes to gain an overall understanding
of the project, or which should be read first before technical requirements are reviewed.
Reader-Specific Sections
In this section, name any parts of the document which are intended only for one or another of the reader
types identified above, and which may therefore be skipped by other readers.
Section Order Dependencies
If readers will need to read certain sections in a specific order, note those sections here. Also point out
any sections that may be read independently with no loss of understanding.
1.3 Scope of the Product
Include a brief narrative here which describes the product as you intend it to be realized. Use this section
to define boundaries and set expectations.
1.4 Business Case for the Product
Why is this product required? How will it contribute to the goals of your institution? This section can be
used when requirements are being negotiated, to assess whether a particular change is a good idea. This
section also helps readers understand why certain requirements have been included.
1.5 Overview of the Requirements Document
If your project is small to medium in size, include a summary of the requirements here. This may be a
numbered list of the most important requirements. The purpose of this section is to give the reader a
general understanding of the requirements and focus attention on the most critical ones. This section may
also help point readers to the specific requirements that are of particular interest to them.
2. General Description
This section will give the reader an overview of the project, including why it was conceived, what it will do
when complete, and the types of people we expect will use it. We also list constraints that were faced
during development and assumptions we made about how we would proceed.
This section contains a nontechnical description of the project, usually in narrative form, which may serve
to acquaint new readers with the purpose of the project. It also sets the stage for the specific requirement
listing which follows.
2.1 Product Perspective
Why have you chosen to develop this product? What need does it serve? Who are the primary
stakeholders, who is developing the project, and who will benefit from the finished product?
2.2 Product Functions
What does your product do? What activities can users perform while using it? List the main functions that
you will build into your product here.
2.3 User Characteristics
Who do you expect to use your finished product, and why? What is their technical background, their
training or education, their motivation to use it? What obstacles might they encounter, and what
specialized skills will they need?
2.4 General Constraints
Did you work under any constraints such as platform or development environment? Did you have to make
your product compatible with any existing software or other products currently in use?
2.5 Assumptions and Dependencies
In this section, list any assumptions you made about your project (for example, did you assume that the
finished product would need to be delivered over the internet?). If your project depends on any particular
technical infrastructure, or requires administrators or others with specific skills, note that here.
2.6 Maintenance and Support Concept
How will the system be maintained and supported during its life-cycle? The maintenance and support
concept generally includes the levels of maintenance, repair policies, organizational responsibilities,
maintenance support elements, effectiveness requirements, and environment. Refer to pages 76-81 in
the textbook.
2.7 Functional Analysis and Allocation
Provide a functional flow block diagram of the system’s top-level functions. Refer to pages 86-93 in the
2.8 Cost Analysis
How much will the entire implemented system cost? Provide a breakdown of the estimated cost for each
major component and the total cost for your entire system.
3. Specific Requirements
This section of the document lists specific requirements for name of project. Requirements are divided
into the following major sections:
System and Integration requirements: These are detailed specifications describing the functions the
system must be capable of doing.
Operational requirements: These are detailed non-functional requirements describing other desired
attributes of the overall system and how the system will run and communicate with operations personnel.
User Interface requirements: These are requirements about the user interface, which may be expressed
as a list, as a narrative, or as images of screen mock-ups.
3.1 System and Integration Requirements
List detailed system requirements here. These are your functional (or technical) Type A system-level
requirements. If your system is large, you may wish to break this into several subsections. Include
dependencies on existing systems.
3.2 Operational Requirements
List detailed operational requirements here. These are your non-functional requirements. Do not state
how these requirements will be satisfied. For example, in the Reliability section, answer the question,
“How reliable must the system be”? Do not state what steps will be taken to provide reliability. You should
include the following types of requirements below:
3.2.1 Performance
List performance requirements here. Include response time for queries and updates, throughput,
expected rate of user activity (for example, number of transactions per hour, day, or month, or cyclical
periods), and specific performance requirements related to a specific functional requirement which should
be listed with that functional requirement.
3.2.2 Physical Characteristics
List physical requirements here (e.g., size?, weight?, speed?, etc.)
3.2.3 Effectiveness/Reliability
List effectiveness and reliability requirements here. Reliability is the probability that the system processes
work correctly and completely without being aborted. State the following in this section:
1. State the damage that can result from failure of this system – indicate the criticality of the software,
such as:
(a) Loss of human life
(b) Complete or partial loss of the ability to perform a mission-critical function
(c) Loss of revenue
(d) Loss of employee productivity
2. What is the minimum acceptable level of reliability?
3. State required reliability:
(a) Mean-Time-Between-Failure (MTBF) is the number of time units the system is operable before
the first failure occurs.
(b) Mean-Time-To-Failure (MTTF) is the number of time units before the system is operable divided
by the number of failures during the time period.
(c) Mean-Time-To-Repair (MTTR) is the number of time units required to perform system repair
divided by the number of repairs during the time period.
3.2.4 Availability
List availability requirements here. System availability is the time when the application must be available
for use. Required system availability is used in determining when maintenance may be performed. State
the period during which the application must be available to users. For example, “The application must be
available to users Monday through Friday between the hours of 6:30 a.m. and 5:30 p.m. MST. If the
application must be available to users in more than one time zone, state the earliest start time and the
latest stop time. Consider daylight savings time, too. Include use peak times. These are times when
system unavailability is least acceptable.
3.2.5 Recoverability
List recoverability requirements here. Recoverability is the ability to restore function and data in the event
of a failure. Answer the following questions in this section:
1. In the event the application is unavailable to users (down) because of a system
failure, how soon after the failure is detected must function be restored?
2. In the event the database is corrupted, to what level of currency must it be restored?
For example “The database must be capable of being restored to its condition of no
more than 1 hour before the corruption occurred”.
3. If the processing site (hardware, data, and onsite backup) is destroyed, how soon
must the application be able to be restored?
4. Backup: Identify backup requirements for ensuring the continued achievement of system functions.
5. Fallback: Identify fallback techniques for ensuring the continued satisfaction of the specific
requirements of the system. Fallback indicates the use of another system to satisfy the system
requirements. For example, the fallback techniques for an automated
system might be manual manipulation and recording of data.
6. Degraded Modes of Operation: State priorities for restoring the essential functional processing steps in
the event that full processing capability is not available.
3.2.6 Maintainability
List maintainability requirements here (e.g., reusability?, extensibility?, etc.)
3.2.7 Usability
List usability (human factors) requirements here. These are requirements written from the point of view of
end users (e.g., what is the ease with which the system can be learned or used?).
3.2.8 Supportability
List supportability requirements here (e.g., how will hardware and/or software components of the system
be easily modified or maintained to accommodate typical usage or change scenarios?)
3.2.9 Portability/Mobility
List portability/mobility requirements here. Provide a description of the hardware and software platforms
needed to support the system.
3.2.10 Sustainability
List sustainability requirements here (e.g., has a long life?, is repairable?, efficiently incorporates
environmentally friendly materials?).
3.2.11 Security and Privacy
List security requirements here. This section describes the need to control access to the data. This
includes controlling who may view and alter application data. Use the following criteria:
1. State the consequences of the following breaches of security:
(a) Loss or corruption of data
(b) Disclosure of sensitive information
(c) Disclosure of privileged/privacy information about individuals
(d) Corruption of software or introduction of malware such as viruses.
2. State the type(s) of security required. Include the need for the following as appropriate:
(a) Physical security
(b) Access by user role or types
(c) State access control requirements by data attribute. For example, one group of users has
permission to view an attribute but not update it while another group of users has permissions to
update or view it.
(d) State access requirements based on system function. For example, if there is a need to grant
access to certain system functions to one group of users, but not to another. For example, “The
system shall make Function X available to the System Administrator only.”
(e) State if there is a need for certification and accreditation of the security measures adopted for this
3.2.12 Safety
List safety requirements here (e.g., can it avoid damage to people or environment?).
3.2.13 Maintenance
List maintenance requirements here (e.g., downtime?, personnel skills required?, etc.).
3.2.14 Data Retention
List data retention requirements here. Describe the length of time various forms of data must be retained
and the requirements for its destruction. For example, “The system shall retain application information for
3 years.” Different forms of data include: system documentation, audit records, database records, access
3.2.15 Environmental factors
List environmental factors here where system will be able to operate (e.g., temperature?, humidity?, etc.).
3.3 User Interface Requirements
List interface requirements here; or include screen mockups. If you use mockups, be sure to explain
major features or functions with narrative to avoid confusion or omission of desired features.
4. High-Level Technology Architecture
(e.g. web-based, Unix, communication networks, etc.)
5. Customer Support
How will it be supported internally?
6. Appendices
If you wish to append any documents, do so here. You may wish to include some or all of the following
but you must at least include the feasibility analysis:
• Feasibility analysis containing scenarios and alternate solutions developed for this project. You
should also explain why you chose the solution you chose over the other possible solutions.
• Original project proposals or other historical documents
• Lists of similar projects or products, with notes about how they differ from yours
• A list of requirements which were “wish-listed” or marked unfeasible at present
• Original screen mockups, if they are relevant
7. Glossary
Include a glossary of definitions, acronyms, and abbreviations that might be unfamiliar to some readers,
especially technical terms that may not be understood by end-users or domain-specific terms that might
not be familiar to developers.
8. References
List references and source documents, if any, in this section.
9. Index
If your document is very large, consider compiling an index to help readers find specific items.
Project Name: System Requirements Specification (version 1.0)

Purchase answer to see full

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.