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