...
In part 1 of the Network Module, the network history should be visible and the basic framework for tracking the Antenna Criteria is in place. Board elections are also possible.
In part 2 , the network status update should be integrated in MyAEGEE and most data for the antenna criteria can be stored in the systemthe rest of the planned features for tracking the Antenna Criteria and finalizing the Network Status Update are implemented and the body history is linked. A better overview of the membership fees is also implemented here.
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
Financial Director (FD) - Part 2
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 |
...
Possible status changes of a local
...
Mockup Antenna Criteria fulfilment
...
Something that will be added here, but not shown in the mockup is that after the fulfilment (so all Yes/No’s) there will be a + button which will allow you to write comments (and maybe show more information in the future). If there is a comment added, the + button will be an !.
Open Questions
Question | Answer | Date Answered | Remarks |
|---|---|---|---|
How would we deal with CIA changes in the Antenna Criteriae? | This is something for the developers to think about. |
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 In Parts 1 & 2, there are no mailing features. Mailing boards that have not fulfilled all ACs will be added in either Part 3 or Part 4.
Emailing boards will be done by clicking the envelope in the column that’s also used for editing/deleting. It will auto-generate an email with the current state of the fulfilment and allows the ND/NetCom to add something at the start of the body of the email (as like an introduction)
Resources
A less structured overview of the Network Module can be found here: Network module
...
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 into two parts.