Moji Weather
Requirements Specification

Authors and Contributions Name | Contribution in % | Ideas, Concepts | Parts of the Specification | | | | | | | | | | | | | | | | | | | | |

Prof. Dr. Samuel A. Fricker
Mini Project Requirements Engineering
Moji Weather
Spring 2016

About the Template v1.1E- Spring 2016
The template has been developed for the requirements engineering course offered by Samuel Fricker. The use of the document is continuously reviewed and adapted if necessary. Please direct feedback and recommendations to samuel.a.fricker@gmail.com.
The template is useful for projects that aim at conceiving and developing consumer-oriented software products that may be realized by a team of young software engineers. This template is a tool that may be used to define a software that is as simple as possible and generates as much value as possible.
Each chapter features instructions on what to document. The author of the requirements specification shall not hesitate to adapt the chapter structure. Also, the texts in the template shall be removed and replaced by the actual requirements.
Advise for structuring the contents of a chapter: * Start with a short introduction that describes the role of the chapter and in what relation the chapter is to previous chapters. * Short summary of the chapter contents. * Overview picture or diagram. * Details in tables, texts, and diagrams on a detail level.
Good luck and lots of fun in the discovery of what can be done with software!
/Samuel Fricker

Revisions Version | Date | Comment | Author | Version 0.1 | 20.03.2016 | Template | Samuel Fricker | | | | |

Contents 1 Introduction 5 1.1 The Team 5 1.2 Requirements Engineering Process 5 2 Problem 5 2.1 Background 5 2.2 Goals of a Successful Solution (Product Goals) 6 2.3 Evaluation of Existing Alternatives 6 3 Concept: Moji Weather 9 3.1 Key Idea 9 3.2 Viewpoints 10 3.3 Features 10 3.4 Constraints 11 4 Requirements 12 5 Appendices 12 5.1 Glossary 12 5.2 Future Requirements 13 5.3 Everything Else 13

Introduction
The Team
Short description of the team members, of their backgrounds, and why the team has chosen the here documented future software product.
Min Yuhao
Qi Pengyang
Ruan Yizhang
Zhu Zhanheng
Dong Panhang

Requirements Engineering Process
Summarize how you have elicited, analysed, documented, and validated the requirements. Justify your approach. Explain to what extent the requirements reflect an innovative product that meets true needs.

Problem
Background
The problem that motivates users and customers to use the software system that is specified in the remaining sections.
Formalize the problem description with the following elements of the RUP vision template: * The problem of * Affects * The impact of which is…
Describe the evidence you have, which shows that the problem truly exists and is supported by the software system’s stakeholders.
-------------------------------------------------
Recommendation for Visualization:
- Use Context (with photographs)

Weather is always an important topic in everyone’s life. Not only the weather disaster, such as hurricane and hail, can be life-threatening, but our daily life, activity arrangement, clothing and so on also need to rely on weather report. Although, weather report service can be get from television, radio, newspaper and other traditional media, but they are not portable and instantly.

The problem of: do not know whether to bring an umbrella or not; do not know what to wear; do not know when to hold an activity;
Affects: the public;
The impact of which is: get wet in the rain; suffer from heatstroke; suffer from cold; hold an activity in the rain.

Goals of a Successful Solution (Product Goals)
Criteria for deciding if a solution of the problem is successful. This sub-chapter corresponds to the entry “a successful solution would be…” of the RUP vision template. * Name of the goal (so that you can refer to it), * Description of the goal (what the goal is, why the goal is important and who, besides the customer, may also be affected by it), * Measurement of goal achievement (quantitative criteria for determining when the goal is considered to be achieved)
A successful solution would be: * Good coverage: cover most of the cities in the country. * Air quality: provide air quality information including PM2.5, PM10, SO2, etc. * Weather forecast for next 15 days: provide accurate weather information for the upcoming 15 days. * Suggestions of clothing: tell you what to wear that will make you feel comfortable. * Voice broadcast: read out the information when you are busy doing other things. * Extreme weather alert: push notification when an extreme weather is coming, so you can prepare for it.

Evaluation of Existing Alternatives
What the users and customers have used so far and what other alternatives they could use to solve the problem. Explain why these alternatives are not good enough for achieving the product goals. * Name of the alternative (so that you can refer to it) and description (what the alternative is) * Limitations (why the alternative is not good enough for solving the users’ problem) * Implications for your software (describe what you can re-use and what should be done differently)
-------------------------------------------------
Recommendation for Visualization:
- Appearance of the solution (screen shots or photo documentation)
Traditional medium:
Many traditional medium, such as television, radio, newspaper, and so on, offer weather forecast service. But they have a lot of limitations. For example, they are lack of portability and instantaneity.

Other weather applications:
There are many weather applications in the market. Each application has its advantages and drawbacks. Below, we list three of the most popular weather apps in Google Play Store.

The Weather Channel
This is a weather application provide by The Weather Channel. The Weather Channel is an American basic cable and satellite television channel, owned by a consortium made up of The Blackstone Group, Bain Capital, and NBC Universal.

