Use cases

Define a scenario

ID / Created by	1 / Kai (zafh.net)
Actors
Trigger
Description
Preconditions
Postconditions
Normal Flow
Alternative Flows
Exceptions
Includes
Priority
Frequency of Use
Non-functional Requirements
Assumptions
Notes and Issues

Define a simulation/computation

ID / Created by	2 / Kai (zafh.net)
Actors
Trigger
Description
Preconditions
Postconditions
Normal Flow	Choose method for simulation/computation If required by the chosen method, provide a seed for generating random numbers
Alternative Flows
Exceptions
Includes
Priority
Frequency of Use
Non-functional Requirements
Assumptions
Notes and Issues

Calculate standard yearly building heating demand

ID / Created by	3 / Romain (zafh.net)
Actors	Researcher, Decision Maker
Trigger	User starts use case
Description	Calculate standard yearly heating demand per building, for all types of building, store the results (for a later visualisation). From these results, find out the building energy efficiencies (eventual energy standards, or individual user energy rating).
Preconditions	A scenario must be defined (area and possibly other parameters) Scenario data must be available: localisation of the site Geometrical data of the building Thermal stationary data of the building Additional semantical data (adjacent/outside walls, building usage) Monthly local weather data (mean outside temperature, mean sky temperature, incoming Irradiance per surface orientations). Suited algorithm for simulation or computation must be available and chosen.
Postconditions	Store in a file the standard yearly heating demand [kWh/a] with the corresponding BuildingID, the related reference heated area [m²], and possibly some further "collateral" index (mean Uvalues, Comapcity Index, energy standards). Relate this result file to the simulated scenario (Creation of a ScenarioID?), allowing to find out directly the results file of a simulation already made if the scene is unchanged.
Normal Flow	Import the building parameters, possibly transform/format them Import local weather data statical thermal simulation according with the monthly energy balance Store the results
Alternative Flows	User may additionally trigger a file export of the results (.xls or .csv) with BuildingID and corresponding yearly heating demand. When data are missing, user may opt for (and specify) the creation of synthetic data.
Exceptions	Missing data for scenario Uncoherent parameter (negative volume...) Computation time too large for given Scenario
Includes	Use Case 1: Define a scenario Use Case 2: Define a simulation/computation
Priority	High
Frequency of Use	About once per day
Non-functional Requirements
Assumptions	*A quick computation should be possible using a standard static building heat balance (DIN V 18599, ISO 13790...), with monozone building model or simplified multi-zone building model for multi-usage buildings Stationary thermal building parameters are all available, possibly using building thermal library (with stationary data).
Notes and Issues	Should we give the choice to the user, to use or not a radiation algorithm for the calculation of the incoming irradiance? Could a simulation without irrdaiance mask/exchange consideration, or with a very simplified shadowing factor consideration, be possible (for computation time reason)?

Calculate building efficiency parameters

ID / Created by	4 / Romain (zafh.net)
Actors	Researcher, Decision Maker
Trigger	User starts use case
Description	Calculate energy efficiency related parameters proper to each building: Mean U-Values, Compacity ratio, Available Roof area for PV, Percentage of windows in South/East/West/North orientation etc...
Preconditions	A scenario must be defined (area and possibly other parameters) Scenario data must be available: Geometrical data of the building Thermal stationary data of the building Additional semantical data (adjacent/outside walls, building usage, part of the roof surface available for PV installation)
Postconditions	Store in a file the calculated energy efficiency parameters with the corresponding BuildingID. Relate this result file to the simulated scenario (Creation of a ScenarioID?), allowing to find out directly the results file of a simulation already made if the scene is unchanged.
Normal Flow
Alternative Flows	User may additionally trigger a file export of the results (.xls or .csv) with BuildingID and corresponding energy efficiency parameters. When data are missing, user may opt for (and specify) the creation of synthetic data.
Exceptions	Missing data for scenario Uncoherent parameter (negative volume...) Computation time too large for given Scenario
Includes	Use Case 2: Define a simulation/computation
Priority	High
Frequency of Use	About once per day
Non-functional Requirements
Assumptions
Notes and Issues

Calculate incoming radiation per building surface

