Requirements overall description
[edit] Product Perspective
How to
Describe the context and origin of the product being specified in this document. For example, state whether this product is a follow-on member of a product family, a replacement for certain existing systems, or a new, self-contained product. A simple diagram that shows the major components of the overall system, subsystem interconnections, and external interfaces can be helpful.
[edit] Product Features
How to
Summarize the major features the product contains or the significant functions that it performs or lets the user perform. Details will be provided in Section 3, so only a high level summary is needed here. Organize the functions to make them understandable to any reader. A picture of the major groups of related requirements and how they relate, such as a top level data flow diagram or a class diagram, is often effective.
[edit] User Classes and Characteristics
How to
Identify the various user classes that you anticipate will use this product. User classes may be differentiated based on frequency of use, subset of product functions used, technical expertise, security or privilege levels, educational level, or experience. Describe the pertinent characteristics of each user class. Certain requirements may pertain only to certain user classes. Distinguish the favored user classes from those who are less important to satisfy.
Four main groups of potential users are characterized below, from the highest to the lowest expertise level in SimStadt Environment.
[edit] User group A: Software-core developers
- Profile: Team of software developers and experts / scientist responsible for the development and coding of the SimStadt Platform.
They know precisely the coding of the SimStadt Platform.
They may provide simulation algorithms and other data processing functionality as remote services, locally executable programs or libraries, or may implement them newly within the system at source code level. They also will introduce new data sources (databases, sensor networks, or remote services), possibly organized in novel ways, that may be implemented and documented by meta-models like the CityGML Energy ADE.
They want to integrate and evaluate novel data sources and data structures, simulation algorithms, and methods for data analysis with respect to the overall goals of SimStadt. They want also design and implement experimental workflows that combine simulation algorithms, data sources and other functionality in order to perform case studies. Case studies as well as special experimental setups for evaluating simulations algorithms, meta-models etc. will provide first insights into the benefits of the new methods, data and technology for the overall goals of SimStadt.
Example: Hochschule für Technik Stuttgart, other Universities willing to integrate a simulation algorithm/coupling a software
[edit] User group B: Software service providers
- Profile: Software engineering companies or data providers
Software service providers will exploit the new methods, data structures and technologies created by user group A, to develop services and special workflows for typical tasks (consulting, planning, assessing scenarios and so on).
They may be assisted by software developers, for the implementation of these workflows, the creation of tailored GUIs or to provide a suited computational infrastructure.
Example: M.O.S.S.
[edit] User group C: Professional users
Methods, data, workflows, GUIs and computational infrastructure provided by user group A and B may be bundled as software products and/or services that may attract customers from the public administration or consulting firms. These professional users may be willing to pay a price to get high quality results, based on reliable methods and data with small effort. Depending on the task at hand, customers may want to "play around" with planning scenarios, simulation parameters and simulation results.
Professional users can come from different domains and then have different needs/goals regarding the SimStadt Platform:
[edit] C.1 3D City model administrators
- Profile: GIS experts of Municipalities or public organizations.
They are responsible for the data management and data quality in the 3D city model. They may manage the access authorization to the 3D City model.
Example: Landesvermessungamt Badenwürttemberg, City Rotterdam
[edit] C.2 City development managers
- Profile: city planning offices.
Based on the 3D City model, the city development managers may decide the city development strategies at middle/long term, creating and modifying the working plan, introducing sustainable urban energy policies so as to reach the CO2 emission goal (in Germany: outlook 2050)
[edit] C.3 Energy facilities planners
- Profile: HVAC engineering companies
They want to design and plan energy facilies, considering an urban scale.
Thes use the information and calculation results of Simstadt to plan Solar heat and photo-voltaic systems, considering the surrounding urban shadowings. Furthermore, they want to use the geometrical information from the 3D city model as well as the building energy demand profiles calculated in SimStadt for the planning of heating-, water- and gas pipes.
Example: GEF
[edit] C.4 Project Investors
- Profile: promotors of new buildings, housing companies willing to refurbish their building stocks.
Based on the SimStadt Environment and the analysis of the results, these project investors want to use SimStadt as Decision maker concerning new projects and investigations.
Example: Wohnungsbau Ludwigsburg
[edit] C.5 Occasional model users
- Profile: engineers, software engineers, students in urban planning or infrastructure management.
They may use occasionnally the simulation environment to evaluate specific problems and case studies, like the extension of a long-distance heating. They don’t know how work the "core" (coding and algorithm) of the Software, and only want to use some SimStadt models/services.
Example: SENCE Student in HFT Stuttgart
[edit] User group D: Tenants & Owners
- Profile: Citizens, owners
This group of users shall contribute local data about buildings and energy infrastructure (crowd sourcing). The background knowledge and software skills of these users will in general be quite limited (knowledge in general use software like SketchUp, excel...). They might be interested in getting advanced information concerning their personal situation, e.g. comparisons with the peer group, or concrete tips to save energy.
[edit] Operating Environment
How to
Describe the environment in which the software will operate, including the hardware platform, operating system and versions, and any other software components or applications with which it must peacefully coexist.
[edit] Design and Implementation Constraints
How to
Describe any items or issues that will limit the options available to the developers. These might include: corporate or regulatory policies; hardware limitations (timing requirements, memory requirements); interfaces to other applications; specific technologies, tools, and databases to be used; parallel operations; language requirements; communications protocols; security considerations; design conventions or programming standards (for example, if the customer’s organization will be responsible for maintaining the delivered software).
[edit] User Documentation
How to
List the user documentation components (such as user manuals, on-line help, and tutorials) that will be delivered along with the software. Identify any known user documentation delivery formats or standards.
[edit] Assumptions and Dependencies
How to
List any assumed factors (as opposed to known facts) that could affect the requirements stated. These could include third-party or commercial components that you plan to use, issues around the development or operating environment, or constraints. The project could be affected if these assumptions are incorrect, are not shared, or change. Also identify any dependencies the project has on external factors, such as software components that you intend to reuse from another project, unless they are already documented elsewhere (for example, in the vision and scope document or the project plan).
