Download
1 / 59
641 likes | 760 Views
Business Analysis. Inc. Purpose and Objectives. Role and Importance of BA What is Business Analysis ? Business Analysis Phases Role of Business Analyst Business Analysis Techniques Software development methodologies Waterfall Model Rational Unified Process Agile Extreme Programming
E N D
Purpose and Objectives • Role and Importance of BA • What is Business Analysis ? • Business Analysis Phases • Role of Business Analyst • Business Analysis Techniques • Software development methodologies • Waterfall Model • Rational Unified Process • Agile • Extreme Programming • Types of requirements • Business • User • System
Purpose and Objectives • Requirement gathering techniques • Interviews • Document Analysis • Brainstorming • Requirements Workshop • Joint Application Development • Prototyping • Storyboards • Diagrams for BA • Use Case Diagram • State chart diagram • Activity Diagram • Sequence Diagrams • Collaboration Diagram • Others (Class, Fish Bone etc.)
Purpose and Objectives • Documents Created by BA • BRD (Business Requirements Document) • Use case Document • Test Case Document
What is Business Analysis • It refers to the process of firstly identifying the needs of the business and then developing and implementing the solutions to meet them. • It is to take the big picture and break it into smaller parts, making it easier to ensure that company resources are being utilized in the most efficient manner. • Business analysis focus is on GOALS. It can be implemented to both set goals, and to achieve them. • Business Analysis is a process of identifying, gathering, analyzing, documenting, and managing the requirements within in a business process
Inception of BA role • Enterprise getting more complicated by the day. • Division of labor • Creation of SME’s • Communication between the various departments and lack of knowledge being a huge bottle-neck. • Developers are specialists n the various technologies. • Management know the details of the business. • BA is a Mediator that understands both the worlds to generate synergies.
Role and Importance of BA • Business Analysts have been the ones tasked with developing business cases for IT application development. • Smoothing relations among competing parties. • Most successful BA are the ones who could "communicate, facilitate and analyze.“ • Some tilt more toward business functions such as operations, marketing, finance or engineering; others seem to fit better in more IT-oriented positions such as in applications and architecture groups, or in project management offices.
Attributes of a Good BA • Analytical thinking & Problem Solving • Behavioral Characteristics • Business & Domain Knowledge • Communication Skills Listening Speaking Writing • Interaction Skills • Facilitator • Negotiator • Strategist • Planner • Software Applications & Tools Knowledge • Diplomat
Software Development Methodologies : Waterfall Model • The model develops systematically from one phase to other in a downward fashion, like a waterfall. • It has been structured on multiple phases to help out the software construction companies to develop an organized system of construction • Once final point is reached, you cannot turn back; similar to the water in a waterfall.
Waterfall Model Advantages Disadvantages • The project requires the fulfillment of one phase, before proceeding to the next. Therefore fault in s/w will be detected during one of the initial phases and will be sealed off for correction. • A lot of emphasis is laid on paperwork. It is easier for new employee to carry on the work from where it had been left. • The Waterfall method is also well known amongst the software developers therefore it is easy to use. It is easier to develop various software through this method in short span of time. • Doesn’t work well in projects that do not have well defined requirements as we might have to start all over again and it might not be cost effective. • Huge amount of time is wasted as we cannot start one phase unless the previous phase has been successfully completed. • Testing period comes quite late in the developmental process unlike other approaches where it is lot sooner thus saving lots a time and money. • It takes a lot of effort and time to do documentation, which is why it is not suitable for smaller projects.
Software Development Methodologies : RUP Model • Iterative software development process developed by Rational Software Corporation, IBM. • It has determined a project life cycle consisting of four phases, each phase has one key objective and milestone at the end that denotes the objective being accomplished. • Defines Visual Modeling as the use of semantically rich, graphical and textual design notations to capture software designs using UML.
Software Development Methodologies : RUP Model • Inception Phase • The primary objective is to scope the system adequately as a basis for validating initial costing and budgets. • Also to understand the scope of the entire project, building the business cases and to get the stakeholders approval to proceed with the next phase. • Once the inception phase is reached we would have the stakeholder’s agreement on the estimation of the cost and schedule and the most important part of prioritizing the requirements. • Elaboration Phase • The major goal is to reduce the technical risk and basically understand what it takes to build the system. • It includes development of the basic form of project architecture and use case descriptions. • The business case is revisited to revise the project risks log and the development plan of the overall project is created. If each of the technical risks have not been taken care of, the project may be cancelled
Software Development Methodologies : RUP Model • Construction Phase • The primary objective is to build the software system. • This is the phase when the bulk of the coding takes place. In larger projects, several construction iterations may be developed in an effort to divide the use cases into manageable segments that produce demonstrable prototypes. • Transition Phase • The primary objective is to 'transit' the system from development into production, making it available to and understood by the end user. • The activities of this phase include training the end users and maintainers and beta testing the system to validate it against the end users' expectations. • The product is also checked against the quality level set in the Inception phase.
Software Development Methodologies : Agile Model • Agile software development is a style of software development that emphasizes customer satisfaction through continuous delivery of functional software. • Iterative: Entire application is distributed in incremental units called as iteration. Development time of each iteration is small (couple of weeks), fixed and strictly adhered to. Every Iteration is a mini increment of the functionality and is build on top of previous iteration. • Active Customer involvement: There is lot of client involvement and face-to-face interaction. Every iteration is tested and approved by client. The feedback obtained is implemented in subsequent iterations; thus minimizing risk and ensuring higher client satisfaction. • Feature driven: More emphasis is on providing the required features in the application. 80/20 principle is applied to decide the 20% features which would be used 80% of the time. • Priority based delivery: Features are prioritized depending on customer need, development risk etc. High priority features are developed first. After every iteration, the project priorities are re-evaluated. • People Centric: More emphasis is on using the adequately skilled people to do the development than on following the processes. The documentation and other non-development activities are minimized and more time is devoted to development and testing.
Software Development Methodologies : Agile Model • The most widely used methodologies based on the agile philosophy are XP and Scrum. These differ in particulars but share the iterative approach.
Agile Variants: XP • XP stands for extreme programming. • It concentrates on the development rather than managerial aspects of software projects.
Agile Variants: XP Rules • Integrate often: Development teams must integrate changes into the development baseline at least once a day. This concept is also called continuous integration. • Project velocity: Velocity is a measure of how much work is getting done on the project. This important metric drives release planning and schedule updates. • Pair programming: All code for a production release is created by two people working together at a single computer. XP proposes that two coders working together will satisfy user stories at the same rate as two coders working alone, but with much higher quality. • User story: A user story describes problems to be solved by the system being built. These stories must be written by the user and should be about three sentences long. User stories do not describe a solution, use technical language, or contain traditional requirements-speak, such as “shall” statements. Instead, a sample user story might go like this: Search for customers. The user tells the application to search for customers. The application asks the user to specify which customers. After the user specifies the search criteria, the application returns a list of customers meeting those criteria.
Agile Variants: SCRUM • Scrum methodology includes both managerial and development processes. • Scrum management • After the team completes the project scope and high-level designs, it divides the development process into a series of short iterations called sprints • Before each sprint, the team members identify the backlog items for the sprint. At the end of a sprint, the team reviews the sprint to articulate lessons learned and check progress. • When enough of the backlog has been implemented so that the end users believe the release is worth putting into production, management closes development. The team then performs integration testing, training, and documentation as necessary for product release.
Agile Variants: SCRUM • Scrum Development • Before each sprint begins, the team plans the sprint, identifying the backlog items and assigning teams to these items. Teams develop, wrap, review and adjust each of the backlog items • During development, the team determines the changes necessary to implement a backlog item. The team then writes the code, tests it, and documents the changes. During wrap, the team creates the executable necessary to demonstrate the changes. In review, the team demonstrates the new features, adds new backlog items, and assesses risk. Finally, the team consolidates data from the review to update the changes as necessary.
Agile Variants: SCRUM • Burndown chart: This chart, updated every day, shows the work remaining within the sprint. The burndown chart is used both to track sprint progress and to decide when items must be removed from the sprint backlog and deferred to the next sprint. • Product backlog: Product backlog is the complete list of requirements—including bugs, enhancement requests, and usability and performance improvements—that are not currently in the product release. • ScrumMaster: The ScrumMaster is the person responsible for managing the Scrum project. Sometimes it refers to a person who has become certified as a ScrumMaster by taking ScrumMaster training. • Sprint backlog: Sprint backlog is the list of backlog items assigned to a sprint, but not yet completed. In common practice, no sprint backlog item should take more than two days to complete. The sprint backlog helps the team predict the level of effort required to complete a sprint.
Requirement Types Business Requirements User Requirements System Requirements Non-Functional Requirements Functional Requirements
Business Requirements • The business requirement is written from the Sponsor's point-of-view. • It defines the objective of the project (goal) and the measurable business benefits for doing the project. • The following sentence format is used to represent the business requirement and helps to increase consistency across project definitions: "The purpose of the [project name] is to [project goal -- that is, what is the team expected to implement or deliver] so that [measurable business benefit(s) -- the sponsor's goal]."
User Requirements • The user requirements are written from the user's point-of-view. • User requirements define the information or material that is input into the business process, and the expected information or material as outcome from interacting with the business process (system), specific to accomplish the user's business goal. • The following sentence format is used to represent the user requirement: "The [user role] shall [describe the interaction (inputs and outputs of information or materials) with the system to satisfy the user's business goal.]" or "The [user role] shall provide (input)/ receive (output.)"
Functional Requirements • The functional requirements define what the system must do to process the user inputs (information or material) and provide the user with their desired outputs (information or material). • Processing the inputs includes storing the inputs for use in calculations or for retrieval by the user at a later time, editing the inputs to ensure accuracy, proper handling of erroneous inputs, and using the inputs to perform calculations necessary for providing expected outputs. • The following sentence format is used to represent the functional requirement: "The [specific system domain] shall [describe what the system does to process the user inputs and provide the expected user outputs]." Or "The [specific system domain/business process] shall (do) when (event/condition)."
Non-Functional Requirements • The nonfunctional requirements define the attributes of the user and the system environment. • Nonfunctional requirements identify standards, for example, business rules, that the system must conform to and attributes that refine the system's functionality regarding use. • Because of the standards and attributes that must be applied, nonfunctional requirements often appear to be limitations for designing an optimal solution. • Nonfunctional requirements are also at the System level in the requirements hierarchy and follow a similar sentence format for representation as the functional requirements:"The [specific system domain] shall [describe the standards or attributes that the system must conform to]."
Requirement Gathering Techniques: Interviews • One-on-one interviews: • The most common technique for gathering requirements is to sit down with the clients and ask them what they need. • The discussion should be planned out ahead of time based on the type of requirements you’re looking for. • Generally you want to ask open-ended questions to get the interviewee to start talking and then ask probing questions to uncover requirements. • Group interviews: • Group interviews are similar to the one-on-one interview, except that more than one person is being interviewed — usually two to four. • These interviews work well when everyone is at the same level or has the same role. • Group interviews require more preparation and more formality to get the information you want from all the participants. You can uncover a richer set of requirements in a shorter period of time if you can keep the group focused.
Requirement Gathering Techniques: Document Analysis • All effective requirements elicitation involves some level of document analysis such as business plans, market studies, contracts, requests for proposals, statements of work, existing guidelines, analyses of existing systems, and procedures. • When you first start a project or join an existing one, analyzing existing documentation is a great way to familiarize yourself with how the business currently functions. This is especially important when the subject matter experts are too busy to dedicate enough time to meet with you to describe the current process or when experts have left the organization and all that is left is documentation. • Reviewing the documentation will help you to understand the current situation and begin to formulate the questions to ask of stakeholders to gather additional requirements. • If the project is enhancing an existing system or replacing it with a new one it will be important to know which functionality of the existing solution the stakeholders want to carry over to the new one and which can be retired. • While reviewing the existing documentation it is important to jot down questions that arise that can be brought to the stakeholders
Requirement Gathering Techniques: Brainstorming • Brainstorming is a short group session where everyone is allowed to say whatever they feel is important to the topic of discussion. After that, a facilitator leads the group in organizing and prioritizing the results. • The following basic rules for brainstorming ensures better results: • Start out by clearly stating the objective of the brainstorming session. • Generate as many ideas as possible. • Let your imagination soar. • Do not allow criticism or debate while you are gathering information. • Once information is gathered, reshape and combine ideas
Requirement Gathering Techniques: Workshops • Workshops can rapidly pull together a good set of requirements. In two to five days, you can create a set of requirements, and then review and improve them. • Workshops are quicker and better at discovering requirements than other techniques, such as sending questionnaires. You are bringing the right collection of people together, and getting them to correct and improve on their requirements document. • A workshop is inherently expensive because of the number of people involved, but it saves a large amount of time. If you can define the product right the first time and cut three months off the requirements gathering, the savings could be enormous. The workshop has to be thoroughly organized to take advantage of people's time. • Choose a quiet location for the workshop so that people are not disturbed by day-to-day business. Mobile phones should be discouraged; arrange to take messages externally. Take advantage of informal interactions by choosing a site so that people don't go home at night or go out separately • Note that the workshop provides the environment in which to apply other requirements-gathering techniques such as brainstorming.
Requirement Gathering Techniques: JAD Session • JAD session is a facilitated workshop that shortens the duration of early IT project activities while delivering better results. • Encourages out-of-box thinking • Creates consensus among stakeholders • Reduces required re-work • Increases common understanding of results • The core component of JAD is a structured, facilitated workshop that focuses on creating specified deliverables based on the group's input.
JAD Sessions • Interactive Joint Application Development (i-JAD) adds a top-notch session analyst who creates the deliverables visible to all participants during the session. • Since the final deliverable is created and critiqued immediately by all project stakeholders, i-JAD delivers the final result even faster than a conventional JAD - and with higher quality. • Uninterrupted 2 - 10 day working session • Input of each participant is captured in real-time • Evolving results visible using LCD projector • Interim deliverables distributed on paper • Final deliverable reviewed immediately by all participants • Electronic Joint Application Development (e-JAD) uses current collaboration technology from simple email to advanced web application sharing to reduce the time needed to execute critical business analysis activities. • Getting all stakeholders together via the Internet is the next best thing to being there - and it saves travel cost, time, and associated risks. • Interruptible 2 - 8 hour audience-specific work segments • Evolving results visible in shared application • Interim deliverables distributed electronically • Better access to information at your workspace • Lower overall session costs
JAD Sessions: Phases • Pre-session Planning • Evaluate the project • Create preliminary agenda • Determine deliverables for the working session • Enable participants to prepare for the session • Pre-work • Gather information from colleagues • Clear schedules for the working session • Refine the session agenda • Finalize pre-session assignments • Working Session • Create the deliverables • Generate common understanding • Achieve consensus on decisions • Generate ownership of results • Identify open issues and questions • Create action items
JAD Sessions: Phases • Follow-up • Resolve open issues and questions • Follow-up on action items • Re-evaluate project • Wrap-up • Review results of follow-up items • Evaluate the JAD process • Discuss "lessons learned"
Requirements Gathering: Prototyping • Prototypes are built early in the development lifecycle, and they’re used to provide valuable insight into the look, feel, and general workflow of an application. • After you build an initial prototype you should show it to the clients to validate the work done so far looks okay. You then use the prototype to gather additional requirements. Advantages Disadvantages • Reduced time and costs • Improved and increased user involvement • Insufficient analysis • User confusion of prototype and finished system • Developer attachment to prototype • Excessive development time of the prototype • Expense of implementing prototyping:
Requirements Gathering: Prototype Types • Complete or partial throw-away: • If you build a prototype, you’ll throw it away after the requirements have been gathered. • Prototype does not have to be the start of the final solution. The main purpose is to gather requirements. • You may leverage some of the physical components of the prototype as a starting point for the Design and Construct Phases of the project. • Iteratively develop into final application: • If you’re using an iterative development approach, the first prototype should still be put together quickly. • Instead of the work being abandoned or thrown away, the prototype is updated with the new requirements. • In the second pass, more business logic is also placed into the application. At this point, it’s no longer called a prototype. Instead, the prototype shell is used as the basis for developing the final solution.
Requirement Gathering: Storyboards • Also termed "Presentation Scenarios", are sequences of images that show the relationship between user actions or inputs and system outputs. • A typical storyboard will contain a number of images depicting features such as menus, dialogue boxes and windows. • Storyboard sequences provide a platform for exploring and refining user requirements options via a static representation of the future system by showing them to potential users and members of a design team • Points to keep in mind while Storyboarding: • Keep it simple: Keep the story simple, do not make it complicated. • Break the story into scenes: Breaking the story into scenes or sections will help you to organize the story better. It will also help you in identifying the shortcomings, if any, in the story. While making a Storyboard, do the Horizontal and Vertical analysis of storyboard, that will ensure completeness of the story. • Make it collaborative: The idea behind storyboarding is to make the complete picture clear. To make sure that you have covered every aspect of the story, involve your clients in the storyboarding session. Check the logic flow (“necessary and sufficient” arguments) • Tell a good story: In the end keep in mind to tell a good story.
Requirement Gathering: Storyboards Story board for Ticket Purchase System
Diagrams: Use Case Diagram • Used to describe the behavior of the target system from an external point of view.
Use Case Diagram: Components • Actor: • Models a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data), but which is external to the subject • Actors may represent roles played by human users, external hardware, or other subjects. • Note that an actor does not necessarily represent a specific physical entity but merely a particular facet (i.e., "role") of some entity that is relevant to the specification of its associated use cases. • Association: • Specifies a semantic relationship that can occur between typed instances. • It has at least two ends represented by properties, each of which is connected to the type of the end.
Use Case Diagram: Components • Dependency: • It is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. • This means that the complete semantics of the depending elements is either semantically or structurally dependent on the definition of the supplier element(s). • Extend: • This relationship specifies that the behavior of a use case may be extended by the behavior of another (usually supplementary) use case. • The extension takes place at one or more specific extension points defined in the extended use case. Note, however, that the extended use case is defined independently of the extending use case and is meaningful independently of the extending use case. • Note that the same extending use case can extend more than one use case. Furthermore, an extending use case may itself be extended.
Use Case Diagram: Components • Include: • It is a Directed Relationship between two use cases • Behavior of the included use case is inserted into the behavior of the including use case. The including use case may only depend on the result (value) of the included use case. This value is obtained as a result of the execution of the included use case. • Use Case: • A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system
State Chart Diagram • State chart diagram describes different states of a component in a system. • States are defined as a condition in which an object exists and it changes when some event is triggered. So the most important purpose of State chart diagram is to model life time of an object from creation to termination. • The following is an example of a Statechart diagram where the state of Order object is analyzed
Activity Diagram • Activity diagram is a special kind of a Statechart diagram. • Activity diagram is basically a flow chart to represent the flow from one activity to another activity. The activity can be described as an operation of the system. • Activity diagrams are not only used for visualizing dynamic nature of a system but they are also used to construct the executable system by using forward and reverse engineering techniques. • It does not show any message flow from one activity to another. • This diagram is used to model the activities which are nothing but business requirements. So the diagram has more impact on business understanding rather implementation details.