Pros: Weather Channel data. Handy subtle widgets. Slick new interface. Pollen and airport dalay data. New social weather feature.
Limitations: do not fully support Simplified-Chinese; lack of information;
Implications:

Weather Underground
The Internet's first ever weather site, Weather Underground has built a reputation for providing the most reliable and in-depth weather data for locations across the world. With our unique network of 180,000+ neighbourhood weather stations our app provides the most localized weather information available.

Limitations: do not fully support Simplified-Chinese; lack of information;
Implications:

Yahoo Weather

Pros: Slick design. Flickr images. Numerous widgets. Customizable stream.
Cons: Occasionally sluggish. Few radar map options.
Implications:

Concept: Moji Weather
Key Idea
Describe the key idea of your software system, who will be using the software system, and how the software system allows achieving the product goals.
Summarize the concept by formalizing it with the following elements of the RUP vision template:
-------------------------------------------------
Recommendations for diagrams (and notations or visualizations):
- direct system context (data flow diagram or class diagram)
- use process (BPMN, storyboard, or photo story)
Describe the evidence you have, which shows that the concept works and that the product goals are fulfilled.

For the public;
Who work / go outside;
The weather information provider;
That give information about weather;
Unlike traditional medium is not portable or instant; other weather applications just offer some data;
Our solution gives suggestions (bring / not bring umbrella, what to wear), extreme weather alerts.

Viewpoints
Consider the following viewpoints: * The various user groups * The customer * The provision of the back-end cloud, the app store, and other distribution channels * Third-party systems that your system interoperates with * Other (people, groups, or organizations
-------------------------------------------------
Recommendations for diagrams (and notations or visualizations):
- overview of viewpoints (onion model)
Define for each viewpoint: * Name of the viewpoint (so that you can refer to it) * Characterization (criteria to decide whether a given person matches the role characterized by the viewpoint) * Background (the knowledge of the stakeholders that represent the viewpoint) * Goals (the desired impact of the software on the stakeholders that represent the viewpoint; the goals should be motivating the use of the software) * Representatives (Name, address, etc.) to be involved in requirements engineering

Features
The most important features of the software, which are needed for the achievement of the product goals. A good way to conceive features is to consider the various types of data that are created and managed with the application. Sort the features according to priority for development (at the top the feature that is to be implemented first).
Define for each feature: * Name (so that you can refer to it) * Priority (affects the order of development) * Cost (effort and expenses; affects the order of development) * Short description (what the feature is) * Goals (the impact of the feature on the viewpoints, respectively the fulfilment of the product goal) * Implementation (key idea for implementing the feature)
Check Present Weather Condition:

Check Weather Forecast:

Get Suggestions for Daily Life:

Get Extreme Weather Alert:

Constraints
Decisions that have been imposed by stakeholders and, as a consequence, have to be respected by project management, software system architecture, implementation or testing.
Define for each constraint: * Short description (what the feature is and why it is important for the stakeholders)

Requirements
Check Present Weather Condition

Structure this potentially long chapter so that themes that belong together are put into one single sub-chapter. If possible, create one sub-chapter for each feature. Sort the sub-chapters according to priority in the development (first the sub-chapter that is to be implemented first).
The writing of the chapter depends on the selection of appropriate notations. Transfer actively the course contents (do not re-invent the wheel).

-------------------------------------------------
Recommendations for the structuring of chapter 4:
- Per feature one sub-chapter. Each feature should be scoped so that it makes sense for the user but is still as small as possible. Extensions of a minimal feature should again be presented as a feature and also be listed in chapter 3.3.
- for the totality of quality requirements of the application, consider the definition of one sub-chapter.
-------------------------------------------------
Each sub chapter has the following structure:
- Identifier and name (copy/paste from chapter 3.3).
- Short description (copy/paste from chapter 3.3).
- Short description of how you have elicited, analysed, and validated the feature.
- Short description of the sub-chapter (explanation for the reader of what he/she will be reading. Refer to the diagrams with the help of legends.
- Overview (UML use case diagram).
- Catalogue of use scenarios (use cases as tables with use case attributes and structured text; the flow may also be specified as a UML activity diagram). - The system functionality that is needed to support the use case: requirements backlog (according to selected language template).
- Domain model (UML class diagram). - For important classes: behaviour (UML state machine diagram).
- Graphical user interfaces (wireframes).
- Feature-specific quality requirements.
-------------------------------------------------
Note: adapt the structure of the sub-chapters to minimize the need for text and graphics. Avoid unnecessary information and redundancies as far as possible.
-------------------------------------------------
Note: each content (feature, use case, requirement, class, etc.) shall have a unique identifier that allow unambiguous referencing of that content.
-------------------------------------------------
Note: depending on the software system you may need to change the structure of this chapter. Discuss your proposal with the lecturer.

Appendices
Glossary
Define here the terms and abbreviations that are used in the requirements specification.

Future Requirements
Document the list of the desired improvements, respectively changes of the software that should be realized after your project.

Everything Else
Refer to documents, models, photos, videos, etc., which should be used for understanding the requirements or as evidence that confirms the correctness of the requirements.