A Business Analyst Perspective
By Ayesha Khanna

1. Introduction
The Rational Unified Process (RUP) is a framework for developing software systems. It represents an organized way of gathering business requirements and building the system given a project goal. It also clearly delineates the different roles of the people involved in the project, such as the project manager, business analyst and developers. This article discusses the use of the RUP framework from the perspective of the business analyst, using the implementation of a new equity trading system as a case study.

2. Business Analyst
A business analyst (BA) is responsible for effectively communicating the business requirements for the system to the development team. This requires the analyst to be a liaison between the project stakeholders, the people funding the project, and the development team building the software system. The role of the business analyst is increasingly becoming important in the financial services industry as trading and risk management systems become more dependent on technology. The BA is required to know both the business side, in this case securities trading, and have a fundamental knowledge of good programming practices, such as object oriented design. The key function of the BA is to gather and document business requirements, and to assist the development team in testing the final product. Documenting requirements includes writing functional specifications such as Use Cases, creating workflow diagrams, and authoring test suites for quality assurance (QA) testing.

3. Rational Unified Process
The rational unified process divides the development of any system into four distinct phases: Inception, Elaboration, Construction and Transition. It outlines the concept of iterative, incremental development, where components are added to the system in increments and each iteration of these additions follows the four phases outlined earlier. RUP recommends six best practices to follow during system development: (i) Develop software iteratively; (ii) Manage requirements; (iii) Use component based architecture; (iv) Visually model software; (v) Verify software quality; and (vi) Control changes to software.

The following diagram shows the progression and overlap of the different components over the four stages of development.

4. Case Study: Equity Trading System
An equity trading system is a real time software system that allows traders to book trades, view market trends, and manage their portfolios; it allows risk managers to calculate risk analytics, such as Value-at-Risk (VAR) for a portfolio of stocks, and to calculate profit and loss (PnL); it stores reference and market related information for a particular stock, and updated positions for each stock.

The following diagram shows the main workflows for the trading system for the front, middle and back offices – trade execution, risk management and reporting.

4.1 Inception
The first step is to determine the goal and scope of the project. In this case, it is to build an equity trading system with the goals outlined in the last paragraph. To understand the required workflows, the BA must gather requirements from all the clients or stake-holders that will use the system. In this case, these clients are the traders and the risk managers. Requirements gathering involves setting up meetings and conference calls with the clients and taking detailed notes on what functionality they would like to see in the final product. These business requirements are documented in workflow diagrams and in word documents.

Workflow diagrams can be made using Unified Modeling Language (UML) which provides a standard set of visual artifacts for modeling business workflows.

In order to prioritize the requirements, the BA draws a list of the most important functionalities, otherwise known as the riskiest parts of the project since their failure will invalidate the system, and documents these functionalities in both Use Cases and timelines.

In the inception phase, only 20% of the Use Cases are created, these being the most fundamental to the system. A Use Case is a word document written in a standardized format; it documents one use of the system. An example of a Use Case is ‘Booking a Trade’. A Use Case has several standard parts: Name (Booking a Trade), Actors (traders), Preconditions (Login to System), Workflow (Choose a security by selecting a symbol, Select a price and quantity, Submit by pressing Buy/Sell button), Alternate Workflow (Choose a basket of securities, Select prices and quantities for each security, Submit by pressing Buy/Sell button), Postconditions (System indicates that Security has been submitted for settlement, Details of the Trade can be viewed on the screen), Exceptions (Security symbol not found in the system, Send email to Support Team).

4.2 Elaboration
Once business requirements have been gathered and documented, they are submitted to the project stake-holders for review and final sign-off. After approval, these requirements are formalized as the goals of the system.

The BA then writes all the functional specifications of the system in the Elaboration phase. This means that each and every functionality is written up as a Use Case. These Use Cases are reviewed and approved by the clients, and then given to the development team, which will start coding the functions in the Construction phase.

The BA also writes detailed technical specifications for the development team. These include data feed documents which provide details on which fields from the market data provider, such as Bloomberg, will be used to populate fields in the GUI and in the database. For example, the security master file that comes from Bloomberg will contain a field called SYMBOL and this field will populate the field called ‘Security Symbol’ in the GUI that is used by the trading desk, and will also populate the ‘secsymbol’ field in the SecurityMaster table in the database. Further details such as the datatype of the field (in this case, a string or text field) and length of the field (varchar 20) will be added to the data feed document, which is presented in an Excel spreadsheet.

4.3 Construction
After the BA provides all the functional and technical specifications to the development team, the software developers use these artifacts along with the workflow diagrams, to start coding parts of the system. The BA is not involved in the Construction phase of the project except to answer questions from the development team regarding further details and requirements, and to communicate any additional requirements brought forth by the clients.

4.4 Transition
When the system has been built and is in ‘Development’ phase, it is ready to be tested for completeness and accuracy. The BA then tests each one of the Use Cases to ensure that all requirements were met, and designs further test suites based on his or her knowledge of the financial products relevant to the system. Three kinds of tests are pertinent to the QA testing: functional [the GUI workflows are well executed], performance [large data sets and multiple users can be handled concurrently] and accuracy [data and calculations are correct] testing.

When the BA has completed testing in ‘Development’, the system is put in ‘UAT’ [User Acceptance Testing] phase, which means that assigned users from the clients can now test the system. This is the final testing of the system before it is released into ‘Production’ status.

After a system is in production, the BA may be called upon to give users training on how to use the new system, and to write a user guide for it.

5. Conclusion
In summary, the RUP framework is an effective and efficient framework for organizing all parts of the development process, including the work done by the business analysts. The RUP founders have created several software components to assist in creating the artifacts outlined by their framework, such as Rational Rose for UML modeling. These tools, while helpful, are not necessary when following the RUP framework. In fact, there is some argument as to whether or not they complicate the business analysis process. It is better to follow the basic tenets of the RUP methodology and to create concise, clear and detailed documentation that is simple in its layout and presentation.

Image Courtesy Corbis