# WG1

WG1 will work mainly in WP2. The tasks that WG1 will support are:

- [x] 2.3 - Define general process for requirements specification (for all kinds of requirements). S: 2022-06-02 E: 2022-07-20
- [ ] 2.4 - Define general process for test creation and rules definition. S: 2022-07-20 E: 2022-07-30
- [ ] 2.5 - Define general processes to check the results of software implementation. S: 2022-07-20 E:2022-07-30
- [ ] 2.6 - Provide input to Implementers Forum regarding communication and consensus finding. S: 2022-07-30 E: 2022-08-30

## Notes

### Meeting 2022.08.02 - Overview on SW certification, IDS, bSDD, etc.
<details open><summary>details</summary>

**Objective**: Answer some questions on bSI strategy/progress regarding: SW certification, IDS, bSDD, etc. To see how RWR project can align with these. Success: we all have the same understanding on what the project can do for bSI and viceversa.

**Questions**:

1. What is available right now form bSI, in terms of technologgies, to capture requirements and validate them?
2. What are the method and technologies that will be used for SW certification?

**Answers/Agreements**:

- Do not create an MVD (the 3 available (RV, AbRV, DTV) are the only ones)
- Rather contribute to further define the AbRV. By adding additional rules/documentation to base MVD using Gherking.
- Example: write rules for miniumum level agreements among SV on Spatial Structure.
- IDS/bSDD can be used to formalise and check some requirements (via Validation Service or IDS checking tools).
- Example: spatial structure setups from different stakeholders
- When IDS / bSDD are not enough to capture requirements, use Gherkin (it's the same technology used by the Validation Services)
- Some terms need explicit definitions for us to understand each others:
- Use Case (railway): "IT" Use Case. As a user I am able to ...
- Use Case (of the UCM tool) = what rail calls Business Case. A level higher than the "IT" Use Case
- Functional part = one level deeper than the "IT" Use Case. Ralated to IFC concepts
- The **traceability** requirement is key, to keep everything linked: Business Case > "IT" Use Case > Contractual requirement > Functional parts > Test Case
- The *RFI fast track* will help us put examples next to these definitions, and explain the others the methodology - so that they can replicate

</details>

### Meeting 2022.07.18 - Template review (Andreas, Chi, Etienne, Evandro, Vincent)
<details><summary>details</summary>

**WHAT**
Instructions for railway experts on how to describe their need...
**WHY**
...to a level that is good enough for:
- <u>Technical Support team</u> shall be able to:
- understand it
- derive requirements and work on them (sort, check duplicate, split, assess complexity, identify IFC concepts)
- test and validate the request
- <u>Software development team</u> shall be able to:
- understand the added value of the request
- decide if and what resources to allocate
- implement a solution to address the need

**HOW**
This is the main deliverable of WG1. Some pricniples are captured in previous meeting's note. Today another one is added: **Traceability of requirement to the use case, and up to the business case**

*Decisions*

- Use Case is a bad term. Railway experts and IT has different interpretation of it.
- Let's stick with this term for the project, too late to change now
- When we talk we differentiate between Business Case (something where the "value" component is key); and "Software" Use Case, which is something more precise and granualar than the "Project" Use Case defined by Stakeholders
- Let's keep the "Use" Case proposal template as an evolving document where we capture lessons learnt and instructions to be released later on

- Take 1 "Project" Use Case (UC-A, IFC model federation) and **use it to build+test the methodology**
- let's do a quick round with authors of the UC-A
- The TS team shall be able to: sort, check duplicate, split, assess complexity, identify IFC concepts

- Actions
- Chi to communicate with Guy about decision to start testing the approach with authors of UC-A
- Questions for meeting with UC-A authors:
- Can you draw a basic process map?
- Can you make an example?
- What do you want to do when, for example, two models are federated? (goal: enhance use case description)
- Other input:
- There is a storyline (SL_10) that covers this. Ccan you read it and see if that is what you need for model federation?
- Feedback from SV: some of SV understood the importance of common rules of ss to federate models. However, ther's different maturity on SS, by SV.

- Critical success factor for the porject: setting up proper communication
- what to focus on
- making sure everyobody has a basic understanding

</details>

### Meeting 2022.07.12 - Brainstorm (Andreas, Chi, Etienne, Evandro)

<details><summary>details</summary>

- Communication shall happen on two levels:
1) Use Case
2) Requirements specification (Functional blocks, Functional categories)
- (1) help stakeholders and vendors understand the bigger picture, (2) shall enable modular (possibly automated) test & validation
- Provide to railway experts (by 20th July):
- **Very simple** Use Case template
- Instructions and principles to fill in templates
- Examples
- ! Provide TS with a template/methodology to manage requirements derived from use cases (by 30th July)
- Some **principles** for UC template:
- Use plain language description
- Explicit data input and data output
- Add a simple diagram (simple!)
- A list of previously fulfilled Use Case is useful
- Avoid any specific tool at the beginning of this process. Text and sketches are perfect!

- The description of the requirements shall allow Technical Support team (and SV) to:
- understand, asses, and (if needed) split the requirements to identify IFC functional blocks (bricks, categories, ... chose your name). **These are the same used for IFC file validation by bSI**.
- make a complexity analysis
- identify duplicates
- distinguish the kinds of requirement (e.g., functional, non functional, ifc file content, SW feature)
</details>

## August meeting

<details open><summary>details</summary>

WG1 Paris workshop
Date: Tuesday, August 23rd, 12:30 to Wednesday Aug 24th, 17:00.
Venue: FNTP 9 rue de Berri, 75008 PARIS

Prerequisites
Before joining the meeting be sure to:
- Read the detailed project plan (not subject to discussion)
- Read the WP2 Instructions document
- Read only methodology for STEP 1 (From business process to use diagram to user stories)
- STEP 2 and 3 are objetive of Paris workshop
- Be aware of bSI strategy for MVD, IDS, bSDD, validation, etc. (Léon slides + recording?)

AGENDA

Day 1 (23rd)
1. Review agenda
3. Methodology for STEP 2 (From user stories to single requirements)
- Differentiate "Requirements for the Appointed Party" (for IFC model tender)
- from "Software requirements" (interpretation of the above req. targeting SW dev. team and IT dept)
- how to link the two
4. Methodology for STEP 3 (From requirements to contracts and to tests)
- How to include the first type of req. into contracts
- How to identify/extract IFC functional parts (blocks) from the second type
- and how to test + validate them

Day 2 (24th)
1. Confirm project deliverables (format), for WP2 to WP6
2. Preview of business case presentation for SV in Boston (Chi)

</details>

Some topics for the meeting agenda:
- Next WP activities
- Added value of the SW development (Etienne) (Experts to state their view in UC, Forum to help)
- Principle of "automation at all cost". If we don't have the resources fine, but state that this is the envisioned goal anyway. Act with the automated test idea in mind (Andreas)