[ASPICE] [SWE.1]: A day as a Requirements Engineer

Quite a long day, ha!!
Let's get to it

First, check these presentations:

Let’s talk “PROCESS” here

Starting by having new requirements from the system team

Then we refer to each Base Practice in ASPICE SWE.1 to understand it deeper

You have got new System requirements!

The following points shall be clearly defined, agreed and communicated with the system team:

-> All of this shall be mentioned in Requirements Management Plan Documents after being discussed and agreed with the System Team.

Inputs documents acceptance shall be based on:

Reviewing all requirements in scope of delivery and relevance to previous deliveries.
Opening questions to confirm requirements understanding.
Opening review points to show missing data, data conflict, infeasibility of the requirement.

-> Note that this shall be reviewed within the Technical Assessments of the SRS

Everything shall be clear in the System Requirements.
Better to have text with charts for explaining, but not only charts, they can be misleading sometimes.
Each review point shall refer to the requirements/feature.
Track points open date and critically to escalate when necessary.
Meeting minutes shall be tracked and reflected in the requirements when needed.

Drafts.. Drafts.. then Release:

To ensure a mature version of the SRS for the release, this can be done:
Having drafts of the document with the required requirements
Having it reviewed by the document consumers (Archi, Testing, Dev..)
Fixing the review points and answering and open questions
Opening relevant review points or questions for the System team based on the new discussions
Updating and releasing the SRS

Providing Verification Criteria doesn’t only ensure the guiding of testing team to test specific scenarios for complex requirements but also it helps them understand the requirements better.
No need to provide Verification Criteria for simple or straight forwards requirements.
However, each requirement shall be assigned to be Sw_Test or Integration_Test.
Integration_Test requirements shall be as minimum as possible and justified if exceeded the agreed limit according to the project scope.

Inter-communication is the KEY

Requirement engineer shall initiate workshops to illustrate the new feature/requirements/modes.. etc
Yes, the document shall be enough to explain what he wants to show.. But even though, communication is the key.
Reviewer shall add their issues or questions:

In specific sheets
In specific attributes, if the requirement management tool supports that such as DOORs.

All questions, review points need to be tracked by open time and solving time and shall be closed before freezing the requirements.

Partial or Fully?

The need of traceability to show the percentage of coverage of the upstream.
Having it bidirectional can show the derived requirements and why would SRS have no links to upstream requirements.
Derived requirements shall be justified.
Traceability shall be always tracked against current release scope and the total number of input requirements.
Any deviation shall be justified. Ex: rejected requirements that the system team still refused to update or clarify.
Traceability filters/attributes shall be agreed and documented.