Skip to content

Software requirements (generic)

jonathan-winn-geo edited this page Oct 17, 2022 · 1 revision

This page details the generic project software requirements for a typical python package.

Specifications are used to:

  • determine design options during development
  • help inform testing strategies.

Software purpose, summary and aims

Statements to clarify system purpose, functionality, expectations.

e.g. - The software will be used by climate scientists, on a Linux platform, with access to high memory and multi core processing capability. - The software will allow geospatial data processing and will be run frequently at intervals from weekly to monthly to produce analysis outputs. - Users will be familiar with python and Linux commands. - The system will produce outputs in scientific data format and will be configured via text based, user editable, config files.

List the software purpose and use cases as a number of distinct development aims.

(example aims)

Aim 1

  • To allow the analysis of input geospatial temperature data to calculate climatologies across different spatial extents and temporal periods

Aim 2

  • To allow analysis at a range of output spatial resolutions

Aim 3

  • The system should be fully responsive to expected future updates in input datasets

Aim 4

  • The system should be able to recognise when input data changes are incompatible and failover safely to use previously available, compatible data

Software use and user inputs

State the situation where the system will be used and how the user will interact with the system, e.g.

  • Software to be run via command line calls, via Linux
  • User editable config to define input data sources and analysis options
  • User editable config setting to be submitted by file, rather than manual terminal input
  • User settings to be captured via logging of each analysis run

Although initial requirements building documents should not list solutions as they should focus on exact requirements, once planning progresses it will be useful for python projects to consider what type of solution a typical end-user may expect. For example, will a user install and use an isolated application / package? or would they require a system that could be imported and integrated with their code, e.g. via modules, sub-packages, packages? Related to this may be any requirements of the user to be able to test and confirm behaviour of the system , e.g. after installation.

User level (intended audience)

Clarify the expected level of user experience, e.g.

  • The system is designed for an advanced / expert level user of climate data
  • The user will be an intermediate / advanced Linux user

User needs

What needs does the user have? e.g. how might these inform functional or non-functional requirements?

  • Scientist users will require science focused documentation, allowing processing code to be reviewed
  • Testers will require documentation that allows full testing and replication of analysis steps and output data
  • Scientist users will require analysis to complete in less than 6 hrs

Assumptions and dependencies

What assumptions have been made about users, systems, inputs, outputs, timescales? e.g.

  • Users will be familiar with Linux, Python
  • User will be familiar with climate science and geospatial data terminology
  • Analysis will occur on a system with internet access

Functional requirements

Detailed description of the types of functions and features the software will deliver

Outputs

Specify the form, location, content of system outputs, e.g.

  • Capture user set config and all analysis options to allow analysis to be re-run
  • All output files to be in netcdf4 format to stated, numbered CF convention format

Data sources and inputs

Clarify requirements for input data, e.g.

  • Ability to select from several different, compatible, data sources
  • Ability to swap and replace input data sources between analysis runs
  • Option to source input data as local downloads so the system can function without internet connectivity

Analysis

Detail any system analysis requirements, e.g.

  • Ability to set specific time periods for the analysis run
  • Ability to set different spatial extent for each analysis run

Non-functional requirements

Define levels of detail and expectation beyond the technical achievements of the software e.g. if the software needs to be user friendly to a certain level of user, visual aesthetics, available documentation or the presence of tutorials or accompanying jupyter notebooks. Also covers: Security and safety, Performance, Quality

Outline all other known requirements, e.g.

  • Analysis runtime, full pipeline (including input data access): should complete in <= 6 hrs
  • Main data analysis (acting on locally available, pre-formated data): <= 1 hr
  • System resources requires: <= 128 GB RAM
  • Network resources: requires internet access
  • Quality: code meets PEP8 and include docstrings to PE257
  • Tutorials: system will include walk through tutorials showing data input, analysis and output