ID / Created by	5 / Romain (zafh.net)
Actors	Researcher, Installer of Solar collectors
Trigger	User starts use case Calculation triggered inside another algorithm (heating demand algorithm)
Description	Calculate the incoming radiation per building surface [kWh/m²], taking into account the surrounding urban and relief masks (close and far) as well as the the facades mutual long-wave radiation exchange.
Preconditions	A scenario must be defined (area and possibly other parameters) Scenario data must be available: Geometrical data of the building Characteristics of the bulding surface (absorption coefficient) localisation of the site Additional semantical data (adjacent/outside walls) hourly local beam and diffuse Irradiation. Suited algorithm for simulation or computation must be available and chosen.
Postconditions	Store the incoming radiation per building surface, per given time resolition (hourly / monthly mean value) with the corresponding BuildingID and Surface ID, the related surface area [m²], and the surface type (roof, wall). Relate this result file to the simulated scenario (Creation of a ScenarioID?), allowing to find out directly the results file of a simulation already made if the scene is unchanged.
Normal Flow	Import the building parameters, possibly transform/format them Import the local radiation data radiation computation algorithm Store the results
Alternative Flows
Exceptions	Missing data for scenario Uncoherent parameter (null surface...) Computation time too large for given Scenario
Includes	Use Case 1: Define a scenario
Priority	High
Frequency of Use	About once per day
Non-functional Requirements
Assumptions	A radiation computation algorithm, urban scale compatible, should be available
Notes and Issues

Simulate building heating demand profile

ID / Created by	6 / Romain (zafh.net)
Actors	Researcher, Energy supply companied
Trigger	User starts use case
Description	Simulate hourly heating demand profile per building, for all types of building.
Preconditions	A scenario must be defined (area and possibly other parameters) Scenario data must be available: Localisation of the site Geometrical data of the building Thermal instationary data of the building Daily, weekly and yearly heating/user schedules Additional semantical data (adjacent/outside walls, building usage) Hourly local weather data (Outside temperature, Sky temperature, Incoming irradiance per surface orientation). Suited algorithm for simulation or computation must be available and chosen.
Postconditions	Store in a file the hourly heating demand [kWh/h] with the corresponding BuildingID, the related reference heated area [m²], and possibly some further "collateral" index. Relate this result file to the simulated scenario (Creation of a ScenarioID?), allowing to find out directly the results file of a simulation already made if the scene is unchanged.
Normal Flow	Import the building parameters, possibly transform/format them Calculate the incoming Irradiance for each surface, with a fixed time resolution (month?) Dynamical thermal simulation Store the results
Alternative Flows	When data are missing, user may opt for (and specify) the creation of synthetic data.
Exceptions	Missing data for scenario Uncoherent parameter (negative volume...) Computation time too large for given Scenario
Includes	Use Case 1: Define a scenario Use Case 2: Define a simulation/computation Use Case 5: Calculate incoming radiations per surface
Priority	High
Frequency of Use	About once per week
Non-functional Requirements
Assumptions	*A dynamical (possibly simplified) computation compatible with urban scale issues should be possible, for monozone building model or simplified multi-zone building model for multi-usage buildings Instationary thermal building parameters are all available, possibly using building thermal library (with instationary data).
Notes and Issues	Should we give the choice to the user, to use or not a radiation algorithm for the calculation of the incoming irradiance? Could a simulation without irrdaiance mask/exchange consideration, or with a very simplified shadowing factor consideration, be possible (for computation time reason)?

Simulate building domestic hot water demand profile

ID / Created by	7 / Romain (zafh.net)
Actors	Researcher, Installer of Solar collectors
Trigger	User starts use case Calculation triggered inside another algorithm
Description	Simulate hourly domestic hot water (DHW) demand profile per building, for all types of building, taking into account a possible hot water storage inside the building.
Preconditions	A scenario must be defined (area and possibly other parameters) Scenario data must be available: living area or person numbers Usage and User information
Postconditions	Store in a file the hourly DHW demand [kWh/h] with the corresponding BuildingID, the related reference heated area [m²]. Relate this result file to the simulated scenario (Creation of a SceneID?), allowing to find out directly the results file of a simulation already made if the scenario is unchanged.
Normal Flow	Import the building parameters, possibly transform/format them Dynamical thermal simulation Store the results
Alternative Flows	User may charge an extern files with DHW demand hourly data per building
Exceptions	Missing data for scenario Uncoherent parameter (negative volume...) Computation time too large for given Scenario
Includes	Use Case 1: Define a scenario Use Case 2: Define a simulation/computation
Priority	High
Frequency of Use	About once per day
Non-functional Requirements
Assumptions	*A library of typical pre-defined DHW profiles per building and usage should be available A probabilitics algorithm should be developed to "sum" the DHW profiles.
Notes and Issues

Calculate potential energy savings

