<Project Name>

Vision (Small Project)

Authors: <forename.name>(<email> )

Document Number: <reference #>

Version: <version #>

Publish Date: 2022-03-02

[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square
brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be
deleted before publishing the document. A paragraph entered following this style will automatically be set to normal
(style=Body Text).]
[To customize automatic fields in Microsoft Word (which display a gray background when selected), select
File>Properties and replace the Title, Subject and Company fields with the appropriate information for this
document. After closing the dialog, automatic fields may be updated throughout the document by selecting
Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately
for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word
help for more information on working with fields.]
<Project Name> Version: <1.0>
Vision (Small Project) Date: <yyyy-mm-dd>
<document identifier>

Record of Processing
No. Version Date Status Who Description
1

Record of Approval
No. Version Date Who Description

1 … … …

Recipients of Document
No. Version Date of Distribution Recipients
1 … …

Page 2
<Project Name> Version: <1.0>
Vision (Small Project) Date: <yyyy-mm-dd>
<document identifier>

Table of Contents
1. Introduction 3
1.1 References 3

2. Positioning 3
2.1 Problem Statement 3
2.2 Product Position Statement 3

3. Stakeholder and User Descriptions 3

3.1 Stakeholder Summary 3
3.2 User Summary 3
3.3 User Environment 3
3.4 Summary of Key Stakeholder or User Needs 3
3.5 Alternatives and Competition 3

4. Product Overview 3
4.1 Product Perspective 3
4.2 Assumptions and Dependencies 3

5. Product Features 3

6. Other Product Requirements 3

Page 3
<Project Name> Version: <1.0>
Vision (Small Project) Date: <yyyy-mm-dd>
<document identifier>

Vision (Small Project)

1. Introduction
O ramură de utilizare a IoT este reprezentată de Agricultura de precizie(în engleză
Precision Agriculture). Această ramură se folosește la rândul ei de WSN(Wireless sensor
network). Wireless sensor networks (WSN) colectează informații de la diferiți senzori din rețele
mari și mici astfel încât utilizatorul final să poată obține și procesa date. [2] Aceste rețele sunt
realizate din mai multe noduri de senzori bazate pe comunicație fără fir. Nodul trebuie să
detecteze fenomene fizice precum temperatura, umiditatea din aer și umiditatea din sol cu
energie și memorie limitată. [3]
1.1 References
[This subsection provides a complete list of all documents referenced elsewhere in the Vision document. Identify
each document by title, report number if applicable, date, and publishing organization. Specify the sources from
which the references can be obtained. This information may be provided by reference to an appendix or to another
document.]

2. Positioning
2.1 Problem Statement
Acest proiect are două scopuri principale. Primul scop este acela de a oferi date
reale de la senzori în contextul unui sistem de senzori care au ca rol simularea unei sere din
domeniul agriculturii. Al doilea scop este acela de a analiza datele care sunt trimise de la
senzori, de a afișa datele clientului și de a pune la dispoziția clientului o serie de acțiuni care vor
avea ca efect gestionarea unor actuatori.

The problem of Gestionarea resurselor unei sere prin supraveghere si

automatizare.
Affects Companiile din sectorul agricol.
the impact of which is Dificultatea alocarii esurselor in gestionarea cresterii
plantelor si gestionarea calitatii produsului final.
a successful solution would Capabil sa gesstioneze resursele si istoricul deciziilor luate
be pe parcursul unei plantatii.
Usor de utilizat.
Usor de mentinut.
Usor de vizualizat datele.

2.2 Product Position Statement

Scopul principal al produselor companiei este acela de a monitoriza temperatura,
umiditatea și salinitatea pentru un interval cât mai mare de culturi. Acestea depind însă de tipul
solului dar și de climat. Valoarea pozitivă pe care aceste produse o aduc într-o fermă este
reprezentată de creșterea randamentului culturii, creșterea calității culturii, scăderea
dependenței culturii de pesticide și în ultimul rând controlul asupra maturității produsului cu
anumite limitări. Astfel dacă ai o comandă de legume cu o săptămână mai târziu decât
preconizezi produsul final ca fiind matur, poți gestiona situația astfel încât să crești durata de
maturizare. Reducerea semnificativă a risipirii resurselor, deoarece de foarte multe ori fermierii

Page 4
<Project Name> Version: <1.0>
Vision (Small Project) Date: <yyyy-mm-dd>
<document identifier>

fie aruncau produsele acestea deteriorându-se până la vânzare sau aruncau produsele
deoarece nu obțineau prețul dorit.
For Sentek
Who Valoarea pozitivă pe care aceste produse o aduc într-o fermă
este reprezentată de creșterea randamentului culturii, creșterea
calității culturii, scăderea dependenței culturii de pesticide și în
ultimul rând controlul asupra maturității produsului cu anumite
limitări.
The Drill & Drop este un produs de formă conică care este disponibil în mai
multe dimensiuni, acesta fiind disponibil pentru culturi
variabile în funcție de adâncime la care rădăcinile plantei ajung
la maturitate. Senzorii sunt situați pe dispozitiv din 10 în 10
centimetri. Drill & Drop livrează datele către baza de date și
astfel datele vor fi utilizate pentru afișarea în contul de IrriMAX
în timp real.
That Returneaza informatii necesare despre starea solului
Unlike Dezavantajele sunt reprezentate de bateriile care pot fi
deteriorate dupa montarea in sol de utilajele grele care fac
lucrari necesare plantatiei.
Our product Usor de montat, si cu o acuratete foarte buna.
[A product position statement communicates the intent of the application and the importance of the project to all
concerned personnel.]

3. Stakeholder and User Descriptions

