Wednesday, 8 February 2017

SRS ASSIGMENT

      

                        

FACULTY OF SCIENCE
DEPARTMENT OF INFORMATICS
DEGREE PROGRAMME: BSC. EDUCATION (IM) AND BSC.INFORMATICS
COURSE NAME: INFORMATION SYSTEM DESIGN & ANALYSIS
COURSE CODE:       INF 300

PARTICIPANTS

STUDENT NAME
REG.NO
SIGNATURE
MCHWAMPAKA JOVINA B
INF/D/2014/0026

LUKYAA WITNESS
EIM/D/2014/0066

MWIGEKA OSCAR PETER
INF/D/2014/0004

OUDU FRANK
EIM/D/2014/0078


1         INTRODUCTION


1.1       Purpose

The purpose of  this document  is to describe the software  specification requirements for  Mazimbu Weather Recording  System. The document will describe how the product will collect and display local weather data and analyze the weather forecast. The document contains the functional behavior and non-functional requirements of the system project. The document also contains  the guidelines for system engineers and programmers to start working and accomplish the project on a given time frame. The product will be beneficial to the Mazimbu faculty staff, students and employees.


1.2       Document conventions

The format of this Software Requirement Specifications for Mazimbu Weather Recording  System is simple. Bold face and indentation is used on general topics and on specific points of interest.  The rest  of the document will be written using the standard font, Times New Roman.

1.3       Intended audience and Read suggestions

The intended readers of this document are the developers of the station, testers, station owners, managers and coordinators.
In case of any suggested changes on the requirements listed on this document should be included in the last version of it so it can be a reference to developing and validating teams.

1.4       Product Scope

The software product is named Mazimbu Weather Recording  System . It will be able to collect and display local weather data, analyze weather forecast and display a live stream of the local weather data on autonomous instruments. The product will be beneficial to the Mazimbu faculty staff, students, employees and different organizations who will need weather information from Mazimbu  weather station. The main goal is to have an autonomous record instruments and a database for the safe storage of all the records from the Mazimbu weather station.




1.5       References

·         IEEE 830-1998 standard for writing SRS document.

·         IEEE Std 1233, 1998 Edition, IEEE Guide for Developing System Requirements Specifications.

2. OVERALL DESCRIPTIONS

  2.1 product perspective


 The current Mazimbu weather recording system is synoptic weather station which includes both conversion weather station and an automation weather station.The proposed Mazimbu weather  station is Automation weather station which will make changes of the conversional weather station system and modify the existing automation weather station system. The following is the simple diagram that shows the major components of the overall system:
2.2 Product function
Using  Mazimbu weather  station system users will be able to accomplish the following;
·Get weather forecasting information
·Meteorological information
·Collect and display weather data
·Analyze weather forecasting
·Training skills
·Gets authentication

2.3 user classes and characteristics
There are different users  who interact with the system . The users of the system are the  station manager  Mr.Vitalis and his assistant Mr.Mateleka as the higher level and clients or customers as a lower level with different purpose of interacting with the system.Station manager  and his assistant  interact with the system during recording and measuring of data also the customers and clients interact with the system during acquiring weather information.
2.4 Operating environment.
·Hardware environment
            Mazimbu weather station system at Mazimbu campus is both conversion and automation.In using conversional weather station, a station manager of Mazimbu(Mr.Vitalis) and his assistant Mr.Mateleka measures  and records the weather information manually. While in using  the automation weather station they do not measure weather information manually but, they  record the data directly from the stationwhile the existing automation weather station involves automatically recorded weather information.
·         Software environment
The system needs database that will ensure complete change of conversional weather station to automation weather station and modifying the existing automation weather station and ensure computerization  of the data found.

 2.5 Product constraints

The  Mazimbu weather recording system is limited by  specific technologies, tools, and databases to be used,money or funding for system development and weather measuring instruments.

 2.6 Assumption and dependencies

One assumption about the product is that it will always be implemented and used on hardware devices that is the weather measuring instruments that have good performance.


       3. Specific requirements

This section contains all of the functional and quality requirements of the system. It gives a detailed Descriptionsof the system and all its features found in the system.

            3.1 External interface Requirements

