Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Target release

Epic

Document status

DRAFT

Document owner

Rik Smale

Designer

Network AEGEE-Europe

Tech lead

Technical writers

Rik Smale

QA

Objective

In part 1 of the Network Module, the network history should be visible. In part 2, the network status update should be integrated in MyAEGEE and most data for the antenna criteria can be stored in the system.

Stakeholders

  • Network Director (ND) - Parts 1 & 2

  • Financial Director (FD) - Part 2

  • Network Commissioners (NetCom) - Parts 1 & 2

  • Board member of a local - Part 1

Requirements - Part 1

User Story

Jira Issue

Notes

1

As ND I would like to see what the history of the status of a local is. (Contact/Contact Antenna/Antenna, including downgrades, deletions and refoundings)

The dates of these events should also be tracked. See section ‘User interaction and design’ for the possible state changes.

2

 As board member/ND I would like to be able to keep track of multiple founding dates.

 

Internal founding date, CD approved date, CdA signed date 

3

As ND I would like to upgrade/downgrade locals on the body page.

ND should confirm this change, so it will not happen accidentally.

4

When a contact upgrades to contact antenna, the name of the contact should be updated.

If the description was auto-generated, this should also update to reflect the new name.

5

As ND I would like to be able to give an explanation to why a local got downgraded or deleted.

Just a description box in the pop up.

6

As ND/NetCom I would like to be able to see a list of past locals which do not exist anymore.

7

As ND I would like to be able to change the status of a local from the bodies list.

For ND a button should be in the table which will give a pop up in which the ND can click on the wanted change. This can be the same pop up as on the body page. This button should only show up for locals

Requirements - Part 2

User Story

Jira Issue

Notes

1

As ND/NetCom I would like to track the fulfilment of the Antenna Criteria for every Agora.

See section ‘User interaction and design’ for a mockup.

2

As ND I would like to be able to export the fulfilment of the Antenna Criteria.

3

As ND I would like to be able to change the status of the Network Status update from draft to final.

 

 

4

When a Network Status update is final, it can not be updated anymore.

5

As ND I would like to include the unfulfilled Antenna Criteria to a downgrade or deletion.

6

As FD I would like to track the payments of every local.

7

As board member/NetCom/ND I would like to be able to update the board of a local.

8

As board member/NetCom/ND I would like to be able to upload the Development Plan of a local.

User interaction and design

Possible status changes of a local

Mockup Antenna Criteria fulfilment

Open Questions

Question

Answer

Date Answered

How would we deal with CIA changes in the Antenna Criteriae?

Out of Scope

  • In Parts 1 & 2, the information is not really data-driven. This will be included in Part 3.

    • With data-driven it is meant that the Antenna Criteria fulfilment will be updated automatically based on the information that the system has in different places.

  • In Parts 1 & 2, the information that a Network Commissioner can see is not specific for that Commissioner. This will be included in Part 4.

    • Part 4 will also see the inclusion of a Network Area selector on the body page.

  • In Part 2, the board member can not see the fulfilment of the Antenna Criteria. This will be included in either Part 3 or Part 4.

  • In Part 2, the Antenna Status update can not be sent from MyAEGEE directly. This will be included in Part 4.

Resources

  • An less structured overview of the Network Module can be found here: Network module

Other remarks

  • The Antenna Criteria fulfilment and the Network Status update are two different terms that can be used interchangeably.

  • Normally Parts 1 & 2 would be kept in separate documents, or combined into one document. But since I didn’t want to overflow the ‘Out of Scope’ section and Parts 1 & 2 were designed simultaneously but still have a different prioritization they are divided in two parts.

  • No labels