From 9c2f41fecbeed9df2f42cef1abde43dd35334153 Mon Sep 17 00:00:00 2001 From: Marnix Kraus Date: Tue, 8 Oct 2024 09:28:09 +0200 Subject: [PATCH 01/12] Update SRS with more details --- docs/dev/srs.md | 154 +++++++++++++++++++++++++++--------------------- 1 file changed, 87 insertions(+), 67 deletions(-) diff --git a/docs/dev/srs.md b/docs/dev/srs.md index cede1834..e261c6c0 100644 --- a/docs/dev/srs.md +++ b/docs/dev/srs.md @@ -3,22 +3,26 @@ -- [Introduction](#introduction) - - [Product scope](#product-scope) - - [Product value](#product-value) - - [Intended audience:](#intended-audience) - - [Intended use:](#intended-use) +- [FloPy 4 software requirement specifications (SRS)](#flopy-4-software-requirement-specifications-srs) + - [Introduction](#introduction) + - [Product scope](#product-scope) + - [Product value](#product-value) + - [Intended audience](#intended-audience) + - [Intended use](#intended-use) - [Use cases](#use-cases) -- [System requirements and functional requirements](#system-requirements-and-functional-requirements) -- [External interface requirements](#external-interface-requirements) -- [Non-functional requirements (NRFs)](#non-functional-requirements-nrfs) -- [Motivation](#motivation) - - [Consistency](#consistency) - - [Maintenance](#maintenance) - - [Introspection](#introspection) - - [Performance](#performance) - - [Invariants](#invariants) -- [Goals](#goals) + - [System requirements and functional requirements](#system-requirements-and-functional-requirements) + - [System requirements](#system-requirements) + - [Functional requirements](#functional-requirements) + - [External interface requirements](#external-interface-requirements) + - [Non-functional requirements (NRFs)](#non-functional-requirements-nrfs) + - [Maintainability](#maintainability) + - [Motivation](#motivation) + - [Consistency](#consistency) + - [Maintenance](#maintenance) + - [Introspection](#introspection) + - [Performance](#performance) + - [Invariants](#invariants) + - [Goals](#goals) @@ -29,92 +33,108 @@ called *the product* or flopy4. ### Product scope -flopy4 will be a software product to pre- and post-Process MODFLOW-based -model input and output. +flopy4 will be a software product to pre- and post-process MODFLOW-based model input and output. +Pre-processing will be limited to preparing model input datasets. +Post-processing will be limited to reading model output into internal data formats that can be used by the product. +For specific use cases, model input and output data will be processed by the product into formats that can be analyzed in other libraries. -Pre-processing will be limited to preparing model input datasets. +The product will be able to run MODFLOW simulations. -Post-processing will be limited to reading model output into internal data formats -that can be used by the product. +The product can load existing model input datasets that were not necessarily created by the product, but conform to MODFLOW input and output specifications. -For specific use cases, model input and output data will be processed by the -product into formats that can be analyzed in other libraries. - -The product will also be able to run MODFLOW simulations. - -The product can load existing model input datasets that were not necessarily -created by the product but conform to MODFLOW input and output specifications. - -flopy4 will replace the MODFLOW 6 targeted capabilities of the current FloPy 3. +flopy4 will replace the MODFLOW 6 targeted capabilities of the current FloPy 3 library. flopy4 will also replace the following capabilities of FloPy 3: - * PEST (?) - * capability 2 (discuss) + +- PEST (?) +- capability 2 (discuss) ### Product value The product will allow defining reproducible, versionable Python workflows for -MODFLOW modeling applications. +MODFLOW modeling applications. -The product will wrap MODFLOW and other programs and provide a Pythonic interface -to their functionality and input and output files. +The product will wrap MODFLOW and other programs and provide a Pythonic interface to their functionality and input and output files. -flopy4 is essential to the MODFLOW development process for testing existing and -newly developed functionality. +flopy4 is essential to the MODFLOW development process for testing existing and newly developed functionality. -### Intended audience: +flopy4 will be compatible with the definition files (DFNs) that come with MODFLOW 6, and will thus always be up-to-date with the latest MODFLOW 6 capabilities. -Hydrologic scientists, engineers, and students who are familiar with the Python -ecosystem and want to use MODFLOW for their hydrologic applications. The other -key audience is the team of MODFLOW software developers. +### Intended audience -### Intended use: +Hydrologic scientists, engineers, and students who are familiar with the Python ecosystem and want to use MODFLOW for their hydrologic applications. +The other key audience is the team of MODFLOW software developers. -The product should be available on the major operating systems -(Windows, Linux, MacOS) and hardware ranging from laptops to HPC systems. +### Intended use -The product will be used through Python scripts and Jupyter notebooks. +The product should be available on the major operating systems (Windows, Linux, MacOS) and hardware ranging from laptops to HPC systems. +The product will be used through Python scripts and Jupyter notebooks. -The product can be relied upon as a core component by other libraries and -tools that offer more advanced or domain specific or application specific -functionality. +The product can be relied upon as a core component by other libraries and tools that offer more advanced, domain specific, or application specific functionality. -#### Use cases +### Use cases -* A hydrologist needs to determine an optimal pumping rate for a well field... +- A hydrologist needs to determine an optimal pumping rate for a well field... -* A student wants to simulate salt water intrusion in a coastal aquifer and -visualize results... +- A student wants to simulate salt water intrusion in a coastal aquifer and visualize results... -* A professor is teaching a groundwater modeling class... +- A professor is teaching a groundwater modeling class... -* A hydrologic institute maintains their own suite of advanced pre- and -post-processing utilities that can rely on flopy4 as a component for its -core capabilities... +- A hydrologic institute maintains their own suite of advanced pre- and post-processing utilities that can rely on flopy4 as a component for its core capabilities... -* A MODFLOW developer is debugging an issue in the UZF package and wants to -create a complicated test with many cells and stress periods... +- A MODFLOW developer is debugging an issue in the UZF package and wants to create a complicated test with many cells and stress periods... -* A MODFLOW developer is setting up a worked example to demonstrate how to -use a new feature... +- A MODFLOW developer is setting up a worked example to demonstrate how to use a new feature... ## System requirements and functional requirements -tbd + +### System requirements + +flopy4 must be able to run within a python environment supporting versions that comply with scientific-python.org guidelines: . This is due to its dependency on the Numpy and XArray libraries, and flopy4 should not be conflicting with user installed libraries. + +The product must be able to run on the following operating systems: Windows, Linux, MacOS. + +The product must be distributed via the Python Package Index (PyPI) and be installable via pip. Additionally, the product must be installable via conda-forge. + +### Functional requirements + +flopy4 must be able to read and write MODFLOW 6 input files and read MODFLOW 6 output files. + +flopy4 must be able to run MODFLOW 6 simulations. + +flopy4 must work with multiple versions of MODFLOW 6, based on the DFN files. And it can support all packages that come with that version of MODFLOW 6. + +The product lets the user define a model domain, including grid dimensions, cell sizes, and boundary conditions. + +flopy4 can create grid definitions in different formats: structured, unstructured, **... (more)** + +flopy4 can create MODFLOW models that support parallel processing. + +The product contains functions to plot model output and gives the user configurable or extendable options for customization. + +The product can export its internal data model to different types of file formats, such as NetCDF, VTK, and geospatial standards. + +Extensive validation on the final input model can be used to ensure that the model is correct before running the simulation. The validation can be extended by the user to include custom checks. ## External interface requirements -tbd + +flopy4 should give the opportunity for external libraries to extend its capabilities by providing a plugin system. This can be useful for new plotting mechanisms, file export formats, or custom input file formats that can be converted to MODFLOW data. + +New DFN files should be compatible with flopy4, and the product should be able to generate a definition of the packages that are applicable to that version of MODFLOW 6. ## Non-functional requirements (NRFs) -tbd -**Maintainability** +The product must be able to create large models that are larger than the available memory on the user's machine. + +The product should be able to create an example model of the United States with a **?1 km?** grid resolution. + +Clear and informative error messages should be provided to the user when an error occurs, also during model input validation. + +### Maintainability flopy4 should maintain a separation of concerns with respect to hydrology and software engineering. The hydrologic modeler should not be concerned with the -technical details of flopy4's internal data storage or parallel processing -implementation, for example, and a software engineer should be able to work -on the code without detailed knowledge on complex hydrologic concepts. - +technical details of flopy4's internal data storage or parallel processing implementation, for example, and a software engineer should be able to work on the code without detailed knowledge on complex hydrologic concepts. ## Motivation From aaf2266a51a335d1d7cd7f6c715f0f29f3d6d63c Mon Sep 17 00:00:00 2001 From: Marnix <150045289+deltamarnix@users.noreply.github.com> Date: Mon, 14 Oct 2024 10:36:50 +0200 Subject: [PATCH 02/12] Apply suggestions from code review Co-authored-by: langevin-usgs --- docs/dev/srs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/dev/srs.md b/docs/dev/srs.md index e261c6c0..506f0c42 100644 --- a/docs/dev/srs.md +++ b/docs/dev/srs.md @@ -90,7 +90,7 @@ The product can be relied upon as a core component by other libraries and tools ### System requirements -flopy4 must be able to run within a python environment supporting versions that comply with scientific-python.org guidelines: . This is due to its dependency on the Numpy and XArray libraries, and flopy4 should not be conflicting with user installed libraries. +flopy4 must be able to run within a python environment supporting versions that comply with scientific-python.org guidelines: . This is due to its dependency on the Numpy, Matplotlib, and XArray libraries, and flopy4 should not be conflicting with user installed libraries. The product must be able to run on the following operating systems: Windows, Linux, MacOS. @@ -102,7 +102,7 @@ flopy4 must be able to read and write MODFLOW 6 input files and read MODFLOW 6 o flopy4 must be able to run MODFLOW 6 simulations. -flopy4 must work with multiple versions of MODFLOW 6, based on the DFN files. And it can support all packages that come with that version of MODFLOW 6. +flopy4 must work with multiple versions of MODFLOW 6, based on the DFN files. And it must support all packages that come with that version of MODFLOW 6. The product lets the user define a model domain, including grid dimensions, cell sizes, and boundary conditions. From a07b15297a1306d8a80d9d7ef2fa0eaaa61764c2 Mon Sep 17 00:00:00 2001 From: Marnix Kraus Date: Mon, 14 Oct 2024 10:54:21 +0200 Subject: [PATCH 03/12] Remove PEST capability from SRS --- docs/dev/srs.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/docs/dev/srs.md b/docs/dev/srs.md index 506f0c42..febfcabf 100644 --- a/docs/dev/srs.md +++ b/docs/dev/srs.md @@ -44,11 +44,6 @@ The product can load existing model input datasets that were not necessarily cre flopy4 will replace the MODFLOW 6 targeted capabilities of the current FloPy 3 library. -flopy4 will also replace the following capabilities of FloPy 3: - -- PEST (?) -- capability 2 (discuss) - ### Product value The product will allow defining reproducible, versionable Python workflows for From fa95a1651c57439226371d9f4b718f0a6407d6b5 Mon Sep 17 00:00:00 2001 From: Marnix Kraus Date: Mon, 14 Oct 2024 11:54:30 +0200 Subject: [PATCH 04/12] Add some parts to the scope of the SRS --- docs/dev/srs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/dev/srs.md b/docs/dev/srs.md index febfcabf..27e012af 100644 --- a/docs/dev/srs.md +++ b/docs/dev/srs.md @@ -34,8 +34,8 @@ called *the product* or flopy4. ### Product scope flopy4 will be a software product to pre- and post-process MODFLOW-based model input and output. -Pre-processing will be limited to preparing model input datasets. -Post-processing will be limited to reading model output into internal data formats that can be used by the product. +Pre-processing will be limited to preparing model input datasets, mesh generation, and model input manipulation capabilities. +Post-processing will be limited to reading model output into internal data formats that can be used by the product, plotting utilities, and rudimentary analysis capabilities. For specific use cases, model input and output data will be processed by the product into formats that can be analyzed in other libraries. The product will be able to run MODFLOW simulations. From e63657edb2a57551fbf33f1e56c78bfec060221a Mon Sep 17 00:00:00 2001 From: Marnix Date: Wed, 6 Nov 2024 14:16:17 +0100 Subject: [PATCH 05/12] Add more requirements to the SRS --- docs/dev/srs.md | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/docs/dev/srs.md b/docs/dev/srs.md index 27e012af..40ec23f9 100644 --- a/docs/dev/srs.md +++ b/docs/dev/srs.md @@ -63,7 +63,7 @@ The other key audience is the team of MODFLOW software developers. ### Intended use The product should be available on the major operating systems (Windows, Linux, MacOS) and hardware ranging from laptops to HPC systems. -The product will be used through Python scripts and Jupyter notebooks. +The product will be used through Python scripts, Jupyter notebooks, pytest, and ipython. The product can be relied upon as a core component by other libraries and tools that offer more advanced, domain specific, or application specific functionality. @@ -101,9 +101,9 @@ flopy4 must work with multiple versions of MODFLOW 6, based on the DFN files. An The product lets the user define a model domain, including grid dimensions, cell sizes, and boundary conditions. -flopy4 can create grid definitions in different formats: structured, unstructured, **... (more)** +flopy4 can create grid definitions in different formats: structured (DIS), vertex (DISV), unstructured (DISU). And is open for expansion of new grid definitions. -flopy4 can create MODFLOW models that support parallel processing. +flopy4 can create MODFLOW models that support parallel processing. It can pre-process models by splitting them up, ready for parallel computation. The product contains functions to plot model output and gives the user configurable or extendable options for customization. @@ -111,13 +111,25 @@ The product can export its internal data model to different types of file format Extensive validation on the final input model can be used to ensure that the model is correct before running the simulation. The validation can be extended by the user to include custom checks. +Instantiation of packages and models should work in an intuitive way, the user should not be stuck with specific orders of function calls. E.g., packages can be created without creating a simulation or model first. + ## External interface requirements flopy4 should give the opportunity for external libraries to extend its capabilities by providing a plugin system. This can be useful for new plotting mechanisms, file export formats, or custom input file formats that can be converted to MODFLOW data. New DFN files should be compatible with flopy4, and the product should be able to generate a definition of the packages that are applicable to that version of MODFLOW 6. -## Non-functional requirements (NRFs) +The product strives for a consistency in its public API between MODFLOW6 and older MODFLOW packages. + +The product has programmatic access to example models, to make it quick for the user to run an example model, or to alter the examples to their liking. + +Input parameters have clear units to avoid confusion. E.g., using SI units only, or by providing usage of a python units package. + +The product has a unified understanding of date and time. + +The user is aided in their development process by providing python type hints directly from the API with accompanying documentation on all the input parameters. + +## Non-functional requirements (NFRs) The product must be able to create large models that are larger than the available memory on the user's machine. @@ -125,6 +137,10 @@ The product should be able to create an example model of the United States with Clear and informative error messages should be provided to the user when an error occurs, also during model input validation. +The user documentation makes a clear distinction in user public and internal API. + +The user documentation provides a complete overview of the definition file specification. + ### Maintainability flopy4 should maintain a separation of concerns with respect to hydrology and From 31b3206cc78f8b3b0c48b1dccb468ea74aea330f Mon Sep 17 00:00:00 2001 From: Marnix Date: Wed, 6 Nov 2024 14:26:11 +0100 Subject: [PATCH 06/12] Move motivation to the top --- docs/dev/srs.md | 144 ++++++++++++++++++++++++------------------------ 1 file changed, 72 insertions(+), 72 deletions(-) diff --git a/docs/dev/srs.md b/docs/dev/srs.md index 40ec23f9..392b5af2 100644 --- a/docs/dev/srs.md +++ b/docs/dev/srs.md @@ -10,18 +10,18 @@ - [Intended audience](#intended-audience) - [Intended use](#intended-use) - [Use cases](#use-cases) - - [System requirements and functional requirements](#system-requirements-and-functional-requirements) - - [System requirements](#system-requirements) - - [Functional requirements](#functional-requirements) - - [External interface requirements](#external-interface-requirements) - - [Non-functional requirements (NRFs)](#non-functional-requirements-nrfs) - - [Maintainability](#maintainability) - [Motivation](#motivation) - [Consistency](#consistency) - [Maintenance](#maintenance) - [Introspection](#introspection) - [Performance](#performance) - [Invariants](#invariants) + - [System requirements and functional requirements](#system-requirements-and-functional-requirements) + - [System requirements](#system-requirements) + - [Functional requirements](#functional-requirements) + - [External interface requirements](#external-interface-requirements) + - [Non-functional requirements (NRFs)](#non-functional-requirements-nfrs) + - [Maintainability](#maintainability) - [Goals](#goals) @@ -81,72 +81,6 @@ The product can be relied upon as a core component by other libraries and tools - A MODFLOW developer is setting up a worked example to demonstrate how to use a new feature... -## System requirements and functional requirements - -### System requirements - -flopy4 must be able to run within a python environment supporting versions that comply with scientific-python.org guidelines: . This is due to its dependency on the Numpy, Matplotlib, and XArray libraries, and flopy4 should not be conflicting with user installed libraries. - -The product must be able to run on the following operating systems: Windows, Linux, MacOS. - -The product must be distributed via the Python Package Index (PyPI) and be installable via pip. Additionally, the product must be installable via conda-forge. - -### Functional requirements - -flopy4 must be able to read and write MODFLOW 6 input files and read MODFLOW 6 output files. - -flopy4 must be able to run MODFLOW 6 simulations. - -flopy4 must work with multiple versions of MODFLOW 6, based on the DFN files. And it must support all packages that come with that version of MODFLOW 6. - -The product lets the user define a model domain, including grid dimensions, cell sizes, and boundary conditions. - -flopy4 can create grid definitions in different formats: structured (DIS), vertex (DISV), unstructured (DISU). And is open for expansion of new grid definitions. - -flopy4 can create MODFLOW models that support parallel processing. It can pre-process models by splitting them up, ready for parallel computation. - -The product contains functions to plot model output and gives the user configurable or extendable options for customization. - -The product can export its internal data model to different types of file formats, such as NetCDF, VTK, and geospatial standards. - -Extensive validation on the final input model can be used to ensure that the model is correct before running the simulation. The validation can be extended by the user to include custom checks. - -Instantiation of packages and models should work in an intuitive way, the user should not be stuck with specific orders of function calls. E.g., packages can be created without creating a simulation or model first. - -## External interface requirements - -flopy4 should give the opportunity for external libraries to extend its capabilities by providing a plugin system. This can be useful for new plotting mechanisms, file export formats, or custom input file formats that can be converted to MODFLOW data. - -New DFN files should be compatible with flopy4, and the product should be able to generate a definition of the packages that are applicable to that version of MODFLOW 6. - -The product strives for a consistency in its public API between MODFLOW6 and older MODFLOW packages. - -The product has programmatic access to example models, to make it quick for the user to run an example model, or to alter the examples to their liking. - -Input parameters have clear units to avoid confusion. E.g., using SI units only, or by providing usage of a python units package. - -The product has a unified understanding of date and time. - -The user is aided in their development process by providing python type hints directly from the API with accompanying documentation on all the input parameters. - -## Non-functional requirements (NFRs) - -The product must be able to create large models that are larger than the available memory on the user's machine. - -The product should be able to create an example model of the United States with a **?1 km?** grid resolution. - -Clear and informative error messages should be provided to the user when an error occurs, also during model input validation. - -The user documentation makes a clear distinction in user public and internal API. - -The user documentation provides a complete overview of the definition file specification. - -### Maintainability - -flopy4 should maintain a separation of concerns with respect to hydrology and -software engineering. The hydrologic modeler should not be concerned with the -technical details of flopy4's internal data storage or parallel processing implementation, for example, and a software engineer should be able to work on the code without detailed knowledge on complex hydrologic concepts. - ## Motivation FloPy 3 supports a wide range of functionality, but presents challenges @@ -220,3 +154,69 @@ With the above in mind, we want the next version of FloPy to - be easy to read, debug, diagnose and test - be memory-efficient and provide fast IO - impose a minimal maintenance burden + +## System requirements and functional requirements + +### System requirements + +flopy4 must be able to run within a python environment supporting versions that comply with scientific-python.org guidelines: . This is due to its dependency on the Numpy, Matplotlib, and XArray libraries, and flopy4 should not be conflicting with user installed libraries. + +The product must be able to run on the following operating systems: Windows, Linux, MacOS. + +The product must be distributed via the Python Package Index (PyPI) and be installable via pip. Additionally, the product must be installable via conda-forge. + +### Functional requirements + +flopy4 must be able to read and write MODFLOW 6 input files and read MODFLOW 6 output files. + +flopy4 must be able to run MODFLOW 6 simulations. + +flopy4 must work with multiple versions of MODFLOW 6, based on the DFN files. And it must support all packages that come with that version of MODFLOW 6. + +The product lets the user define a model domain, including grid dimensions, cell sizes, and boundary conditions. + +flopy4 can create grid definitions in different formats: structured (DIS), vertex (DISV), unstructured (DISU). And is open for expansion of new grid definitions. + +flopy4 can create MODFLOW models that support parallel processing. It can pre-process models by splitting them up, ready for parallel computation. + +The product contains functions to plot model output and gives the user configurable or extendable options for customization. + +The product can export its internal data model to different types of file formats, such as NetCDF, VTK, and geospatial standards. + +Extensive validation on the final input model can be used to ensure that the model is correct before running the simulation. The validation can be extended by the user to include custom checks. + +Instantiation of packages and models should work in an intuitive way, the user should not be stuck with specific orders of function calls. E.g., packages can be created without creating a simulation or model first. + +## External interface requirements + +flopy4 should give the opportunity for external libraries to extend its capabilities by providing a plugin system. This can be useful for new plotting mechanisms, file export formats, or custom input file formats that can be converted to MODFLOW data. + +New DFN files should be compatible with flopy4, and the product should be able to generate a definition of the packages that are applicable to that version of MODFLOW 6. + +The product strives for a consistency in its public API between MODFLOW6 and older MODFLOW packages. + +The product has programmatic access to example models, to make it quick for the user to run an example model, or to alter the examples to their liking. + +Input parameters have clear units to avoid confusion. E.g., using SI units only, or by providing usage of a python units package. + +The product has a unified understanding of date and time. + +The user is aided in their development process by providing python type hints directly from the API with accompanying documentation on all the input parameters. + +## Non-functional requirements (NFRs) + +The product must be able to create large models that are larger than the available memory on the user's machine. + +The product should be able to create an example model of the United States with a **?1 km?** grid resolution. + +Clear and informative error messages should be provided to the user when an error occurs, also during model input validation. + +The user documentation makes a clear distinction in user public and internal API. + +The user documentation provides a complete overview of the definition file specification. + +### Maintainability + +flopy4 should maintain a separation of concerns with respect to hydrology and +software engineering. The hydrologic modeler should not be concerned with the +technical details of flopy4's internal data storage or parallel processing implementation, for example, and a software engineer should be able to work on the code without detailed knowledge on complex hydrologic concepts. From 676c8ef97c3eab774cb9e0e14bb94c88a75a6f15 Mon Sep 17 00:00:00 2001 From: Marnix Date: Wed, 6 Nov 2024 14:34:11 +0100 Subject: [PATCH 07/12] More SRS cleanup --- docs/dev/srs.md | 63 ++++++++++++++++++------------------------------- 1 file changed, 23 insertions(+), 40 deletions(-) diff --git a/docs/dev/srs.md b/docs/dev/srs.md index 392b5af2..3f2b9980 100644 --- a/docs/dev/srs.md +++ b/docs/dev/srs.md @@ -94,36 +94,27 @@ in several areas: ### Consistency -The `flopy.mf6` module departs considerably from the older `flopy.modflow` -module. This requires more memorization (or more R'ing TFM) for users and -developers alike, and makes maintenance harder. - +The `flopy.mf6` module departs considerably from the older `flopy.modflow` module. +This requires more memorization (or more R'ing TFM) for users and developers alike, and makes maintenance harder. Both modules are strongly coupled to the relevant programs' input format. -We would like a consistent core framework for any modeling program, which -can be applied to MODFLOW 6, older MODFLOW programs, and other hydrologic -simulators. The framework should be agnostic to the IO format used by any -particular program. +We would like a consistent core framework for any modeling program, which can be applied to MODFLOW 6, older MODFLOW programs, and other hydrologic simulators. +The framework should be agnostic to the IO format used by any particular program. ### Maintenance -The `flopy.mf6` module is large and developers have struggled to maintain -it. Deep abstraction in the object model raises barriers to comprehension -and error messages are not easy to trace back to the offending component. +The `flopy.mf6` module is large and developers have struggled to maintain it. +Deep abstraction in the object model raises barriers to comprehension and error messages are not easy to trace back to the offending component. Debugging is also difficult. ### Introspection -Component classes reproduce their input specification verbatim. This is -redundant and yet not particularly useful or Pythonic; more informative -would be a format-agnostic specification in terms of Python primitives, -containers, and classes, which can be translated into any given format -upon request. This allows flexibility to translate DFN specifications -to a different format, e.g. TOML, YAML or JSON. +Component classes reproduce their input specification verbatim. +This is redundant and yet not particularly useful or pythonic; +more informative would be a format-agnostic specification in terms of Python primitives, containers, and classes, which can be translated into any given format upon request. +This allows flexibility to translate DFN specifications to a different format, e.g. TOML, YAML or JSON. -Component classes also provide a data access layer via `.get_data()` and -`set_data()` — it would be simpler just to get/set the attributes -normally and intercept these behind the scenes for any magic necessary. +Component classes also provide a data access layer via `.get_data()` and `set_data()` — it would be simpler just to get/set the attributes normally and intercept these behind the scenes for any magic necessary. ### Performance @@ -131,26 +122,23 @@ TODO: describe current issues ### Invariants -FloPy 3 has a "check" mechanism for validating simulation configurations, -but this must be run manually by the user, and no straightforward method -for extension is available. - -This allows simulations to be initialized in an invalid state, which may -go unnoticed until runtime, producing less than informative errors from -the modeling program. +FloPy 3 has a "check" mechanism for validating simulation configurations, but this must be run manually by the user, and no straightforward method for extension is available. +This allows simulations to be initialized in an invalid state, which may go unnoticed until runtime, producing less than informative errors from the modeling program. +The most obvious example is that grid dimensions can be changed with no warning to the user, and no attempt to coerce package array data to the new shape. +We would like automatic enforcement of invariants whenever a simulation changes. -The most obvious example is that grid dimensions can be changed with no warning to the user, and no attempt to coerce package array data to the -new shape. +### Maintainability -We would like automatic enforcement of invariants whenever a simulation -changes. +flopy4 should maintain a separation of concerns with respect to hydrology and software engineering. +The hydrologic modeler should not be concerned with the technical details of flopy4's internal data storage or parallel processing implementation, +for example, and a software engineer should be able to work on the code without detailed knowledge on complex hydrologic concepts. ## Goals -With the above in mind, we want the next version of FloPy to +With the above in mind, we want the next version of FloPy to: - preserve existing `flopy.mf6` functionality -- be consistent, user-friendly and Pythonic +- be consistent, user-friendly and pythonic - be easy to read, debug, diagnose and test - be memory-efficient and provide fast IO - impose a minimal maintenance burden @@ -159,7 +147,8 @@ With the above in mind, we want the next version of FloPy to ### System requirements -flopy4 must be able to run within a python environment supporting versions that comply with scientific-python.org guidelines: . This is due to its dependency on the Numpy, Matplotlib, and XArray libraries, and flopy4 should not be conflicting with user installed libraries. +flopy4 must be able to run within a python environment supporting versions that comply with scientific-python.org guidelines: . +This is due to its dependency on the Numpy, Matplotlib, and XArray libraries, and flopy4 should not be conflicting with user installed libraries. The product must be able to run on the following operating systems: Windows, Linux, MacOS. @@ -214,9 +203,3 @@ Clear and informative error messages should be provided to the user when an erro The user documentation makes a clear distinction in user public and internal API. The user documentation provides a complete overview of the definition file specification. - -### Maintainability - -flopy4 should maintain a separation of concerns with respect to hydrology and -software engineering. The hydrologic modeler should not be concerned with the -technical details of flopy4's internal data storage or parallel processing implementation, for example, and a software engineer should be able to work on the code without detailed knowledge on complex hydrologic concepts. From 8e5d501da84cedf14d6f124f2b87ad027ec18655 Mon Sep 17 00:00:00 2001 From: Marnix Date: Wed, 6 Nov 2024 14:39:56 +0100 Subject: [PATCH 08/12] Update TOC --- docs/dev/srs.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/dev/srs.md b/docs/dev/srs.md index 3f2b9980..d48c759f 100644 --- a/docs/dev/srs.md +++ b/docs/dev/srs.md @@ -16,13 +16,13 @@ - [Introspection](#introspection) - [Performance](#performance) - [Invariants](#invariants) + - [Maintainability](#maintainability) + - [Goals](#goals) - [System requirements and functional requirements](#system-requirements-and-functional-requirements) - [System requirements](#system-requirements) - [Functional requirements](#functional-requirements) - [External interface requirements](#external-interface-requirements) - - [Non-functional requirements (NRFs)](#non-functional-requirements-nfrs) - - [Maintainability](#maintainability) - - [Goals](#goals) + - [Non-functional requirements (NFRs)](#non-functional-requirements-nfrs) From 0f37213c8d8d0f3a5ed2437e8dd95acf08e044e7 Mon Sep 17 00:00:00 2001 From: Marnix Date: Wed, 6 Nov 2024 17:03:51 +0100 Subject: [PATCH 09/12] Put requirements in table format --- docs/dev/srs.md | 94 +++++++++++++++++++++---------------------------- 1 file changed, 41 insertions(+), 53 deletions(-) diff --git a/docs/dev/srs.md b/docs/dev/srs.md index d48c759f..a239815a 100644 --- a/docs/dev/srs.md +++ b/docs/dev/srs.md @@ -19,10 +19,10 @@ - [Maintainability](#maintainability) - [Goals](#goals) - [System requirements and functional requirements](#system-requirements-and-functional-requirements) - - [System requirements](#system-requirements) - [Functional requirements](#functional-requirements) - [External interface requirements](#external-interface-requirements) - - [Non-functional requirements (NFRs)](#non-functional-requirements-nfrs) + - [Non-functional requirements](#non-functional-requirements) + - [System requirements](#system-requirements) @@ -145,61 +145,49 @@ With the above in mind, we want the next version of FloPy to: ## System requirements and functional requirements -### System requirements - -flopy4 must be able to run within a python environment supporting versions that comply with scientific-python.org guidelines: . -This is due to its dependency on the Numpy, Matplotlib, and XArray libraries, and flopy4 should not be conflicting with user installed libraries. - -The product must be able to run on the following operating systems: Windows, Linux, MacOS. - -The product must be distributed via the Python Package Index (PyPI) and be installable via pip. Additionally, the product must be installable via conda-forge. - ### Functional requirements -flopy4 must be able to read and write MODFLOW 6 input files and read MODFLOW 6 output files. - -flopy4 must be able to run MODFLOW 6 simulations. - -flopy4 must work with multiple versions of MODFLOW 6, based on the DFN files. And it must support all packages that come with that version of MODFLOW 6. - -The product lets the user define a model domain, including grid dimensions, cell sizes, and boundary conditions. - -flopy4 can create grid definitions in different formats: structured (DIS), vertex (DISV), unstructured (DISU). And is open for expansion of new grid definitions. - -flopy4 can create MODFLOW models that support parallel processing. It can pre-process models by splitting them up, ready for parallel computation. - -The product contains functions to plot model output and gives the user configurable or extendable options for customization. - -The product can export its internal data model to different types of file formats, such as NetCDF, VTK, and geospatial standards. - -Extensive validation on the final input model can be used to ensure that the model is correct before running the simulation. The validation can be extended by the user to include custom checks. - -Instantiation of packages and models should work in an intuitive way, the user should not be stuck with specific orders of function calls. E.g., packages can be created without creating a simulation or model first. +| ID | Description | MoSCoW | +| ------ | ----------- | ------ | +| FUNC-1 | flopy4 must be able to read and write MODFLOW 6 input files and read MODFLOW 6 output files. | M | +| FUNC-2 | flopy4 must be able to run MODFLOW 6 simulations. | M | +| FUNC-3 | flopy4 must work with multiple versions of MODFLOW 6, based on the DFN files. And it must support all packages that come with that version of MODFLOW 6. | M | +| FUNC-4 | The product lets the user define a model domain, including grid dimensions, cell sizes, and boundary conditions. | M | +| FUNC-5 | flopy4 can create grid definitions in different formats: structured (DIS), vertex (DISV), unstructured (DISU). And is open for expansion of new grid definitions. | M | +| FUNC-6 | flopy4 can create MODFLOW models that support parallel processing. It can pre-process models by splitting them up, ready for parallel computation. | M | +| FUNC-7 | The product contains functions to plot model output and gives the user configurable or extendable options for customization. | M | +| FUNC-8 | The product can export its internal data model to different types of file formats, such as NetCDF, VTK, and geospatial standards. | M | +| FUNC-9 | Extensive validation on the final input model can be used to ensure that the model is correct before running the simulation. | S | +| FUNC-10| The validation can be extended by the user to include custom checks. | C | +| FUNC-11| Instantiation of packages and models should work in an intuitive way, the user should not be stuck with specific orders of function calls. E.g., packages can be created without creating a simulation or model first. | M | +| FUNC-12 | Functionality is in place to set up example simulation with predefined setup combinations of models and packages already configured. | C | ## External interface requirements -flopy4 should give the opportunity for external libraries to extend its capabilities by providing a plugin system. This can be useful for new plotting mechanisms, file export formats, or custom input file formats that can be converted to MODFLOW data. - -New DFN files should be compatible with flopy4, and the product should be able to generate a definition of the packages that are applicable to that version of MODFLOW 6. - -The product strives for a consistency in its public API between MODFLOW6 and older MODFLOW packages. - -The product has programmatic access to example models, to make it quick for the user to run an example model, or to alter the examples to their liking. - -Input parameters have clear units to avoid confusion. E.g., using SI units only, or by providing usage of a python units package. - -The product has a unified understanding of date and time. +| ID | Description | MoSCoW | +| ------ | ----------- | ------ | +| API-1 | flopy4 should give the opportunity for external libraries to extend its capabilities by providing a plugin system. This can be useful for new plotting mechanisms, file export formats, or custom input file formats that can be converted to MODFLOW data. | C | +| API-2 | New DFN files are compatible with flopy4, and the product should be able to generate a definition of the packages that are applicable to that version of MODFLOW 6. | M | +| API-3 | The product strives for a consistency in its public API between MODFLOW6 and older MODFLOW packages. | S | +| API-4 | The product has programmatic access to example models, to make it quick for the user to run an example model, or to alter the examples to their liking. | C | +| API-5 | Input parameters have clear units to avoid confusion. E.g., using SI units only, or by providing usage of a python units package. | M | +| API-6 | The product has a unified understanding of date and time. | M | +| API-7 | The user is aided in their development process by providing python type hints directly from the API with accompanying documentation on all the input parameters. | M | + +## Non-functional requirements + +| ID | Description | MoSCoW | +| ------ | ----------- | ------ | +| NFR-1 | The product must be able to create large models that are larger than the available memory on the user's machine. | M | +| NFR-2 | The product should be able to create an example model of the United States with a **?1 km?** grid resolution. | ? | +| NFR-3 | Clear and informative error messages should be provided to the user when an error occurs, also during model input validation. | M | +| NFR-4 | The user documentation makes a clear distinction in user public and internal API. | M | +| NFR-5 | The user documentation provides a complete overview of the definition file specification. | M | -The user is aided in their development process by providing python type hints directly from the API with accompanying documentation on all the input parameters. - -## Non-functional requirements (NFRs) - -The product must be able to create large models that are larger than the available memory on the user's machine. - -The product should be able to create an example model of the United States with a **?1 km?** grid resolution. - -Clear and informative error messages should be provided to the user when an error occurs, also during model input validation. - -The user documentation makes a clear distinction in user public and internal API. +### System requirements -The user documentation provides a complete overview of the definition file specification. +| ID | Description | MoSCoW | +| ------ | ----------- | ------ | +| SYS-1 | flopy4 must be able to run within a python environment supporting versions that comply with scientific-python.org guidelines: . This is due to its dependency on the Numpy, Matplotlib, and XArray libraries, and flopy4 should not be conflicting with user installed libraries. | M | +| SYS-2 | The product must be able to run on the following operating systems: Windows, Linux, MacOS. | M | +| SYS-3 | The product must be distributed via the Python Package Index (PyPI) and be installable via pip. Additionally, the product must be installable via conda-forge. | M | From 44a2627139ac8ba383c2f8e4cd9126bbc11f0a4c Mon Sep 17 00:00:00 2001 From: Marnix Date: Wed, 13 Nov 2024 17:45:14 +0100 Subject: [PATCH 10/12] Fix table spacing --- docs/dev/srs.md | 68 ++++++++++++++++++++++++------------------------- 1 file changed, 34 insertions(+), 34 deletions(-) diff --git a/docs/dev/srs.md b/docs/dev/srs.md index a239815a..4b1b6cf3 100644 --- a/docs/dev/srs.md +++ b/docs/dev/srs.md @@ -147,47 +147,47 @@ With the above in mind, we want the next version of FloPy to: ### Functional requirements -| ID | Description | MoSCoW | -| ------ | ----------- | ------ | -| FUNC-1 | flopy4 must be able to read and write MODFLOW 6 input files and read MODFLOW 6 output files. | M | -| FUNC-2 | flopy4 must be able to run MODFLOW 6 simulations. | M | -| FUNC-3 | flopy4 must work with multiple versions of MODFLOW 6, based on the DFN files. And it must support all packages that come with that version of MODFLOW 6. | M | -| FUNC-4 | The product lets the user define a model domain, including grid dimensions, cell sizes, and boundary conditions. | M | -| FUNC-5 | flopy4 can create grid definitions in different formats: structured (DIS), vertex (DISV), unstructured (DISU). And is open for expansion of new grid definitions. | M | -| FUNC-6 | flopy4 can create MODFLOW models that support parallel processing. It can pre-process models by splitting them up, ready for parallel computation. | M | -| FUNC-7 | The product contains functions to plot model output and gives the user configurable or extendable options for customization. | M | -| FUNC-8 | The product can export its internal data model to different types of file formats, such as NetCDF, VTK, and geospatial standards. | M | -| FUNC-9 | Extensive validation on the final input model can be used to ensure that the model is correct before running the simulation. | S | -| FUNC-10| The validation can be extended by the user to include custom checks. | C | -| FUNC-11| Instantiation of packages and models should work in an intuitive way, the user should not be stuck with specific orders of function calls. E.g., packages can be created without creating a simulation or model first. | M | +| ID | Description | MoSCoW | +| ------- | ----------- | ------ | +| FUNC-1 | flopy4 must be able to read and write MODFLOW 6 input files and read MODFLOW 6 output files. | M | +| FUNC-2 | flopy4 must be able to run MODFLOW 6 simulations. | M | +| FUNC-3 | flopy4 must work with multiple versions of MODFLOW 6, based on the DFN files. And it must support all packages that come with that version of MODFLOW 6. | M | +| FUNC-4 | The product lets the user define a model domain, including grid dimensions, cell sizes, and boundary conditions. | M | +| FUNC-5 | flopy4 can create grid definitions in different formats: structured (DIS), vertex (DISV), unstructured (DISU). And is open for expansion of new grid definitions. | M | +| FUNC-6 | flopy4 can create MODFLOW models that support parallel processing. It can pre-process models by splitting them up, ready for parallel computation. | M | +| FUNC-7 | The product contains functions to plot model output and gives the user configurable or extendable options for customization. | M | +| FUNC-8 | The product can export its internal data model to different types of file formats, such as NetCDF, VTK, and geospatial standards. | M | +| FUNC-9 | Extensive validation on the final input model can be used to ensure that the model is correct before running the simulation. | S | +| FUNC-10 | The validation can be extended by the user to include custom checks. | C | +| FUNC-11 | Instantiation of packages and models should work in an intuitive way, the user should not be stuck with specific orders of function calls. E.g., packages can be created without creating a simulation or model first. | M | | FUNC-12 | Functionality is in place to set up example simulation with predefined setup combinations of models and packages already configured. | C | ## External interface requirements -| ID | Description | MoSCoW | -| ------ | ----------- | ------ | -| API-1 | flopy4 should give the opportunity for external libraries to extend its capabilities by providing a plugin system. This can be useful for new plotting mechanisms, file export formats, or custom input file formats that can be converted to MODFLOW data. | C | -| API-2 | New DFN files are compatible with flopy4, and the product should be able to generate a definition of the packages that are applicable to that version of MODFLOW 6. | M | -| API-3 | The product strives for a consistency in its public API between MODFLOW6 and older MODFLOW packages. | S | -| API-4 | The product has programmatic access to example models, to make it quick for the user to run an example model, or to alter the examples to their liking. | C | -| API-5 | Input parameters have clear units to avoid confusion. E.g., using SI units only, or by providing usage of a python units package. | M | -| API-6 | The product has a unified understanding of date and time. | M | -| API-7 | The user is aided in their development process by providing python type hints directly from the API with accompanying documentation on all the input parameters. | M | +| ID | Description | MoSCoW | +| ------- | ----------- | ------ | +| API-1 | flopy4 should give the opportunity for external libraries to extend its capabilities by providing a plugin system. This can be useful for new plotting mechanisms, file export formats, or custom input file formats that can be converted to MODFLOW data. | C | +| API-2 | New DFN files are compatible with flopy4, and the product should be able to generate a definition of the packages that are applicable to that version of MODFLOW 6. | M | +| API-3 | The product strives for a consistency in its public API between MODFLOW6 and older MODFLOW packages. | S | +| API-4 | The product has programmatic access to example models, to make it quick for the user to run an example model, or to alter the examples to their liking. | C | +| API-5 | Input parameters have clear units to avoid confusion. E.g., using SI units only, or by providing usage of a python units package. | M | +| API-6 | The product has a unified understanding of date and time. | M | +| API-7 | The user is aided in their development process by providing python type hints directly from the API with accompanying documentation on all the input parameters. | M | ## Non-functional requirements -| ID | Description | MoSCoW | -| ------ | ----------- | ------ | -| NFR-1 | The product must be able to create large models that are larger than the available memory on the user's machine. | M | -| NFR-2 | The product should be able to create an example model of the United States with a **?1 km?** grid resolution. | ? | -| NFR-3 | Clear and informative error messages should be provided to the user when an error occurs, also during model input validation. | M | -| NFR-4 | The user documentation makes a clear distinction in user public and internal API. | M | -| NFR-5 | The user documentation provides a complete overview of the definition file specification. | M | +| ID | Description | MoSCoW | +| ------- | ----------- | ------ | +| NFR-1 | The product must be able to create large models that are larger than the available memory on the user's machine. | M | +| NFR-2 | The product should be able to create an example model of the United States with a **?1 km?** grid resolution. | ? | +| NFR-3 | Clear and informative error messages should be provided to the user when an error occurs, also during model input validation. | M | +| NFR-4 | The user documentation makes a clear distinction in user public and internal API. | M | +| NFR-5 | The user documentation provides a complete overview of the definition file specification. | M | ### System requirements -| ID | Description | MoSCoW | -| ------ | ----------- | ------ | -| SYS-1 | flopy4 must be able to run within a python environment supporting versions that comply with scientific-python.org guidelines: . This is due to its dependency on the Numpy, Matplotlib, and XArray libraries, and flopy4 should not be conflicting with user installed libraries. | M | -| SYS-2 | The product must be able to run on the following operating systems: Windows, Linux, MacOS. | M | -| SYS-3 | The product must be distributed via the Python Package Index (PyPI) and be installable via pip. Additionally, the product must be installable via conda-forge. | M | +| ID | Description | MoSCoW | +| ------- | ----------- | ------ | +| SYS-1 | flopy4 must be able to run within a python environment supporting versions that comply with scientific-python.org guidelines: . This is due to its dependency on the Numpy, Matplotlib, and XArray libraries, and flopy4 should not be conflicting with user installed libraries. | M | +| SYS-2 | The product must be able to run on the following operating systems: Windows, Linux, MacOS. | M | +| SYS-3 | The product must be distributed via the Python Package Index (PyPI) and be installable via pip. Additionally, the product must be installable via conda-forge. | M | From cfb626e16f6bd3b65a514acc20f5b242268b8d9e Mon Sep 17 00:00:00 2001 From: Marnix Date: Fri, 15 Nov 2024 08:29:12 +0100 Subject: [PATCH 11/12] Addressed review comments by Chris --- docs/dev/srs.md | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/docs/dev/srs.md b/docs/dev/srs.md index 4b1b6cf3..1e49cd1d 100644 --- a/docs/dev/srs.md +++ b/docs/dev/srs.md @@ -145,22 +145,28 @@ With the above in mind, we want the next version of FloPy to: ## System requirements and functional requirements +The requirements below are written up through interviews with stakeholders and internal research of the flopy code base. + +The requirements are categorized through the [MoSCoW method](https://en.wikipedia.org/wiki/MoSCoW_method), prioritizing which requirements Must, Should, Could, and Won't go into the first iteration of the flopy 4 project. + ### Functional requirements | ID | Description | MoSCoW | | ------- | ----------- | ------ | | FUNC-1 | flopy4 must be able to read and write MODFLOW 6 input files and read MODFLOW 6 output files. | M | -| FUNC-2 | flopy4 must be able to run MODFLOW 6 simulations. | M | +| FUNC-2 | flopy4 must be able to run MODFLOW 6 simulations and report back on the run status. | M | | FUNC-3 | flopy4 must work with multiple versions of MODFLOW 6, based on the DFN files. And it must support all packages that come with that version of MODFLOW 6. | M | | FUNC-4 | The product lets the user define a model domain, including grid dimensions, cell sizes, and boundary conditions. | M | | FUNC-5 | flopy4 can create grid definitions in different formats: structured (DIS), vertex (DISV), unstructured (DISU). And is open for expansion of new grid definitions. | M | | FUNC-6 | flopy4 can create MODFLOW models that support parallel processing. It can pre-process models by splitting them up, ready for parallel computation. | M | | FUNC-7 | The product contains functions to plot model output and gives the user configurable or extendable options for customization. | M | -| FUNC-8 | The product can export its internal data model to different types of file formats, such as NetCDF, VTK, and geospatial standards. | M | -| FUNC-9 | Extensive validation on the final input model can be used to ensure that the model is correct before running the simulation. | S | -| FUNC-10 | The validation can be extended by the user to include custom checks. | C | -| FUNC-11 | Instantiation of packages and models should work in an intuitive way, the user should not be stuck with specific orders of function calls. E.g., packages can be created without creating a simulation or model first. | M | -| FUNC-12 | Functionality is in place to set up example simulation with predefined setup combinations of models and packages already configured. | C | +| FUNC-8 | The product contains functions to plot model input and gives the user configurable or extendable options for customization. | M | +| FUNC-9 | The product can export its internal data model to different types of file formats, such as NetCDF, VTK, and geospatial standards. | M | +| FUNC-10 | Extensive and optional validation on the final input model can be used to ensure that the model is free from detectable errors and to warn the user of potential errors before running the simulation. | S | +| FUNC-11 | The validation can be extended by the user to include custom checks. | C | +| FUNC-12 | Instantiation of packages and models should work in an intuitive way that does not depend on the specific order of function calls. E.g., packages can be created without creating a simulation or model first. | M | +| FUNC-13 | Functionality is in place to set up example simulations with predefined setup combinations of models and packages already configured. | C | +| FUNC-14 | Flopy is a non-intrusive package when it comes to reading and writing the model. When writing out a model that was read, Flopy does not add any additional information. | C | ## External interface requirements @@ -168,9 +174,9 @@ With the above in mind, we want the next version of FloPy to: | ------- | ----------- | ------ | | API-1 | flopy4 should give the opportunity for external libraries to extend its capabilities by providing a plugin system. This can be useful for new plotting mechanisms, file export formats, or custom input file formats that can be converted to MODFLOW data. | C | | API-2 | New DFN files are compatible with flopy4, and the product should be able to generate a definition of the packages that are applicable to that version of MODFLOW 6. | M | -| API-3 | The product strives for a consistency in its public API between MODFLOW6 and older MODFLOW packages. | S | +| API-3 | The product strives for a consistency in its public API between MODFLOW 6 and older MODFLOW packages. | S | | API-4 | The product has programmatic access to example models, to make it quick for the user to run an example model, or to alter the examples to their liking. | C | -| API-5 | Input parameters have clear units to avoid confusion. E.g., using SI units only, or by providing usage of a python units package. | M | +| API-5 | Input parameters have clear units to avoid confusion. E.g., using SI units only, or by providing usage of a python units package. | C | | API-6 | The product has a unified understanding of date and time. | M | | API-7 | The user is aided in their development process by providing python type hints directly from the API with accompanying documentation on all the input parameters. | M | From df9ee3c2a47b52f07f1f3347d6ca560da7460b63 Mon Sep 17 00:00:00 2001 From: Marnix Date: Fri, 15 Nov 2024 15:21:44 +0100 Subject: [PATCH 12/12] Fix final requirement mentioned by Chris --- docs/dev/srs.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/dev/srs.md b/docs/dev/srs.md index 1e49cd1d..9b10e176 100644 --- a/docs/dev/srs.md +++ b/docs/dev/srs.md @@ -20,8 +20,8 @@ - [Goals](#goals) - [System requirements and functional requirements](#system-requirements-and-functional-requirements) - [Functional requirements](#functional-requirements) - - [External interface requirements](#external-interface-requirements) - - [Non-functional requirements](#non-functional-requirements) + - [External interface requirements](#external-interface-requirements) + - [Non-functional requirements](#non-functional-requirements) - [System requirements](#system-requirements) @@ -166,9 +166,9 @@ The requirements are categorized through the [MoSCoW method](https://en.wikipedi | FUNC-11 | The validation can be extended by the user to include custom checks. | C | | FUNC-12 | Instantiation of packages and models should work in an intuitive way that does not depend on the specific order of function calls. E.g., packages can be created without creating a simulation or model first. | M | | FUNC-13 | Functionality is in place to set up example simulations with predefined setup combinations of models and packages already configured. | C | -| FUNC-14 | Flopy is a non-intrusive package when it comes to reading and writing the model. When writing out a model that was read, Flopy does not add any additional information. | C | +| FUNC-14 | Flopy is a non-intrusive package when it comes to reading, writing, and running the model. When writing out a model that was read, the simulation output must give the exact same results. | C | -## External interface requirements +### External interface requirements | ID | Description | MoSCoW | | ------- | ----------- | ------ | @@ -180,7 +180,7 @@ The requirements are categorized through the [MoSCoW method](https://en.wikipedi | API-6 | The product has a unified understanding of date and time. | M | | API-7 | The user is aided in their development process by providing python type hints directly from the API with accompanying documentation on all the input parameters. | M | -## Non-functional requirements +### Non-functional requirements | ID | Description | MoSCoW | | ------- | ----------- | ------ |