[To effectively provide products and services that meet your stakeholders’ and users' real needs it is necessary to
identify and involve all of the stakeholders as part of the Requirements Modeling process. You must also identify the
users of the system and ensure that the stakeholder community adequately represents them. This section provides a
profile of the stakeholders and users involved in the project, and the key problems that they perceive to be addressed
by the proposed solution. It does not describe their specific requests or requirements as these are captured in a
separate stakeholder requests artifact. Instead, it provides the background and justification for why the
requirements are needed.]

3.1 Stakeholder Summary

[There are a number of stakeholders with an interest in the development and not all of them are end users. Present a
summary list of these non-user stakeholders. (The users are summarized in section 3.2.)]
Name Description Responsibilities
[Name the [Briefly describe the [Summarize the stakeholder’s key
stakeholder type.] stakeholder.] responsibilities with regard to the system
being developed; that is, their interest as a
stakeholder. For example, this stakeholder:
ensures that the system will be maintainable
ensures that there will be a market demand for
the product’s features
monitors the project’s progress

Page 5
<Project Name> Version: <1.0>
Vision (Small Project) Date: <yyyy-mm-dd>
<document identifier>

approves funding
and so forth]

3.2 User Summary

[Present a summary list of all identified users.]
Name Description Responsibilities Stakeholder

[Name [Briefly describe [List the user’s key responsibilities [If the user is not directly
the user what they represent with regard to the system being represented, identify which
type.] with respect to the developed; for example: stakeholder is responsible for
system.] representing the user’s
captures details
interest.]
produces reports
coordinates work
and so on]

3.3 User Environment

[Detail the working environment of the target user. Here are some suggestions:
Number of people involved in completing the task? Is this changing?
How long is a task cycle? Amount of time spent in each activity? Is this changing?
Any unique environmental constraints: mobile, outdoors, in-flight, and so on?
Which system platforms are in use today? Future platforms?
What other applications are in use? Does your application need to integrate with them?
This is where extracts from the Business Model could be included to outline the task and roles involved, and so on.]

3.4 Summary of Key Stakeholder or User Needs

[List the key problems with existing solutions as perceived by the stakeholder or user. Clarify the following issues
for each problem:
• What are the reasons for this problem?
• How is it solved now?
• What solutions does the stakeholder or user want?]
[It is important to understand the relative importance the stakeholder or user places on solving each problem.
Ranking and cumulative voting techniques indicate problems that must be solved versus issues they would like
addressed.
Fill in the following table—if using Rational RequisitePro to capture the Needs, this could be an extract or report
from that tool.]
Need Priority Concerns Current Solution Proposed Solutions
Broadcast messages

Page 6
<Project Name> Version: <1.0>
Vision (Small Project) Date: <yyyy-mm-dd>
<document identifier>

3.5 Alternatives and Competition

[Identify alternatives the stakeholder perceives as available. These can include buying a competitor’s product,
building a homegrown solution, or simply maintaining the status quo. List any known competitive choices that exist
or may become available. Include the major strengths and weaknesses of each competitor as perceived by the
stakeholder or end user.]

4. Product Overview
[This section provides a high level view of the product capabilities, interfaces to other applications, and system
configurations. This section usually consists of two subsections, as follows:
• Product perspective
• Assumptions and dependencies]

4.1 Product Perspective

[This subsection of the Vision document puts the product in perspective to other related products and the user’s
environment. If the product is independent and totally self-contained, state it here. If the product is a component of a
larger system, then this subsection needs to relate how these systems interact and needs to identify the relevant
interfaces between the systems. One easy way to display the major components of the larger system,
interconnections, and external interfaces is with a block diagram.]

4.2 Assumptions and Dependencies

[List each factor that affects the features stated in the Vision document. List assumptions that, if changed, will alter
the Vision document. For example, an assumption may state that a specific operating system will be available for
the hardware designated for the software product. If the operating system is not available, the Vision document will
need to change.]

5. Product Features
[List and briefly describe the product features. Features are the high-level capabilities of the system that are
necessary to deliver benefits to the users. Each feature is an externally desired service that typically requires a
series of inputs to achieve the desired result. For example, a feature of a problem tracking system might be the
ability to provide trending reports. As the use-case model takes shape, update the description to refer to the use
cases.
Because the Vision document is reviewed by a wide variety of involved personnel, the level of detail needs to be
general enough for everyone to understand. However, enough detail must be available to provide the team with the
information they need to create a use-case model.
To effectively manage application complexity, we recommend for any new system, or an increment to an existing
system, capabilities be abstracted to a high enough level so 25-99 features result. These features provide the
fundamental basis for product definition, scope management, and project management. Each feature will be
expanded in greater detail in the use-case model.
Throughout this section, each feature will be externally perceivable by users, operators, or other external systems.
These features should include a description of functionality and any relevant usability issues that must be addressed.
The following guidelines apply:
• Avoid design. Keep feature descriptions at a general level. Focus on capabilities needed and why (not how)
they should be implemented.
• If you are using the Rational RequisitePro toolkit, all need to be selected as requirements of type for easy
reference and tracking.]

Page 7
<Project Name> Version: <1.0>
Vision (Small Project) Date: <yyyy-mm-dd>
<document identifier>

[Define the priority of the different system features. Include, if useful, attributes such as stability, benefit, effort, and
risk.]

6. Other Product Requirements

[At a high level, list applicable standards, hardware, or platform requirements; performance requirements; and
environmental requirements.
Define the quality ranges for performance, robustness, fault tolerance, usability, and similar characteristics that are
not captured in the Feature Set.
Note any design constraints, external constraints, or other dependencies.
Define any specific documentation requirements, including user manuals, online help, installation, labeling, and
packaging requirements.
Define the priority of these other product requirements. Include, if useful, attributes such as stability, benefit, effort,
and risk.]

Page 8