ID / Created by	8 / Romain (zafh.net)
Actors	Decision Maker, Municipalities
Trigger	User starts use case
Description	Calculate potential energy savings per building, for all type of building, by comparing the energy consumption (heating demand/heat demand/primary energy/CO2) of a reference scenario (generally the actual present state) with the one of a second pre-defined scenario (generally after refurbishment).
Preconditions	Two scenarios must have been defined (area and possibly other parameters) and simulated Following scenario data must be common for both scenario: localisation of the site Geometrical data of the building Additional semantical data (adjacent/outside walls, building usage) Monthly local weather data (mean outside temperature, mean sky temperature, incoming Irradiance per surface orientations). Following scenario data must be separate for each scenario: Thermal stationary data of the building
Postconditions	Store in a file the energy savings with the corresponding BuildingID.
Normal Flow	Check the compatibility of the 2 scenarios (same BuildingID, same energy calculation algorithm etc..) Import the result files of both scenario Compare them Store the results
Alternative Flows	User may additionally trigger a file import of the results (.xls or .csv) with BuildingID and corresponding yearly heating demand (for example from measures).
Exceptions	Missing data for scenario different BuildingID
Includes
Use Case 1: Define a scenario	Priority	Important
Frequency of Use	About once per week
Non-functional Requirements
Assumptions	The results of previous calculation should have been stored
Notes and Issues

Assistant to design and size energy systems and infrastructures

ID / Created by	9 / Romain (zafh.net)
Actors	Energy supply companies
Trigger	User starts use case
Description	Assist the user for sizing and design the energy systems (energy generation, storage and networks), by simulating the hourly energy demand over a test period in extrem conditions (one winter week for heating installation, one summer week for air-conditionning installation and solar collector for DHW production).
Preconditions	A scenario must be defined (area and possibly other parameters) Scenario data must be available: Type of energy systems per building (including storage) Urban energy infrastructures (network and energy plants)
Postconditions	Store in a file the maximum power/diameter/Storage volume required over the test period, for each energy systems.
Normal Flow	Import the building parameters, possibly transform/format them. Dynamic thermal simulation over the test period. Store the results, relative to each energy systems. Propose energy system sizing to user (if accepted, integer it in the energy systems attributes)
Alternative Flows
Exceptions	Missing data for scenario Uncoherent parameter (required power out of raisonable domain) Computation time too large for given Scenario
Includes	Use Case 1: Define a scenario Use Case 2: Define a simulation/computation Use Case 6: Simulate building heating demand profile Use Case 7: Simulate building DHW demand profile
Priority	Important
Frequency of Use	About once per week
Non-functional Requirements
Assumptions
Notes and Issues

Simulate dynamic energy flux inside the city

ID / Created by	10 / Romain (zafh.net)
Actors	Decision makers, Energy supply companies
Trigger	User starts use case
Description	Simulate all dynamic flux of energy carriers (heat, cooling, fuels, primary energy) inside the city, between the production, the storage, the network systems and the consumers.
Preconditions	A scenario must be defined (area and possibly other parameters) Scenario data must be available: Energy systems with type of fuel and efficiency Urban energy infrastructures (network and energy plants)
Postconditions	Store in a file the hourly energy flux for each energy city objects (building, energy systems, storage, energy plants, network).
Normal Flow
Alternative Flows
Exceptions	Missing data for scenario Uncoherent parameters Computation time too large for given Scenario
Includes	Use Case 1: Define a scenario Use Case 2: Define a simulation/computation Use Case 6: Simulate building heating demand profile Use Case 7: Simulate building DHW demand profile
Priority	Important
Frequency of Use	About once per week
Non-functional Requirements
Assumptions
Notes and Issues

simulation on urban scale

ID / Created by	? / Coors
Actors	researcher / (decision maker)
Trigger	user
Description	A simulation such as head demand simualtion will be applied on a large spatial area, for example an entire city. For research, it is of interest to have such a platform to compare different simulation models as well as the impact of geometric details (LoD1, LoD2, ...) and attributes on the simulation result. It will be wrong for a single building, but might give good results on a larger scale. As we have to deal with large amount of data, it might be wise a avoid data transmission / file handling.
Preconditions	scenario, data and simualtion method must be choosen;
Postconditions	simulation results will be added to the city model / database using an energy application domain extension (to be defined);
Normal Flow	read necessary data from database and perform simulation; store choosen simulation and data as well be be able to compare it with other experiments.
Alternative Flows
Exceptions
Includes
Priority
Frequency of Use
Non-functional Requirements
Assumptions
Notes and Issues	maybe this includes use case 1

visualise simulation results

