What the Business Systems Analyst is Working to Achieve
The job of the Business Systems Analyst (BSA) is to obtain information from stakeholders and transform that information into documentation the technical staff can successfully use as the basis of their work. The key to doing this is moving the information through a series of stages that start with the mostly natural language from the stakeholders and ends with the formalized documentation required by the technical staff. Stakeholder Information Stakeholder information can come in many different forms. Examples are formal meetings, informal conversations, business process documentation, and demonstrations of existing applications. The information may or may not be organized, and what organization exists may be quite different than what you need for your project. What You Give the Technical Staff The technical documentation needs to be organized in a way that allows the technical staff to easily find all of the information they need to do their work and to then smoothly automate it. For example, if your job is to create the specifications for an entry page being added to a business application, you might create the following:
A picture of the page desired.
A description of each value to be entered.
The sequence in which the values are to be entered.
What rules to enforce about each value.
What to do with the values when the user is done.
The technical person should only have to make technical decisions when implementing this page. Examples of valid technical decisions are the programming language to use, how to program this functionality in that language, and so on. Transforming the Stakeholder Information to Technical Documentation The process starts in the mostly natural language of the stakeholders’ information. The process ends with the information being transformed into the precise technical documentation to be automated. The stages between them are done to ensure that the final technical documentation fully covers the stakeholder requirements, is consistent, and will result in a good technical product. For example, if it is a business application, it will have an easy-to-use and logical user experience. A small project may have just a couple of stages. A large, complex project may have many. On a very small project it may be possible to work from the stakeholder information straight through to the technical documentation. On larger projects, one would start with the stakeholder information and progress until it becomes difficult to move forward. It becomes difficult because it is not possible to exactly know the target of the current stage until you have worked out some of the next stage. So you would switch to the next stage and start working that out. This can become an iterative process of working with a stage until it is not possible to move forward until you have a better idea of the next stage and then moving to the next stage. You would move forward like this until you find you need to go back to the earlier stages and make them more complete before you can continue. In this way, one moves from the stakeholder information to the technical documentation. How Would this Apply to Agile? The transformation of stakeholder requirements to information the technical staff can smoothly automate helps ensure the success of the project. However, in an Agile methodology, the development is not held off until the requirements are complete. Starting development before the requirements are complete (Agile) and not starting the development before the requirements are complete (Waterfall) both have their own risks. If you are an analyst on an Agile methodology, you should know the full analysis process below even if you cannot fully do it. This way, you can best manage what you do to lower the risk of the technical staff having to redo work. Example Stages Say a client wants you to specify a software application to manage their business. The stages in such a project might be the following:
Use cases to define current state business processes.
A proposed list of screens and reports that could be used to automate these business processes.
Use cases to define future state business processes referencing the new application.
The full functionality in the screens and reports in the new business application.
A data model of the new business application.
When the technical specifications are finished, create a document that can orient the technical staff to what the client is trying to achieve. The technical staff has many decisions they must make and understanding the goals of the client will help them. If you can, work with the technical team to ensure they understand the technical documentation and to answer questions as their work progresses. Even if the technical documentation is perfectly written, different people might interpret it differently. Ensuring that it is interpreted correctly can be a major part of your work, especially if you have multiple teams of developers. How this Varies from Project to Project Some projects can require stages that others do not. If you find it difficult to move forward on a project, see if there is another tool you can use to help you. For example, to help organize work flows between stakeholder groups, use an Activity diagram. To manage a complex life cycle of an entity in the data model, use a State Transition Diagram. A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) lists many such tools. If you still find it difficult to move forward on a project, see if you can find a more experienced BSA who can help you. You might just need a little help to do the entire project.