This section provides a detailed description of all inputs into and outputs from the system. It also gives a description of the hardware, software and communication interfaces and provides basic prototypes of the user interface.

            3.1.1.User interface:

A first-time user of the Mazimbu weathering recording system should see the log-in page when he/she opens the application. If the user has not registered, he/she should be able to do that on the log-in page. If the user is not a first-time user, he/she should be able to see the search page directly when the system is opened. Here the user chooses the type of search he/she wants to conduct. Every user should have a profile page where they can edit their e-mail address, phone number and password.

         3.1.2Hardware interfaces

The physical GPS is managed by the GPS application in the mobile phone and the hardware connection to the database server is managed by the underlying operating system on the Mazimbu weathering recording system and the web server.

          3.1.3.Software interfaces

The software interfaces that will be used are GPS and SQL Management Studio.  GPS used to collect  geographical  information of the area around the station and  SQL Management Studio will be used to maintain the database to store the forecast.

 

              3.1.4.Communications interfaces

The communication between the different parts of the system is important since they depend on each Other .There is two interfaces that our system will interact with. The first interface is the Weather Channel website to provide the forecast. The second interface is the camera that the live weather feed will come from. Also there are social networks such as face book, twitter that help communication between the clients or costumers and the workers at the station for more detail or clarification about the service provides by the system.

      4.System Features

This template illustrates organizing the functional requirements for the product by system features, the major services provided by the product. You may prefer to organize this section by use case, mode of operation, user class, object class, functional hierarchy, or combinations of these, whatever makes the most logical sense for your product.

        4.1System Feature agricultural agency

4.1.1    Description and Priority

Provide a short description of the feature and indicate whether it is of High, Medium, or Low priority. You could also include specific priority component ratings, such as benefit, penalty, cost, and right season for transport goods.

4.1.2    Response/Stimulus Sequences

List the sequences of agricultural user action and system responses that stimulate the behavior defined for this feature. These will correspond to the dialog elements associated with use cases.

4.1.3    Functional Requirements

Itemize the detailed functional requirements associated with this feature. These are the software capabilities that must be present in order for the user to carry out the services provided by the feature, or to execute the use case. Include how the product should respond to anticipated error conditions or invalid inputs.

Each requirement should be uniquely identified with a sequence number or a meaningful tag of some kind.


4.2.System Feature SUA staff

4.2.1    Description and Priority

Provide a short description of the staff members to connects the students learning material and the information from the weathering station to be the part of learning material. Alsostudents should know the name of the system and in charge at mazimbu weathering station.

4.2.2    Response/Stimulus Sequences

SUA staff now as auser action and system responses that stimulate the behavior defined for this feature. Staff members will elects to view the practical information from mazimbu weather station.

4.2.3    Functional Requirements

In order to functional requirements associated with this feature. The software capabilities in order for user to carry out the service provided by the feature it must be present, or to execute the use case.

 

  4.3.System Feature water management agency

4.3.1    Description and Priority

Provide a short description of the feature and indicate the rate of water it is of High, Medium, or Low priority. You could also include specific priority component ratings, such as benefit, underground water, cost, and amount of water.

4.3.2.Response/Stimulus Sequences

Water manager agency as a user action get the result from system responses that stimulate the behavior for feature. And this result will based on the options of water manager requirements.

4.3.3    Functional Requirements

Functional requirements associated with this feature can be itemized. Depending on the request of the water manager these are the software capabilities that must be present in order for the user to carry out the services provided by the feature. Include how the result should respondfor the request of the user



5. OTHER NON FUNCTIONAL REQUIREMENTS

5.1.Perfomance requirements

.This section includes the requirements that specify all the fundamental actions of the software system.

5.1.2. Perfomance requirement 1.1

Tool: The SQL management tools
DESC: will be used to maintain the database to store the forecast .
RAT: In order to for a user to use get the required during the search easily  and maintainability  by the administrator easily

5.1.3. Perfomance requirement 1.2

Tool:  search tool
DESC: The different search options should be evident, simple and easy to understand.
RAT: In order to for a user to perform a search easily.

5.1.4 Perfomance requirement 1.3

