W1 - What is business analysis in IT Who is Business analyst Types of Business analysts The business analyst’s tasks Essential BA skills Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders. IIBA - International Institute of Business Analysis The term "business analysis" is understood as a set of techniques that allows to identify the structure and specifics of an organization, identify its needs and find options for solving business problems. During the business analysis, the requirements for the business solution, the functionality required by the customer, are determined, and the documentation for the developers is agreed. If there is no BA… • Missed deadlines • Poor quality of documentation • Lack of time • Lack of knowledge A business analyst enables change in an organizational context by defining needs and recommending solutions that deliver value to stakeholders. The analyst elicits and analyzes others’ perspectives, transforms the information collected into a requirements specification, and communicates the information to other stakeholders. The analyst helps stakeholders find the difference between what they say they want and what they really need So who is Business Analyst? A business analyst is a specialist who investigates the needs of organization using business analysis methods to identify existing problems and find solutions. The business analyst is the individual who has the primary responsibility to elicit, analyze, document, and validate the needs of the project stakeholders. Types of BA ● Systems analyst ● Business Process analyst ● Business consultant ● Investment analyst ● Data analyst ● Product analyst Business analyst - Gathering, analyzing and documentation of requirements of customers. - Tasking and monitoring of implementation - Proposes solutions to the customer. Business Process analyst studies and improves business processes: HR, recruiting, teamwork, management. Product analyst studies product metrics, explores growth points and proposes solutions to management. System analyst analyzes the received business requirements, clarifies them and develops detailed functional and non-functional requirements in accordance with the characteristics of the future system. System analysts design data models, describe communication protocols between systems. Investment analyst evaluates the investment attractiveness of businesses. Data analyst processes large amounts of data using scripts, visualizes information, conducts quantitative research; BA tasks - Document requirements - Define business requirements - Communicate requirements - Plan the requirements approach - Lead requirements validation - Identify project stakeholders and user classes - Facilitate requirements - Elicit requirements prioritization - Analyze requirements - Manage requirements ● Elicit requirements. A proactive analyst helps users articulate the system capabilities they need to meet their business objectives by using a variety of information-gathering techniques. ● Document requirements. The analyst is responsible for documenting requirements in a well-organized and well-written manner that clearly describes the solution that will address the customer’s problem. ● Communicate requirements You must communicate the requirements effectively and efficiently to all parties. The BA should determine when it is helpful to represent requirements by using methods other than text, including various types of visual analysis models, tables, mathematical equations, and prototypes. Essential BA skills - Facilitation skills - Listening skills - Leadership skills - Interviewing and questioning skills - Observational skills - Thinking on your feet - Communication skills - Analytical skills - Organizational skills - Systems thinking skills - Modeling skills - Learning skills - Interpersonal skills - Creativity Interviewing and questioning skills. Most requirements input comes through discussions, so the BA must be able to interact with diverse individuals and groups about their needs. It can be intimidating to work with senior managers and with highly opinionated or aggressive individuals. ● Thinking on your feet. Business analysts always need to be aware of the existing information and to process new information against it. ● Analytical skills. An effective business analyst can think at both high and low levels of abstraction and knows when to move from one to another. The flow of BA’s job: 1. Understanding the current state 2. Help form the desired result 3. Draw up a plan of action from the present to the future. ● W2 Requirements ● ● ● ● ● What is Requirement? Levels and types of requirements Why it is important to document Product vs Project requirements Requirements engineering Definitions of Requirement Anything that drives design choices © Brian Lawrence Requirements are a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system. © Ian Sommerville и Pete Sawyer Levels of requirements 1. Business requirements 2. User requirements 3. Functional requirements In addition, every system has an assortment of nonfunctional requirements. Business requirements describe why the organization is implementing the system—the business benefits the organization hopes to achieve. The focus is on the business objectives of the organization or the customer who requests the system. Example. An airline wants to reduce airport counter staff costs by 25 percent. This goal might lead to the idea of building a kiosk that passengers can use to check in for their flights at the airport. Business requirements typically come from ● Funding sponsors ● Manager of actual users ● Marketing department ● Product visionary (who is responsible for the concept of the product) The various stakeholders’ objectives sometimes are in alignment. For instance, both the kiosk developers and the customers want to have a wide variety of products or services available through the kiosk. However, some business objectives could conflict. The customer wants to spend less time purchasing goods and services, but the retailer would prefer User Requirements to have customers store User requirements describelinger goalsinorthe tasks the users must be able to perform with the product that will provide value to and spend more money. someone. The domain of user requirements also includes descriptions of product attributes or characteristics that are important to user satisfaction. Ways to represent user requirements include use cases, user stories, and event-response tables. User requirements describe what the user will be able to do with the system. An example of a use case is “Check in for a flight” using an airline’s website or a kiosk at the airport. Written as a user story, the same user requirement might read: “As a passenger, I want to check in for a flight so I can board my airplane.” Functional Requirements Functional requirements specify the behaviors the product will exhibit under specific conditions. They describe what the developers must implement to enable users to accomplish their tasks (user requirements), thereby satisfying the business requirements. This alignment among the three levels of requirements is essential for project success. Functional requirements often are written in the form of the traditional “shall” statements: “The Passenger shall be able to print boarding passes for all flight segments for which he has checked in” or “If the Passenger’s profile does not indicate a seating preference, the reservation system shall assign a seat.” Relationships among several types of requirements information. Solid arrows mean “are stored in”; dotted arrows mean “are the origin of” or “influence. The business analyst documents functional requirements in a software requirements specification (SRS), which describes as fully as necessary the expected behavior of the software system. People call this artifact by many different names, including business requirements document, functional spec, requirements document, and others. Artifact - any solution-relevant object that is created as part of business analysis efforts. Quality attributes are also known as quality factors, quality of service requirements, constraints, and the “–ilities.” They describe the product’s characteristics in various dimensions that are important either to users or to developers and maintainers, such as performance, safety, availability, and portability. A feature consists of one or more logically related system capabilities that provide value to a user and are described by a set of functional requirements. A customer’s list of desired product features is not equivalent to a description of the user’s task-related needs. Examples of features: - Web browser bookmarks - Spelling checkers - The ability to define a custom workout program for a piece of exercise equipment - Automatic virus signature updating in an anti-malware product and so on. Feature tree, an analysis model that shows how a feature can be hierarchically decomposed into a set of smaller features, which relate to specific user requirements and lead to specifying sets of functional requirements. Let’s have a look to an example Project - Developing the next version of a text editor program. A business requirement - “Increase non-US sales by 25 percent within 6 months.” They want to add new feature - a multilanguage spelling checker feature. User requirements might include following tasks: - “Select language for spelling checker,” - “Find spelling errors,” - “Add a word to a dictionary.” The spelling checker has many individual functional requirements, which deal with operations such as highlighting misspelled words, autocorrect, displaying suggested replacements, and globally replacing misspelled words with corrected words. Working with three levels An example of how different stakeholders participate in requirements development. Product vs Project requirements Projects certainly do have other expectations and deliverables that are not a part of the software the team implements, but that are necessary to the successful completion of the project as a whole. Project requirements include - Physical resources the development team needs, such as workstations, special hardware devices, testing labs, testing tools and equipment, team rooms, and videoconferencing equipment. - Staff training needs. - User documentation, including training materials, tutorials, reference manuals, and release notes. - Support documentation, such as help desk resources and field maintenance and service information for hardware devices. - Infrastructure changes needed in the operating environment. - Requirements and procedures for releasing the product, installing it in the operating environment, configuring it, and testing the installation. - Product certification and compliance requirements. - Revised policies, processes, organizational structures, and similar documents. - Sourcing, acquisition, and licensing of third-party software and hardware components. - Beta testing, manufacturing, packaging, marketing, and distribution requirements. - Customer service-level agreements. - Requirements for obtaining legal protection (patents, trademarks, or copyrights) for intellectual property related to the software. Subdisciplines of software require Elicitation Elicitation encompasses all of the activities involved with discovering requirements, such as interviews, workshops, document analysis, prototyping, and others. The key actions are: ● Identifying the product’s expected user classes and other stakeholders. ● Understanding user tasks and goals and the business objectives with which those tasks align. ● Learning about the environment in which the new product will be used. ● Working with individuals who represent each user class to understand their functionality needs and their quality expectations. Analysis Analyzing requirements involves reaching a richer and more precise understanding of each requirement and representing sets of requirements in multiple ways. Following are the principal activities: ● Analyzing the information received from users to distinguish their task goals from functional requirements, quality expectations, business rules, suggested solutions, and other information ● Decomposing high-level requirements into an appropriate level of detail ● Deriving functional requirements from other requirements information ● Allocating requirements to software components defined in the system architecture ● Negotiating implementation priorities ● Identifying gaps in requirements or unnecessary requirements as they relate to the defined scope Specification Requirements specification involves representing and storing the collected requirements knowledge in a persistent and well-organized fashion. The principal activity is: ● Translating the collected user needs into written requirements and diagrams suitable for comprehension, review, and use by their intended audiences. Validation Requirements validation confirms that you have the correct set of requirements information that will enable developers to build a solution that satisfies the business objectives. The central activities are: ● Reviewing the documented requirements to correct any problems before the development group accepts them. ● Developing acceptance tests and criteria to confirm that a product based on the requirements would meet customer needs and achieve the business objectives. Requirements Management Requirements management activities include the following: ● Defining the requirements baseline, a snapshot in time that represents an agreed-upon, reviewed, and approved set of functional and nonfunctional requirements, often for a specific product release or development iteration ● Evaluating the impact of proposed requirements changes and incorporating approved changes into the project in a controlled way ● Keeping project plans current with the requirements as they evolve ● Negotiating new commitments based on the estimated impact of requirements changes ● Defining the relationships and dependencies that exist between requirements ● Tracking individual requirements to their corresponding designs, source code, and tests ● Tracking requirements status and change activity throughout the project The major consequence of requirements problems is rework — doing again something that you thought was already done — late in development or after release. Rework often consumes 30 to 50 percent of your total development cost and requirements errors can account for 70 to 85 percent of the rework cost. Creating better requirements is an investment, not just a cost. Your greatest investment is the time your project teams actually spend on requirements engineering tasks. The potential benefits includes: ● Fewer defects in requirements and in the delivered product. ● Reduced development rework. ● Faster development and delivery. ● Fewer unnecessary and unused features. ● Lower enhancement costs. ● Fewer miscommunications. ● Reduced scope creep. ● Reduced project chaos. ● Higher customer and team member satisfaction. ● Products that do what they’re supposed to do. Requirements development process framework Requirements development is an iterative process. “Progressive refinement of detail” is a key operating phrase for requirements development, moving from initial concepts of what is needed toward further precision of understanding and expression. Concept and scope of the project Concept and scope are two basic elements of business requirements. A product vision succinctly describes the final product that will achieve the set business goals. The project scope indicates which part of the final product concept the current project or iteration will focus on. Vision and scope document The vision and scope document collects the business requirements into a single deliverable that sets the stage for the subsequent development work. Some organizations create a project charter or a business case document that serves a similar purpose. The owner of the vision and scope document is the project’s executive sponsor, funding authority, or someone in a similar role. A business analyst can work with this individual to articulate the business requirements and write the vision and scope document. Input comes from the following stakeholders: - senior management - a product visionary - a product manager - a subject matter expert - members of the marketing department Template for a vision and scope document Business requirements Projects are launched in the belief that creating or changing a product will provide worthwhile benefits for someone and a suitable return on investment. The business requirements describe the primary benefits that the new system will provide to its sponsors, buyers, and users. Business requirements directly influence which user requirements to implement and in what sequence. Business objectives Summarize the important business benefits the product will provide in a quantitative and measurable way. Platitudes (“become recognized as a world-class <whatever>”) and vaguely stated improvements (“provide a more rewarding customer experience”) are neither helpful nor verifiable. Success metrics Specify the indicators that stakeholders will use to define and measure success on this project. Identify the factors that have the greatest impact on achieving that success, including factors both within and outside the organization’s control. Vision statement Write a concise vision statement that summarizes the long-term purpose and intent of the product. The vision statement should reflect a balanced view that will satisfy the expectations of diverse stakeholders. Key word template: ● For [target customer] ● Who [statement of the need or opportunity] ● The [product name] ● Is [product category] ● That [major capabilities, key benefit, compelling reason to buy or use] ● Unlike [primary competitive alternative, current system, current business process] ● Our product [statement of primary differentiation and advantages of new product] Business risks Risk categories include marketplace competition, timing issues, user acceptance, implementation issues, and possible negative impacts on the business. Business risks are not the same as project risks, which often include resource availability concerns and technology factors Business assumption An assumption is a statement that is believed to be true in the absence of proof or definitive knowledge. Business assumptions are specifically related to the business requirements. Incorrect assumptions can potentially keep you from meeting your business objectives. Scope and limitations The scope and limitations help to establish realistic stakeholder expectations because customers sometimes request features that are too expensive or that lie outside the intended project scope. At each level, the scope must stay within the bounds of the level above it. For example, in-scope user requirements must map to the business objectives, and functional requirements must map to user requirements that are in scope. Business context This section presents profiles of major stakeholder categories, management’s priorities for the project, and a summary of some factors to consider when planning deployment of the solution. Stakeholder profiles Stakeholders are the people, groups, or organizations that are actively involved in a project, are affected by its outcome, or are able to influence its outcome The stakeholder profiles describe different categories of customers and other key stakeholders for the project.