ID / Created by	? / Coors
Actors	researcher / (decision maker)
Trigger	user
Description	visualize the result of a simulation. In case of PV potential, suited areas could be displayed using a color ramp (not only roofs but also open areas and mybe facades); in case of heat demand, buildings have to be colored; the user will define which data should be displayed and should be able to choose a suitable visualization from a given catalog.
Preconditions	simualtion is performed
Postconditions	interactive 2D or 3D visualization as well as simple diagrams
Normal Flow	read necessary data from database and create a visualization
Alternative Flows
Exceptions
Includes
Priority
Frequency of Use
Non-functional Requirements
Assumptions
Notes and Issues	maybe this includes use case 1

Template (please copy before use)

ID / Created by	? / ?
Actors
Trigger
Description
Preconditions
Postconditions
Normal Flow
Alternative Flows
Exceptions
Includes
Priority
Frequency of Use
Non-functional Requirements
Assumptions
Notes and Issues

How to

Adapted from http://www.processimpact.com/goodies.shtml, Copyright © 2011 by Karl E. Wiegers

Use Case Name	State a concise, results-oriented name for the use case. These reflect the tasks the user needs to be able to accomplish using the system. Include an action verb and a noun. Some examples: View part number information. Manually mark hypertext source and establish link to target. Place an order for a CD with the updated software version.
Use Case ID	Give each use case a unique integer sequence number identifier.
Created by	Supply the name and organization of the person who initially documented this use case.
Actors	An actor is a person or other entity external to the software system being specified who interacts with the system and performs use cases to accomplish tasks. Different actors often correspond to different user classes, or roles, identified from the customer community that will use the product. Name the actor that will be initiating this use case and any other actors who will participate in completing the use case.
Trigger	Identify the event that initiates the use case. This could be an external event or system event that causes the use case to begin, or it could be the first step in the normal flow.
Description	Provide a brief description of the reason for and outcome of this use case, or a high-level description of the sequence of actions and the outcome of executing the use case.
Preconditions	List any activities that must take place, or any conditions that must be true, before the use case can be started. Number each precondition. Examples: User’s identity has been authenticated. User’s computer has sufficient free memory available to launch task.
Postconditions	Describe the state of the system at the conclusion of the use case execution. Number each postcondition. Examples: Document contains only valid SGML tags. Price of item in database has been updated with new value.
Normal Flow	Provide a detailed description of the user actions and system responses that will take place during execution of the use case under normal, expected conditions. This dialog sequence will ultimately lead to accomplishing the goal stated in the use case name and description. This description may be written as an answer to the hypothetical question, “How do I <accomplish the task stated in the use case name>?” This is best done as a numbered list of actions performed by the actor, alternating with responses provided by the system. The normal flow is numbered “X.0”, where “X” is the Use Case ID.
Alternative Flows	Document other, legitimate usage scenarios that can take place within this use case separately in this section. State the alternative flow, and describe any differences in the sequence of steps that take place. Number each alternative flow in the form “X.Y”, where “X” is the Use Case ID and Y is a sequence number for the alternative flow. For example, “5.3” would indicate the third alternative flow for use case number 5.
Exceptions	Describe any anticipated error conditions that could occur during execution of the use case, and define how the system is to respond to those conditions. Also, describe how the system is to respond if the use case execution fails for some unanticipated reason. If the use case results in a durable state change in a database or the outside world, state whether the change is rolled back, completed correctly, partially completed with a known state, or left in an undetermined state as a result of the exception. Number each alternative flow in the form “X.Y.E.Z”, where “X” is the Use Case ID, Y indicates the normal (0) or alternative (>0) flow during which this exception could take place, “E” indicates an exception, and “Z” is a sequence number for the exceptions. For example “5.0.E.2” would indicate the second exception for the normal flow for use case number 5.
Includes	List any other use cases that are included (“called”) by this use case. Common functionality that appears in multiple use cases can be split out into a separate use case that is included by the ones that need that common functionality.
Priority	Indicate the relative priority of implementing the functionality required to allow this use case to be executed. Priority scheme is: High - Medium - Low.
Frequency of Use	Estimate the number of times this use case will be performed by the actors per some appropriate unit of time.
Nonfunctional Requirements	Identify nonfunctional requirements for the use case that may need to be addressed during design or implementation. These may include performance requirements or other quality attributes.
Assumptions	List any assumptions that were made in the analysis that led to accepting this use case into the product description and writing the use case description.
Notes and Issues	List any additional comments about this use case or any remaining open issues or TBDs (To Be Determineds) that must be resolved. Identify who will resolve each issue, the due date, and what the resolution ultimately is.