My requirements process: How i look at a process for gathering requirements

I have created a short requirement analysis based on a company doing e-commerce payments system. I have not talk to any of the stakeholders and the information i gathered is based on its software workflow and the information it provides on their webpage.
我用一个公司创建电子商务的支付系统创建了一个简短的需求分析. 我的资料收集是基于其软件的工作流程和我所收集的资料, 都是从他们的网页读和分析的。

When i need to gathered requirements, this is how i will look at a process before implementing the necessary codes to create a system.
当我需要收集需求分析资料的时候，这就是我会在这个过程看在实施必要，然后再创建一个系统。

A short example of my use-case:

For their system doing payments, i will list down the key payment business rules in the system.

Types of Payments from users with different sets of business rules:

• Credit Cards
• Debit Cards
• E-Giro
• Remittance
• Mobile E-banking users
• Pay-pal
• Corporate Accounts
• Bank branches/Foreign banks

Next i will break down the scenario into cases.

Scenario breakdown:

1. Get the user account number and location
2. Send the credentials
3. Check and verify
4. Ask security questions
5. Permit access to the account
6. View payment items
7. User confirms the payment and sends in the payment details
8. Business rules to determine the type of settlement services
9. Confirm the settlement at the back office
10. Confirm settlement to user

Define what are the normal case scenarios

Normal Case Scenarios

1. Inputs: User account, password, objects to make payments for. Output: Records inserted into the back end and confirmation made to the payer

The payer’s account number, password, purchased items and his account are both constraints on the work. His account number comes from outside, which is the account number & password that he needs to input. The record account is a constraint imposed by the bank system; in this case, it cannot be changed.

However, the account number, password, purchased items and his account are means to an end the real work to be done is to make the payment transaction. 

2. The implementation of the security encapsulation protocols to transfer data

The use of the security features such as SSL to transfer payer details

3.  Ensure the payer is correctly identified and connected to the right account.

4. Check the payer account is valid and belongs to the payer.

• The account must be current in used.
• Enough funds in his account
• Credit limit is not exceed
• Displays his payment history

What is the main goal of this process?

Business Event: Payer decides to make payment

What are the information that must be available before the system will starts the functions?

Trigger: Payers account, password, purchased items list/payment items, account database

Preconditions: The payer must have an account

Interested stakeholders: Types of payment account(Visa, Mastercard, E-banking, Paypal, etc), Payment List, workflow, security, goal of the transaction

Active stakeholders: Payer, Institutions

• Verify the payer’s account
• Transfer data using security encryption
• Check the account is valid
• Check with business rules to ensure the account can be used.
• Verify the items which payment is to be made
• Select the type of payment
• Check with the business rules to select the type gateway
• Process with payment and record in the backend
• Process with payment and sends confirmation to payer.

 This alternative case scenarios states how payers will get to choose their desired payments and system will wait for their input before processing.

Alternative Case Scenarios

5. Using payment Gateway to make payments

In this scenario, alternative case can arrive when it comes to choosing which payment gateway.

Consider this step 5 scenario:

• Choose to use the Visa/Master, Paypal, and etc gateway based on business rules engine to select payers’ payment preferences
• Using the guiding payment rules to facilitate the transaction work flow

In any case, sometimes we need to cater for systems that encounter exception scenarios for eg: Something disrupts the workflow and how we can introduce solutions to rectify them

Exception Cases

6. The goal of this exception case is to show how we can handle exceptions when the business workflow deviates from the goal.

Some of the exceptions can be:

• What happens if the server is loaded and transaction process is taking a long time?
• What happens if there is error encountered while inserting records in the database?
• What can go wrong in these steps?

Solutions:

1. Some solutions to solve the stress of the servers can be using the load balancer to move the load of users to different servers
2. Using the cluster server to handle the load, for eg: if one of the server is down, the second server can be kick start to continued the process
3. Implement the functions in the business rules to synchronize the methods for inserting data
4. Solutions to handle the error in data insertion will be having a rollback mechanism in the business logic to prevent duplications or dirty records

Next we need to cater for misuse cases or scenarios that are unwanted or will be causing disastrous results to the system.

Misuse Cases & Negative Scenarios

7. This case may surface when an antagonist uses someone’s account to make transactions.

Scenarios to stop/prevent the misuse

• The payer key in an incorrect password for an account that is not his
• Allow the antagonist to key in 3 times (this is for ebanking account)
• Freeze/lock the account when the password is incorrect(this is for ebanking account)
• Send an sms if payment exceed a certain amount (for credit cards)

Finally the goal to the system

Outcome

The payment is make successfully, records retained at the institutions’ backend and confirmation make to payers’ records.

Lastly some of the test cases that we can implemented to make sure the system is well prepared for users usage:

Types of testing to deployed

• Unit Testing (Component Testing) – testing of individual module components as they are completed. 
• Integration Testing – testing to integrate multiple modules
• User Acceptance Testing – testing by users/customer to get approval that business flow is correct and what they want
• Functional Testing (Black Box Testing) – testing done to ensure the final output is what the user/customers want
• Usability Testing – testing for users where they can get to understand more about  the application, as well as the users’ efficiency and productivity.
• Performance Testing (Load Testing, Stress Testing) – refers to testing performed to evaluate whether the system. Eg: Use idx-tsunami stress tool to simulate a high number of users and emulate the using of the system at the same time