Requirements

User stories

• Write down user stories to devise the main personas (user roles) and the activities they will perform via the system to be developed.

Requirements analysis

• The requirements must explain what (not how) the software being produced should do.
  • You should not focus on the particular problems, but exclusively on what you want the application to do.
• Requirements must be clearly identified, and possibly numbered.
• Requirements are divided into:
  • Functional: some functionality the software should provide to the user.
  • Non-functional: requirements that do not directly concern behavioral aspects, such as consistency, availability, security, efficiency, etc.
  • Implementation: constrain the entire phase of system realization, for instance by requiring the use of a specific programming language and/or a specific software dependency.
    • These constraints should be adequately justified by political / economic / administrative reasons (which must be written down)…
    • …otherwise, implementation choices should emerge as a consequence of design (and therefore described in the design section).
• If there are domain-specific terms, these should be explained in a glossary.
• Each requirement must have its own acceptance criteria.
  • These will be important for the validation phase.

You may consider adding a use-case diagram here (via PlantUML) to better visualize the requirements and their relationships