Usage of the result in the map view
Tool:GPS
DESC: The results displayed geographical information in clearyresolution .
RAT: In order to for a user to use the map view easily.

 

5.1.5. Perfomance requirement 1.4

Tool: System dependability
SCALE:  If the system loses the connection to the Internet or to the GPS device or the system gets some strange input, the user should be informed.
METER: Measurements obtained from 1000 hours of usage during testing.
MUST: 100% of the time.

5.2 Safety requirement

The product of this system has no safety requirements.

5.3.Security requirement

The System needs a strong and healthy security mechanism in place so that unauthorized users are not allowed access. Authorized users are expected to be restricted to software and hardware development, testing, maintenance and operations personnel.
All users of the System must be uniquely identified. This could be done via a username and associated password scheme that would authenticate and authorize the user access to the system and, if applicable, grant the user access to restricted or controlled parts of the system. If a user cannot be identified, they will not be given access. In order to monitor all past access to the system, all attempts to access the system should be logged.
Users’ needs and expectations from the system will be different. Systems operations should be given unrestricted access to all aspects of the system and should have the authority to grant and revoke privileges on a per user basis. Development, testing and maintenance personnel, on the other hand, require access to some parts of the system, but not all, indicating that an access level is needed that allows privileges to be granted on a per-user and what do you need to do basis.
The security should be done through the following way:
Ø  .All users of the system shall login using some form of unique identification. (e.g., username and password)
Ø  Each user shall have a set of system access properties that defines  the user’s privileges within the system.(e.g., the subsystems a user may control or system tools the user may access).
Ø  The administrator shall have the ability to remove a user from the system.
Ø  The administrator shall have the ability to edit a user’s system access properties.
Ø  The administrator shall have the ability to block all access to the system for all users or selectively by user. (All blocked users with active sessions shall automatically be logged off.

5.4 Software Quality Attributes

The additional quality characteristics for the product that will be important to either the customers or the developers are adaptability since the system can be easily adapted in any kind of situation, maintainability as the system will be easily maintained without doubt,usability as the user will be able to use it without fail.

5.5 Business Rules

These are operating principles about the product, such as which individuals or roles can perform which functions under specific circumstances.Station manager Mr.Vitalis and his assistant Mr.Mateleka they record weather information, take measurements, receive payments and give authorization to clients. Sua staff collect Meteorological data from mazimbu weather station that they use in different training of students and other people in need.

 

6.Appendix A: Glossary

This part involves acronyms and abbreviations used in the SRS
SRS: Software Requirements Specification
SQL: Structured query language
GPS: Geographical position system
DESC: Description
RAT: Rate in time
ERD: Entity-relationship diagrams



 Appendix B: Analysis Models

Includes any pertinent analysis models such as data flow diagrams, class diagrams, state-transition diagrams, or entity-relationship diagrams.
For our case we shall involve ERD



DATA FLOW DIAGRAM FOR MAZIMBU WEATHER RECORDING SYSTEM


SOKOINE UNIVERSITY OF AGRICULTURE
FACULTY OF SCIENCE
DEPARTMENT OF INFORMATICS
DEGREE PROGRAMME: Bsc. EDUCATION (IM) AND BSC.INFORMATICS
COURSE NAME: INFORMATION SYSTEM DESIGN & ANALYSIS
COURSE CODE:       INF 300

PARTICIPANTS

STUDENT NAME
REG.NO
SIGNATURE
MCHWAMPAKA JOVINA B
INF/D/2014/0026

LUKYAA WITNESS
EIM/D/2014/0066

MWIGEKA OSCAR PETER
INF/D/2014/0004

OUDU FRANK
EIM/D/2014/0078


USER REQUIREMENTS
Agriculture
Mazimbu Weather stations provide information to users, for example in agricultural activities information can include harvesting time where by the farmer need to know weather condition to know the harvest time also in farm planning a farmer need to know weather condition to plan for farming at the right season. And also in livestock keeping a livestock keeper needs to know the right season for rearing their animals.
SUA staff
Here SUA staff collect Meteorological data from mazimbu weather station that they use in different training of students and other people in need.
Broadcasting stations (TV)
These include televison stations and they require weather forecasting information from mazimbu weather station to help them in maintaining their radio frequencies as they become affected by lightning and rainfall.
Tanzania Meteorological Agency(TMA)
Here  the overall weather stations are handled and it provides some instruments to mazimbu weather station.
Students
Here the students take some training information from the station and use them in conducting projects and after the project they tend to leave the instruments to the station.

  
FEASIBILITY REPORT FOR MAZIMBU WEATHERING RECORDING SYSTEM .

BACKGROUND
          Mazimbu Weather station recording system is situated at Sokoine University Of Agriculture in   Morogoro registered by 9637095 in which 963 is the block number for all East African weather station and 7095 is the station number for Mazimbu weather station which depends on resources from Tanzania Meteorological Agency. The current Mazimbu weather system is synoptic weather station which includes both conversion weather station and an automation weather station. The system proposed at Mazimbu weather  station is Automation weather station which will make changes of the conversional weather station system and modify the existing automation weather station system. Since the conversional weather system involves the station manager’s presence to measure manually the data from weather station which is time consuming and data loss, that means the station manager should be present at any time that the weather changes. In case the station manager is not around during any weather change for instance it is raining or too sunny then there is no possibility of obtaining data. “when am not around data from synoptic weather station cannot be recorded “According to Mr.Vitalis in charge at mazimbu weather station.
CURRENT SYSTEM
The Mazimbu Weather station is under Mr.Vitalis and his assistant Mr.Mateleka who are in charge of controlling, managing, recording, writing weather forecasting reports and providing weather information to companies and individuals who are in need of that information. The current weather system that is being used at Mazimbu is synoptic which is both conversional and automation weather stations. In which  synoptic weather stations are instruments which collect meteorological information at standard times. The common instruments of measure are anemometer, wind vane, pressure sensor, air temperature, humidity, and rain-gauge. In using conversional weather station, a station manager of Mazimbu(Mr.Vitalis) and his assistant Mr.Mateleka measures  and records the weather information manually. While the automation weather station is the type of weather station that gather high-quality, real-time data that is used in a variety of weather observation activities. In this type of weather station the station manager Mazimbu(Mr.Vitalis) his assistant Mr.Mateleka do not measure weather information manually but, they  record the data directly from Mazimbu weather station instruments at real times. So Mazimbu weather station collects weather information from both synoptic and automatic weather stations.


 PROPOSED SYSTEM
The proposed system at Mazimbu weather station is automation weather station that will change  the Mazimbu synoptic weather station by replacing conversional weather station to automation weather station and modifying the existing automation weather station and the records should be computerized. Through provision of  more weather recording instruments and other necessary requirements such as experts will ensure complete change of conversional weather station to automation weather station and modifying the existing automation weather station. The proposed system will solve the problem of time consuming since the automation system will not need the station manager to take measurements manually and data loss since automation does not require paper records.
METHODOLOGY
The methods used  in collecting data for this case study was face to face in which group members together went to Mr.Vitalis in charge of  Mazimbu weather station and had a couple of questions to ask concerning weather requirements of the user. From this method of data collection me and my group members obtained the information we needed for the establishment of automation weather recording system.

COST AND BENEFITS
The proposed automation weather system requires a small area of (60*40)meters which needs just a little amount of money for being constructed.  Also measuring instruments are not replaced  time to time since they are long lasting. Therefore this system does not meet repair costs. In providing the weather forecasting data, Mazimbu weather system requires little funding and provide enough required information.


 CONCLUSION
Generally, Mazimbu synoptic weather station will be replaced by automation weather station which will assist the mazimbu in charge weather Mr.Vitalis in easy record and storage of weather forecasting information. As this computerize automation system will store data in  secured and long term memory that as it was kept in papers and files.


RECOMMENDATION
The automation weather system that we have proposed will be time effective since the weather data will be recorded automatically and also data will be computerized and converted automatically thus time is less in automation weather station than conversional weather station.

CONTEXT DIAGRAM MAZIMBU WEATHER RECORDING SYSTEM


 LEVEL 0 DIAGRAM MAZIMBU WEATHER RECORDING SYSTEM





 DFD LEVEL 1 PROCESS 1

DFD LEVEL 1 PROCESS 2




  
DFD LEVEL 1 PROCESS 3






DFD LEVEL 1 PROCESS 4



ENTITY RELATIONSHIP DIAGRAM FOR MAZIMBU WEATHER RECORDING SYSTEM


DATA RELATIONSHIP DIAGRAM  FOR MAZIMBU WEATHER RECORDING SYSTEM

DREAM-HOME


\
SOKOINE UNIVERSITY OF AGRICULTURE









FACULTY OF SCIENCE
DEPARTMENT OF INFORMATICS
DEGREE PROGRAMME: BSC. EDUCATION (IM) AND BSC.INFORMATICS
COURSE NAME: INFORMATION SYSTEM DESIGN & ANALYSIS
COURSE CODE:       INF 300

PARTICIPANTS

STUDENT NAME
REG.NO
SIGNATURE
MCHWAMPAKA JOVINA B
INF/D/2014/0026

LUKYAA WITNESS
EIM/D/2014/0066

MWIGEKA OSCAR PETER
INF/D/2014/0004

OUDU FRANK
EIM/D/2014/0078


CONTEXT DIAGRAM FOR DREAM-HOME 




   LEVEL “0” DIAGRAM FOR DREAMHOME



LEVEL “1” DIAGRAM FOR PROCESS ONES


LEVEL “1” DIAGRAM FOR PROCESS TWO



LEVEL “1” DIAGRAM FOR PROCESS THREE



LEVEL “1” DIAGRAM FOR PROCESS  FOUR


LEVEL “1” DIAGRAM FOR PROCESS  FIVE






LEVEL”1” DIAGRAM FOR PROCESS SIX AND SEVEN:




ENTITY RELATIONSHIP DIAGRAM (ERD) FOR DREAMHOME




DATA DICTIONARY FOR PROPERTIES FOR RENT
properties_for_rent = property_no + property_type + no_of_rooms + monthly_rent + property_owner
property_number = {A-Z | 0-9 | special characters}
special characters = {/ -}
property_type = fixed_property + movable_property
fixed_property = {characters}
movable_property = {characters}
character = {A-Z | a-z}
no_of_rooms = integer
monthly_rent = {amount}
property_owner = {staff_no}


DATA DICTIONARY FOR PROPERTY OWNERS
property_owner = private_owner + business_owner
private_owner= owner_no + owner_name + owner_address + owner_telephone_no
owner_no = {integer}+ special_character
special_character= {/}
owner_name ={first_name + (middle_name) + surname}
owner_address = {street + city + postcode}
telephone_no = {country_code + local_number + user_number}
business_owner = business_id + business_name  +  type_of_business  +  business_address  +  business_tel_no
business_name = {character}
business_type = {character}
business _address = {street + city + postcode}
business _tel_no = {country_code + local_number + user_number}
business_contact_name = {characters}


DATA DICTIONARY FOR CLIENT
client= client_no+ name + telephone _number+ accommodation  + max_rent  + staff
client_no=  integer  + (special_char)
integer = 0-9
special_char =[#;/;@ ;$;&]
client_name = {title + firstName + (middleName) + surname}
title = [Mr | Mrs | Miss | Dr | Prof | Rev | Sheikh | Eng]
client_telephone_no ={ country_code + local_number + user_number}
accommodation_type = [permanent |  temporary]
max_rent ={ £}
staff = registration + client_date + branch_details
registration = {integer}
{integer} = 0 – 9
client_date = {date}
branch_details = name+number
name={characters}
number={interger}


DATA DICTIONARY FOR LEASE
lease = lease_no  + client + property
lease_no = {integer}
client = client_no + client_name + client_address
client_no = {characters}
client_name = {title + firstName + (middleName) + surname }
client_address = {street + city + postcode }
property = property_no + monthly_rent + method_of_payment + duration_of_lease
property_no = {characters}
monthly_rent = {£}
method_of_payment = [cash | cheque]
duration_of_lease = date_lease_start + date_lease_finish
date_lease_start = {date}
date_lease_finish = {date}