Nextens Requirements policy - NextensArelB/SwaggerGenerationTool GitHub Wiki

Nextens Requirements policy

image.png

Nextens requirement policy consists of 3 parts:

  • Business requirements analysis- high level analysis and requirements (Epic/Feature level) delivered by business analyst (for more information how the BA/DA is working, please refer to this wiki page
    • This activity is done prior to handover to tech team
  • Data requirements analysis - high level analysis and requirements (Epic/Feature level) delivered by data analyst (for more information how the BA/DA is working, please refer to this wiki page
    • This activity is done prior to handover to tech team
  • (non) Functional requirements analysis - worked out business requirements into (non) functional requirements on User Story level by the QTA in such a way that the team knows what to develop and to test, please refer to this wiki page
    • This activity is performed after handover to techteam and performed during the 3-weekly sprints where per sprint user stories are refined and described in detail

Type of requirements

Requirements can be non-functional, functional or generic: Non-functional requirements are a set of specifications that describe the system's operation capabilities and constraints, such as what are the performance criteria or requirements related to logging. A specific type of a non-functional requirement is Security

  • Security requirements are requirements which are related to ensure the authentication and access control to the application and the confidentiality, integrity, and availability of information, example is that fields with confidential content should always be masked.

Functional requirements define what a product must do and what its features and functions are, example is that a filter can be set on column/field A and B. Generic requirements can be functional and non-functional and are requirements which are applicable for (almost) all apps within Nextens, example is that date fields are always in DD-MM-YYYY format.

Level of detail

Level of detail differs per topic and experience within the tech teams. The following characteristics impact the level of detail delivered by either the BA/DA or QA:

  • Domain knowledge:
    • When Domain knowledge of QA is low, the BA/DA delivers more detail before handing over to tech team
    • When Domain knowledge of Dev is low, QA delivers more detail for the dev's to start coding
  • Experience:
    • When Experience of QA is low, the BA/DA delivers more detail before handing over to tech team
    • When Experience of Dev is low, QA delivers more detail for the dev's to start coding
  • Complexity:
    • When the complexity is high, the BA/DA delivers more detail before handing over to tech team and QA delivers more detail for the dev's to start coding
  • Comply to law, compliance or legislation:
    • When the functionality has to compy to law, compliance or legislation, the BA/DA delivers more detail before handing over to tech team and the QA delivers more detail for the dev's to start coding
  • High expected sales volume:
    • When the expected sales volume is high, the BA/DA delivers more detail before handing over to tech team and the QA delivers more detail for the dev's to start coding
  • Independent team with high agility:
    • When team has the ability to try out, being agile in delivering and adapting, the BA/DA delivers less detail before handing over to tech team and the QA delivers less detail for the dev's to start coding

The different characteristics can impact eachother, for example when domain knowlegde is high and complexity is high, the level of detail can be less as there is a high level of domain knowledge.

⚠️ **GitHub.com Fallback** ⚠️