Security. Your security considerations should include, but are not limited to the following:
Authenticity - Access to the service functionality of the API must be protected using an appropriate series of authentication and authorisation mechanisms;
Each user has their own account - which is registered → we also have sessions for each account (our idea of how we run it - group would make 1 account - each individual has sessions out of it - track who is using it - get a token instead of having to login every time) → They can make an account and make sessions of that account.
Hashed our user passwords → most common thing
Accountability - all activity on the API (calls to endpoints) should be tracked and kept in a log.
The infrastructure on which the service is deployed needs to be secure (physically and electronically, as much as possible).
Document any relevant content inside a confluence page called Security.
Performance. The API endpoints should take a minimal amount of time to complete. In most cases this will be relatively straightforward. In some, where computations are more complex, you will need to spend time designing your algorithm with pseudocode to determine the algorithmic complexity and reduce it as much as possible. Document any relevant content inside a confluence page called Performance.
As a business, I want the system to prevent other people from using it (who shouldn’t be able to access the invoices), to protect the privacy of all related parties.
Token
As a developer, I want all API calls to be logged so that I can check what has happened.
Database holding API call information
Info about: who sent API call, time, …
As a recipient, I do not want outside parties to be able to view details about my invoice.
Tokens
Possibly database encrypting?
As a business, I want the system to be able to send and operate quickly, so that I am not wasting my time waiting on sending.
Optimising sending
Functional Requirements - things it must or must not do.
Non-Functional Requirements - performance standards/quality, eg. security, scalability, usability, speed.
USER STORIES
As a business, I want to be able to send invoices, so that my invoices can reach outside of my local system.
Sending invoice to address (possibly email)
Files sent in correct format (UBL XML)
As a business, I want to know if my invoice was sent successfully so that I can make sure the invoice was sent or take further action.
Communication report with error or success
Report includes the type of error/s (eg. email address invalid, connection not etablished etc.)
Report also includes address, client, time/date
Readable communication report for humans to understand
As a business, I want to send intact invoices successfully so that my invoices are sent and not lost.
Corruption check
Files sent in correct format (UBL XML)
As a business, I want to be able to deliver invoices in different ways, so that I have flexibility and choice in reaching my clients.
Sending via SMS
Sending via Email
As a business, I want to be able to send to multiple recipients at once, so I don’t have to send it to them individually.
USE CASE
After requesting an invoice and it being created, I click send invoice
I pick the delivery method (Email/SMS/SFTP) and input the details
I click ‘send invoice’ and the system send the invoice to the addressee
If the invoice is sent successfully, I receive a Communication Report with success and details
If the invoice is sent unsuccessfully, I receive a Communication Report with related errors and details, and am taken back to the sending page.
Requirements
Ability to send XML via email, MMS and SFTP (MAYBE)
Ability to receive details of the user to send invoice
Ability to send to multiple users at once
Ability to recieve XML data
Ability to report back on success/failure of function
Ability to provide informative error description
The API needs to have a health check endpoint.