Skip to content
    Share this post

    Everything you want to know about the Business Analysis Profession

    Definition, Perspectives, Process, Tools, and Techniques

    Written by:             Published on: May 27, 2022 9:31:20 AM

    Become an in-demand BA in 6 months or less!

    Talk to our Learning Advisor Today

    Everything about BA

    Business analysis is among the fastest growing fields as per LinkedIn 2020 survey. Business analysis is a key skill which every professional should acquire to enable his/her organization to scale newer heights.

    Let's learn about:

    What is business analysis?

    Business analysis perspectives

    Business analysis process

    Business analysis tools

    Business analysis techniques

    What is business analysis?

    As per Business Analysis Body of Knowledge® (BABOK® Guide) Version 3.0 from IIBA®,

    “Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders. It is a disciplined approach for introducing and managing change to organizations, whether they are for-profit businesses, governments, or non-profits. Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change.”

    Business Analysis Perspectives

    Business analysis is a vast topic. It can be conducted from multiple perspectives. Following is a list of perspectives which by no means is exhaustive.

    1. Enterprise strategy analysis
    2. Product portfolio analysis
    3. Cyber Security Analysis
    4. Enterprise Needs Analysis
    5. Enterprise analysis
    6. Project needs analysis
    7. Business Data analysis
    8. Product ownership analysis
    9. Business Process Analysis
    10. Software needs analysis
    11. Cyber security analysis

    Business Analysis Process

    The set of tasks and techniques that are used to perform business analysis are defined in the Guide to the Business Analysis Body of Knowledge® (BABOK® Guide). We have listed all the tasks in BABoK in a subsequent section. Unfortunately, BABoK does not give a definite business analysis process definition. It is rightly so because the situations are different, organizations are different, needs are different. Trying to propose a business analysis process in such varied conditions can really be a nightmarish approach.

    At the same time, applying Pareto’s principle, it will be prudent to say that in about 80% of the situations, we can propose a solid business analysis process. For remaining 20% cases, of course, we need expert guidance and need to design custom process. We are proposing a 10-step approach to business analysis. We propose following 7 steps business analysis process.

    Business analysis process - Adaptive US

     

    1. Plan, Engage, and Monitor

    There are certain activities which run across the business analysis life cycle. This is numbered as 0 as it is the foundation for the remaining phases. Phase 0 will involve continuous planning, monitoring, engaging stakeholders, managing issues, risks, requirements, traceability. For every phase, we should perform an appropriate level of planning and monitoring.

    2. Understand Project Context, Objectives, and Scope

    Often business analysts are expected contribute as soon as possible towards project delivery. Often, the project may have started already, or a phase may be completed. As business analysts, it’s our job to clarify the business and project objectives as quickly as possible. Investing some time, whether that’s a few hours or few days, to get oriented will ensure we are not only moving quickly but also competent, effective, and confident contributor for the project.

    3. Elicit Requirements

    Plan to understand the process and expectations in detail from various stakeholders to understand their expectations from the solution. Identify stakeholders who are in best position to provide the requirements. Choose appropriate techniques to conduct elicitation activities.

    4. Manage Requirements

    Not all stakeholder expectations can be met given the organizational constraints. We need to understand which requirements are critical and feasible.

    6. Document Requirements

    Detailed requirements provide the implementation team with the information they need to implement the solution.

    7. Define solution options

    Define suitable solution options to meet business and stakeholder needs.

    8. Evaluate and Improve Solution Performance

    A track record of successful projects creates significant positive momentum within an organization. So, if we need to assess the value created by the solution.

     

    Business Analysis Tools

    Commonly used business analysis tools are:

    1. Microsoft Visio
    2. Atlassian Jira
    3. Balsamiq
    4. Lucid Chart
    5. BizAgi BPM

    Business Analysis Techniques

    There are hundreds of techniques which business analysis professionals use. The most common ones are:

    Functional decomposition

    Functional decomposition breaks down a large aspect (processes, functional areas, deliverables, scope, or problems) into smaller aspects, as independent as possible, so that work can be assigned to different groups. This reduces complexity of analysis.

    Estimation

    Estimation techniques are used for better understanding of possible range of costs and efforts associated with any change.

    Interface analysis

    An interface is a connection between 2 components or solutions. Identify interfaces and interactions between solutions and/or solution components.

    Organizational modelling

    Org. modelling describes roles, responsibilities, and reporting structures that exist within an organization, and aligns those structures with organization’s goals. Visual representations of organizational units.

    Stakeholder list, map, or personas

    Identify stakeholders affected by a proposed initiative or share a common business need, level of decision-making authority, authority within domain and organization, attitude/ interest towards change, and business analysis work.

    Scope modelling

    Describe scope of analysis or scope of a solution. They serve as a basis for defining and limiting scope of business analysis and project work

    Brainstorming

    One or group of stakeholders deliberate on an idea to produce numerous new ideas in a non-judgmental environment, and to derive themes for further analysis.

    Workshops

    Requirements workshop, also known as JAD (Joint application design) session, is a highly productive focused event attended by carefully selected key stakeholders, and Subject Matter Experts for a short, intensive period (typically 1 or a few days).

    Focus groups

    Elicit ideas, impressions, preferences, and needs and attitudes from pre-qualified individuals about a specific product, service, or opportunity in an interactive group environment. Guided by a moderator. Typically 1 to 2 hours with 6-12 attendees.

    Collaborative games

    Uses game playing techniques to collaborate in developing common understanding of a problem or a solution. Involves strong visual or tactile (activities) elements such as moving sticky notes, writing on whiteboards, or drawing pictures.

    Interviews

    Most common form of elicitation technique where interviewers ask questions to stakeholders. Effective interviewers control discussions understand needs from ALL stakeholders, probe deeper when needed and ensure completeness of answers.

    Observation

    Elicit information by observing activities and their contexts.

    Survey or questionnaire

    Administers a set of written questions to stakeholders and Subject Matter Experts. Survey can elicit information from many people, sometimes anonymously, in a relatively short period of time. Can collect information about customers, products, work practices and attitudes. Alternatively, respondents are provided with a series of statements and asked for their level of agreement.

     

     

    Document analysis

    Elicit Business Analysis information, by examining materials describing business environment or organizational assets. Document analysis helps in understanding context of a business need or understanding how existing solutions are implemented. Based on Business Analysis information being explored, purpose, scope, and topics to be researched are determined.

    Benchmarking and market analysis

    Benchmarking compares org. practices against best-in-class practices from competitors, government, industry associations or standards. Market analysis understands customers’ needs, factors influencing purchase decisions, and studies competitors.

    Prototyping

    Provides an early model of final result, widely used for product design. Details UI requirements and integrates them with other requirements such as use cases, scenarios, data, and business rules. Stakeholders often find prototyping to be a concrete means of identifying, describing, and validating their interface needs. Prototypes can discover desired process flow and business rules.

    Glossary

    Comprises of key terms relevant to a business domain to provide a common understanding of terms. Contains definitions and synonyms. Needs to be organized and be accessible to all stakeholders.

    Mind Map

    Articulates and captures ideas in a non-linear (tree) structure. Ideas are grouped as topics, sub-topics, further sub-sub-topics. Mind maps use words, images, color, and connections to structure thoughts, ideas, and information.

    Backlog management

    Backlogs record, track and prioritize remaining work items. Backlog management is a planned approach to manage remaining work for project. In managed backlogs, items at top have highest business value and priority. Backlog items can be user stories, use cases, defects, CRs, risks etc.

    Business rules analysis

    Business policies dictate actions of an enterprise and people in it by broadly controlling, influencing, or regulating them. Business rules serves as a criterion for guiding behavior and making decisions in a specific, testable manner.

    Lessons learned

    Discusses and documents successes, failures and improvement recommendations for future phases or projects. Can include any format or venue that is acceptable to key stakeholders. Can be formal facilitated meetings or informal.

    Prioritization

    Provides a framework for stakeholder decisions to understand relative importance of requirements. Importance may be based on value, risk, difficulty of implementation etc.

    Reviews

    Communicate, verify, and validate content of work products, formally or informally. Communicate review objectives in advance to participants.

     

    Item tracking

    Captures and assigns responsibility for issues and stakeholder concerns. Items can refer to actions, assumptions, constraints, dependencies, defects, enhancements, and issues.

    Balanced scorecard

    A strategic planning and management tool to measure org. performance beyond traditional financial measures aligned to organization's vision and strategy.

    Business capability analysis

    Capability maps provide a graphical view of capabilities. Capabilities describes ability of an enterprise to act on or transform something that helps achieve a business goal or objective. Capabilities describe outcome of performance or transformation, not how it is performed.

    Business cases

    Formally or informally, justify investments based on estimated value compared to cost. Spend time and resources on business case proportional to the size and importance of its potential value. Business cases do not provide intricate details.

    Business model canvas

    Comprises 9 building blocks describing how an organization intends to deliver value. As a diagnostic tool, use elements of the canvas as a lens into current process or system of business, especially wrt relative amounts of energy, time, and resources currently invested in various areas.

    Decision analysis

    Supports decision-making in complex, difficult, or uncertain situations. Examines and models possible consequences of different decisions.

    Decision modeling

    Shows how repeatable business decisions are made using data and knowledge.

    Financial analysis

    Explore financial aspects (benefits and costs) of an investment.

    Risk analysis and management

    Identify, analyze, and evaluate uncertainties that could negatively affect value, develop and manage way of dealing with risks.

    SWOT analysis

    SWOT is an acronym for Strengths, Weaknesses, Opportunities, and Threats. A framework for strategic planning, opportunity analysis, competitive analysis, business, and product development.

    Concept modelling

    Organizes business vocabulary, usually starting with glossary.

    Data dictionary

    Standard definitions of primitive data elements, their meanings, allowable values, how those elements combine into composite data elements. Used to manage data within a solution’s context, often used along with ER diagrams.

    Data modelling

    Data models describe entities, classes or data objects relevant to a domain, their attributes and relationships among them.

    Data flow diagrams

    Show transformation of data from (data source such as external sources, activities and destination). Data used in DFDs should be described in a data dictionary. Highest level diagram (Level 0) is context diagram represents the entire system.

    Process modelling

    Graphical model to describe sequential flow of activities. A system process model defines sequential flow of control among programs or units within a computer system. A program process flow shows sequential execution of program statements within a software program.

    Sequence diagrams

    Sequence diagrams (also known as event diagrams) model logic of usage scenarios, by showing information (also known as stimuli, or message) passed between objects during execution of a scenario.

    State modelling

    State models (also sometimes called a process or system transition model) describe and analyze different possible states (formal representation of a status) of an entity within a system, how that entity changes from one process or system to another and what can happen to entity when it is in each state.

    User stories

    User stories are a brief textual description, typically 1 or 2 sentences, of functionality that users need from a solution to meet a business objective. User story describes actor (who uses story), goal they are trying to accomplish, and any additional information to be critical to understanding scope of story.

    Use cases and scenarios

    Scenarios, and use cases describe how actors (a person or a system) interacts with a solution to accomplish one or more of that person or systems goals.

    Non-functional requirements analysis

    Examines requirements for a solution that define how well functional requirements must perform. Also known as quality attributes or quality of service requirements. Expressed in textual formats as declarative statements or in matrices.

    Roles and permissions matrix

    Ensure coverage of activities by denoting responsibility, to identified roles, and to discover missing roles.

    Acceptance and evaluation criteria

    Acceptance criteria describe minimal set of requirements to be met for a solution to be worth implementing, also known as Must Have requirements. Typically used when evaluation only one possible solution and is expressed as pass or fail. Must be testable.

    Metrics and key performance indicators (KPIs)

    Measure performance of solutions, solution components and other matters of interest to stakeholders. A metric is a quantifiable level of an indicator to measure progress. A target metric is objective to be reached within a specified period.

    Process analysis

    Analyzes processes for their effectiveness, efficiency, and identifies improvement opportunities.

    Root cause analysis

    Identify and evaluate underlying causes of a problem, looking into causes occurring due to people, physical or organizational effects.

    Vendor assessment

    Assess ability of a potential vendor to meet commitments wrt delivery and consistent provision of a product or service.

    Data mining

    Finds useful patterns and insights from large amounts of data, usually resulting in mathematical models. Utilized in either supervised (user poses a question) or unsupervised (pure pattern discovery) investigations.

    MOST

    Most is a short form of Mission, Objectives, Strategies. It allows business analysts to perform thorough internal analysis of what is the aim of an organization to achieve and how to tackles such issues.

    PESTLE

    Pestle stands for (Political, Economic, Sociological, Technological, Legal, and Environmental). This model helps business analysts to evaluate all the external factors which can possibly impact their organization and determine how to address them.

    SWOT

    SWOT is a full form of Strengths, Weaknesses, Opportunities, and Threats. This technique helps we to find areas of both strength and weakness. It also allows for the proper allocation of resources.

    MoSCoW

    Must or Should, Could or Would process is a long-form of MosCoW. This technique allows prioritization of requirements by presenting a framework in which every individual requirement should be evaluated relative to the others.

    CATWOE - Customers, Actors, Transformation Process, World View, Owner, and Environmental

     

    This technique helps us to recognize processes that may be affected by any action the business undertakes.

    The 5 Whys

    This technique is a backbone of both Six Sigma and business analysis techniques. It consists of leading questions that allow business analysts to single out the root cause of an issue by asking why such a situation arises.

    Six Thinking Hats

    This process helps us to consider alternate perspectives and ideas.

    Business analysis training

    Business analysis learning can be expedited by undergoing a formal training.

    Many colleges, universities, professional training institutes provide structured training on business analysis.

    Adaptive US provides both theory training through it's Entry Certificate in Business Analysis training and skill training through it's Inner Circle program.

    Business Analysis Vocabulary

    A

    Absolute reference

    Unique identifier of a requirement to be maintained even if requirement is moved, changed or deleted.

    Acceptance criteria

    Minimal set of requirements to be met for a particular solution to be acceptable to stakeholders.

    Active/visible observation

    Observer observes the current process and takes notes, interacts with the user while work is being performed.

    Activity

    A unit of work performed.

    Activity diagram

    Diagram showing sequence of activities.

    Actor(s)

    Any person, system, or event that interacts with the system.

    Additional potential capabilities

    Capabilities offered by solution beyond those specified.

    Agile

    One type of software development life cycle.

    Allocation

    See requirements allocation.

    Analyst

    Stakeholder responsible for analysis.

    Approach

    High level plan to execute any task.

    Architecture

    Manner in which components of system are organized.

    Association

    Relationship between two elements or objects in a diagram, such as between classes and use cases.

    Atomic level

    At lowest level

    Attribute

    Defines information associated with a concept.

    Auditory learners

    Stakeholders who learn best through oral communication.

    B

    BA

    Business analyst / Business analysis

    Baseline

    A point-in-time view of requirements which have been reviewed and agreed upon. Serves as the basis for further development.

    Benchmarking

    Comparing a process or application's cost, time, quality, or other metrics to those of best in class process or applications to identify opportunities for improvement.

    BI

    Business intelligence - Analyzing business data to draw inferences.

    Black box tests

    Tests conducted using expected inputs and outputs.

    BPR

    Business process re-engineering - To modify business processes from scratch.

    Brainstorming

    Process for generating creative ideas and solutions through intensive and freewheeling group discussion.

    Business constraints

    Business limitations placed on the solution design such as schedule, budget etc.

    D

    Data dictionaries or glossaries

    Identify and define critical terms used by the organization or organizational unit.

    Data entity

    Group of related information to be stored in the system.

    Data flow

    Describes how data movement between a data process and an external entity, a data store or another data process.

    Data flow diagram (DFD)

    Diagrams data processes. See data flow.

    Data model

    Diagram depicting logical structure of data, independent of the data design or storage mechanisms.

    Data process

    A process that transforms the data in some way, either combining, reordering, converting, filtering etc.

    Decision analysis

    Decision-making approach modeling possible consequences of different decisions under conditions of uncertainty.

    Decision tables

    Tables expressing complex business rules or logic concisely in an easy-to-read tabular format, specifying all of the possible conditions and decisions.

    Decision tree

    A graphical representation illustrating conditions and outcomes.

    Deep structure

    Actual needs of the stakeholder.

    Defect

    Deficiency in a product or service reducing quality.

    Deliverable

    Any work product or service that stakeholder has agreed to deliver.

    Dependencies

    Activities that have to be completed before subsequent tasks can begin.

    Design constraints

    Constraints placed on solution design.

    Detailed logical data models

    Describe complete descriptions of all entities, attributes and relationships.

    Developer

    Stakeholders responsible for the construction of software applications.

    DFD

    See Data flow diagram.

    Dialog hierarchy

    Diagram showing user interface dialogs arranged as hierarchies.

    Dialog map

    Diagram showing architecture of the system’s UIs.

    Discovery session

    See requirements workshop.

    Dispersed stakeholders

    Stakeholders located in different geographic regions or countries.

    Document analysis

    Analysis of existing documentation and documentation of competing products.

    E

    Elicitation

    Elicitation involves understanding underlying needs from stated requirements of stakeholders. It also involves eliciting all necessary information for successful development of a system from all identified sources.

    Elicitation workshop

    See requirements workshop.

    End user

    A person or system that interacts with the solution.

    Entity-relationship diagram

    Graphical representation of entities relevant to a chosen problem domain, their attributes and relationships between them.

    Event

    Something that occurs to which an organizational unit, system, or process must respond.

    Event-based elicitation

    Techniques that require in person interactions, such as brainstorming, focus group, interview, observation, prototyping, requirements workshop.

    Event response table

    A table defining events and their responses.

    Evolutionary / functional prototype

    A prototype that becomes the product.

    Exploratory prototype

    Prototype developed to explore requirements.

    Extend use case

    Extends additional behavior into a use case.

    External interfaces

    Interfaces with other systems (hardware, software and human) that a proposed system will interact with.

    F

    Facilitation

    Skill of moderating discussions among a group.

    Flow chart

    A diagrammatic representation of activity or logic.

    Focus group

    Means to elicit ideas, attitudes and improvements about a specific product, service or opportunity in an interactive group environment.

    Force field analysis

    A diagram depicting forces supporting and opposing a change.

    FP

    Function point – A method to compute software size based on the functionality provided by the software.

    FS

    Functional specifications.

    Functional requirements

    Product capabilities or features.

    H

    Heterogeneous

    A group with diverse participants.

    High-level logical data models

    Focusing on describing important entities, attributes and relationships.

    Horizontal prototype

    A prototype that shows a shallow and wide view of the system’s functionality. Does not support any actual interaction.

    I

    Impact analysis

    Assessing effects of a proposed change on stakeholders, project, or system.

    Implementation subject matter expert (SME)

    Stakeholders responsible for designing, developing and implementing requirements.

    Incremental delivery

    Creating working software in multiple releases.

    Industry

    Various categories of businesses in economy, for example, retail, telecom, aviation etc.

    Initiative

    Effort undertaken with a defined goal or objective.

    Inspection

    Formal peer review utilizing a predefined and documented process, specific participant roles, captures defects and process metrics. Also see Structured walkthrough.

    Interface

    A shared boundary between any two entities (persons and/or systems).

    Interview

    Elicit information from stakeholders by asking relevant questions.

    Iteration

    A set period of time in which a solution is progressively built.

    Iterative

    One methodology for software development life cycle where working software is created in multiple releases.

    JAD (Joint application design)

    A session where client and solution team discuss requirements together. See requirements workshops.

    J

    JAD (Joint application design)

    A session where client and solution team discuss requirements together. See requirements workshops.

    K

     

    Key Performance Indicators (KPI)

    KPIs measure progress towards a strategic goal or objective.

    L

    Lessons learned process

    Learn about and improve a process or project. Also called Sprint retrospective in agile process.

    Logical order

    Order of priority/significance, for example, general questions to specific questions, start to finish, summary to, etc.

    M

    Matrix documentation (model)

    Captures a set of requirements having a complex but uniform structure in tabular form.

    Metadata

    Data about data.

    Methodology

    Proven approach.

    Metric

    Quantifiable level of an indicator at a specific point in time.

    Milestones

    Represent significant events in the progress of a project.

    Mock-up

    Synonym for proto-type.

    Monitoring

    Continuous process of collecting data to determine if the solution is performing in real world scenario. See also metric and indicator.

    MoSCoW

    MoSCoW categorizes requirements into, Must Have, Should Have, Could Have and Wont Have.

    Multiplicity

    See Cardinality.

    N

    Natural language

    Expressed in spoken language

    Nominalization

    Converting a long-lasting activity or group of nouns into a single event or noun.

    Non-Functional requirements (NFR) aka Quality or Supplementary requirements

    Conditions under which the solution must remain effective.

    O

    Object oriented modeling

    A software engineering approach where software is comprised of objects.

    Observation

    Eliciting requirements by observing stakeholder’s work environment.

    On-going requirements

    Requirements required to be maintained on an ongoing basis.

    OO

    Object oriented - An approach to design systems with real-world concepts.

    OOAD

    Object oriented analysis and design.

    Open-ended question

    Respondent is free to answer questions as he/she wishes.

    Operational support

    Stakeholders who provide support, such as trainers, help desk, network and other technical support personnel.

    Operative rules

    Rules intended to guide actions of stakeholders.

    Optionality

    Defines whether there is a mandatory relationship between entities in a data model.

    Oral communication skills

    Verbally express ideas, and information.

    Organizational change management professionals

    Stakeholders responsible for facilitating adoption of new solutions and overcoming resistance to change.

    Organizational process assets

    Methods, policies and processes and artifacts created by the organization from past experiences and best practices.

    P

    Passive/invisible observation

    Observer observes users working but does not interact with them.

    PDCA

    Plan-Do-Check-Act, four phase approach to complete any activity. Also known as Deming cycle or Shewhart's cycle.

    Peer review

    Stakeholders evaluate a work product to discover errors in order to improve its quality.

    Personal organization

    Ability to quickly find information, timeliness, management of outstanding tasks and appropriate handling of priorities.

    Physical data models

    Description of how data is stored and managed in a system.

    Plan-driven

    Approaches focusing on up-front minimizing uncertainty and fully defining solution before implementation begins.

    Plan-driven methodology

    Methodologies emphasizing planning and formal documentation.

    POC

    Proof of concept - Activities carried out to check technical feasibility of an initiative.

    POLDAT

    Process, Organization, Location (Business architecture), Data, Applications, Technology (Systems Architecture)

    Post-conditions

    Aspect to be true when the use case is complete.

    Preconditions

    Aspect to be true before the use case begins.

    Preventive and corrective action

    See CAPA.

    Primary actor

    Actor who initiates the use case.

    Primary or basic flow

    Simplest way to accomplish the goal of the use case.

    Prioritization

    Determining relative importance among a set of items.

    Process map

    Model that shows a process.

    Product

    A solution or its component.

    Product backlog

    A set of user stories, features or requirements identified for potential implementation, prioritized and estimated.

    Product scope

    Features and functions that characterize a product.

    Project

    A temporary endeavor undertaken to create a unique product or service.

    Project charter

    A document that formally authorizes the existence of a project.

    Project manager

    Stakeholder to manage work required to achieve the project objectives.

    Project scope

    Work to be performed to deliver a project. See also scope.

    Q

    QA

    Quality assurance – Activities carried out to ensure that the designed process will deliver quality products and services.

    QC

    Quality control - Activities carried out to ensure the defective products are not delivered to customers.

    QMS

    Quality Management System.

    Quality

    Degree to which a set of inherent characteristics fulfils requirements.

    Quality assurance

    See QA.

    Quality attributes

    See Non-functional requirements.

    Questionnaire

    See survey.

    R

    RACI (Responsibility-Accountability-Consulted-Informed) matrix

    Describes stakeholders / roles for a given task or deliverable.

    Recorder

    Alias scribe

    Regression testing

    Checking if the existing functionalities are affected due to introduction of new functionalities.

    Regulator

    Stakeholder with legal or governance authority.

    Release planning

    Deciding requirements to be included in different releases.

    Repository

    A real or virtual facility where information is stored.

    Request for information (RFI)

    Document issued to obtain supplier input on a proposed process or product.

    Request for proposal (RFP)

    Requirements document issued when seeking a formal proposal from suppliers.

    Request for quote (RFQ)

    RFQs are used when the organization understands solution options available and is seeking suppliers to implement an option.

    Requirement attributes

    Metadata related to requirements used for requirements management.

    Requirement defects

    Errors in requirements caused by incorrect, incomplete, missing, or conflicting requirements.

    Requirements allocation

    Apportioning requirements to subsystems and components (i.e., stakeholders, hardware and software).

    Requirements coverage

    Tracing business objectives to detailed requirements such as business rules, data elements and use cases.

    Requirements discovery session

    See requirements workshop.

    Requirements document

    See requirements package.

    Business Analyst, aka requirements analyst

    A practitioner of IT Business Analysis.

    IT Business Analysis

    Systematic and disciplined approach to identify, specify and manage requirements.

    Business Analysis approach

    Overall process to be followed to perform IT Business Analysis work.

    IT Business Analysis communication plan

    Types of communication that Business Analysts perform.

    IT Business Analysis performance assessment

    Using prior experiences to determine effort involved in performing IT Business Analysis work.

    IT Business Analysis plan

    Includes information such as scope, work breakdown structure, activity list and estimates for each activity and task.

    Requirements iteration

    An iteration defining requirements for a subset of the solution scope.

    Requirements management

    Activities that control requirements development, including requirements change control, attributes definition and traceability.

    Requirements management plan

    Describes approach to be taken to structure traceability, definition of requirements attributes, requirements prioritization and change process.

    Requirements management tool

    Software tool that stores requirements information in a database, captures attributes and associations and facilitates reporting.

    Requirements model

    Representation of requirements using text and diagrams.

    Requirements package

    Requirements documents created for sharing with specific audience.

    Requirements quality

    See requirements verification.

    Requirements repository

    See repository.

    Requirements risk mitigation strategy

    Identify, prioritize and mitigate requirements-related risks.

    Requirements signoff

    Formal approval of a set of requirements.

    Requirements trace matrix

    A matrix tracking requirements’ relationships to other requirements and other deliverables.

    Requirements traceability

    Linking requirements to business objectives, other solution components and other requirements.

    Requirements validation

    Ensuring requirements are aligned to the goals and objectives of the business.

    Requirements verification

    Ensuring requirements are at an acceptable level of quality.

    Requirements workshop

    A structured meeting in which selected stakeholders define requirements.

    Retrospective

    See lessons learned process.

    Return on investment

    A measure of the profitability of a project or investment.

    S

    Scenario

    Series of actions to achieve a goal.

    Scope

    Area covered by a particular activity or topic of interest. See also project scope and solution scope.

    Scope model

    A model that defines scope boundaries.

    SDLC

    Software Development Life Cycle.

    Secondary actor

    An actor who participates in a use case but does not initiate the same.

    Service

    Work carried out or on behalf of others.

    Signoff

    See requirements signoff.

    Software engineers

    Stakeholders responsible for construction of software applications.

    Software/systems requirements specification

    Requirements document describing detailed functional and non-functional requirements.

    Solution requirement

    Requirements described to develop a solution that meets the business and stakeholder requirements.

    Solution scope

    Set of capabilities a solution must deliver to meet business need.

    Span of control

    Number of employees a manger is responsible for.

    Sponsor

    Stakeholder who pays for the project.

    Stability

    Indicates how mature the requirement is.

    Stakeholder

    A group or person who may be affected by an initiative or has influence over it.

    Stakeholder analysis

    To identify, prioritize, assess interests and likely participation of stakeholders for an initiative.

    Stakeholder list, roles and responsibilities

    List of stakeholders affected by a business need or proposed solution and their participation.

    Stakeholder maps

    Visual diagrams that depict relationship of stakeholders to the solution, their authorities and interests.

    Stakeholder requirements

    Statements of needs of a particular stakeholder or class of stakeholders.

    State machine diagram, State transition diagram

    See state diagram.

    Stated requirements

    Requirement described by stakeholders.

    Status attribute

    Indicates requirement status.

    Structured walkthrough

    A session where invited participants review a set of requirements/deliverables.

    Subject matter expert (SME)

    Stakeholder with specific expertise in any aspect of problem domain or potential solutions.

    Surface structure

    Requirement stated by the stakeholder

    Survey

    Administering a set of written questions to stakeholders to collect responses.

    Swim lane

    Horizontal or vertical section of a process model showing activities are performed by a particular role.

    T

    Technical constraint

    Limitations on design of a solution based on technology used.

    Throw-away prototype

    A prototype used to quickly uncover and clarify interface requirements using simple tools and which is not used in final product.

    Time box

    A fixed period of time assigned for a purpose.

    Tracing

    Act of linking requirements among them and also to other deliverables.

    U

    UCP

    Use case point – A method to compute software size using use cases.

    Unified modeling language (UML)

    A non-proprietary modeling language used to specify, visualize and document requirements and designs for object-oriented software systems.

    Universal quantifiers

    Universal quantifiers group set of objects and generalize behavior or property for the group such as All, None etc..

    Urgency

    Indicates how soon the requirement is needed necessary.

    Use case diagram

    A diagram showing actors and use cases for a system.

    Use case (UC) specifications

    Describes the tasks that the actors and system will perform for achieving a goal.

    User

    See end user.

    User acceptance test

    Testing carried out users to judge whether the delivered system is acceptable.

    User requirement

    See stakeholder requirements.

    User requirements document

    A requirements document prepared for a user audience.

    User story

    A short description of a solution capability described from a stakeholder perspective.

    V

    Validated requirements

    Requirements that demonstrate delivery of business value.

    Validation

    Ensuring product or service satisfies its intended use.

    Variance analysis

    Analysis of differences between planned and actual performance parameters.

    Verification

    Ensuring deliverables produced at a given stage of development satisfies the conditions or specifications of the previous stage.

    Verified requirements

    Requirements that demonstrate characteristics of requirements quality.

    Vertical prototype

    A prototype that dives into the details of the interface, functionality, or both.

    W

    Walkthrough

    A review where participants present, discuss and go through a work product to find errors and verify correctness of requirements

    Waterfall

    Software development methodology where activities move from one phase to another.

    Wire-frame

    Synonym for proto-type.

    Work breakdown structure (WBS) A deliverable-oriented hierarchical decomposition of the work to be executed to accomplish the project objectives.

    Work packages

    Include at least one and usually many activities, which can be further broken into smaller tasks.

    Work product

    Document or collection of notes or diagrams created during the IT Business Analysis process.

    Detailed Description of BA Processes

    Plan IT Business Analysis

    4.1 Key Concepts

    Plan IT Business Analysis knowledge area focuses on having right planning for IT Business Analysis. It describes following tasks:

    • Plan for understanding requirements context

    • Understand and document requirements context

    • Define system boundary and solution scope

    • Identify requirement sources

    • Identify and prioritize stakeholders

    • Determine Business Analysis approach

    • Plan for requirements communication

    • Identify IT Business Analysis risks and assumptions

    • Estimate schedule, effort and cost

    • Develop IT BA plan

    A good planning ensures that Business Analyst has identified all requirements sources and resources needed for IT Business Analysis. This goes a long way in ensuring quality of requirements gathered.

    4.1.1 Understanding context

    Dictionary definitions of word “Context”.

    Webster-Mariam dictionary

    • The words that are used with a certain word or phrase and that help to explain its meaning.

    • The situation in which something happens: the group of conditions that exist where and when something happens.

    Cambridge dictionary

    • The influences and events related to a particular event or situation.

    Oxford dictionary

    • The circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood.

    So, we can conclude context is the prevailing situation that affects or helps to understand requirements.

    Typical elements of the context are:

    • People (stakeholders),

    • Systems in operation (interfacing systems),

    • Processes,

    • Events,

    • Documents (e.g., laws, standards, system documentation).

    Requirements originate within a certain context. Stakeholders, relevant standards, and legal authorities demand specific functionalities from the system to be developed. Requirements can ONLY be interpreted correctly in regard to the specific context. Better understanding of the context lowers the likelihood of incorrect interpretations. Business Analysts MUST document the context correctly and completely.

    Very first thing Business Analysts should do is to plan for understanding the context. As part of the plan, plan for studying existing documentation and meet key stakeholders. Use case diagrams and data flow diagrams are often used to document system context.

    System boundary

    System boundary demarcates aspects to be developed from its environment. It separates the aspects of the environment that can be modified from aspects of the environment that cannot be modified by the development process. Aspects within the system boundary can be business processes, technical processes, people and roles, organizational structures and components of the IT infrastructure.

    Sources and sinks

    Sources and sinks can be used to identify system’s interfaces with its environment. Sources provide inputs for the system. Sinks receive outputs from the system. Possible sources and sinks of a system are:

    • Stakeholders of existing systems,

    • Other systems (applications and hardware).

    Sources and sinks interact with the system via system interfaces. Using system interfaces, the system provides functionalities to the environment, monitors the environment, and influences parameters of the environment. Depending on the type of source or sink, system needs different interface types:

    1. Human-machine interface, also known as user interface,

    2. Hardware interface,

    3. Software or application interface.

    [Rupp, Klaus Pohl and Chris 2015]

    4.1.2 Requirements sources

    Significance of requirements sources

    Requirements are the foundation of solution development, hence it is essential to identify all requirements sources.

    Identifying relevant stakeholders, interfacing systems and relevant documents is a key task for Business Analysts. Gather, document and consolidate goals and requirements from different sources.

    Consequences of unconsidered sources

    Not identifying or not considering stakeholders, documents and interfacing results in significant re-work, possibly leading to failure of the project. Unconsidered sources will create large number of change requests during system acceptance and operation. As we learnt earlier, not implementing requirements at appropriate time leads to significant re-work and hence high additional costs.

    Types of requirements sources

    Key requirements sources are:

    Stakeholders

    Stakeholders are those people or organizations who affect requirements. They may provide or implement requirements. Stakeholders are the most important sources of requirements, hence not considering is bound to result in incomplete requirements.

    Typical IT Business Analysis stakeholders are: Sponsor, Project managers, Domain SMEs, Implementation SMEs, Testers, End users, Administrators, Management, Application owners, and Legal entities, and institutions etc. There could be undesired stakeholders as well, such as hackers and users with fraudulent intents.

    Documents

    Documents are also another significant source for requirements. Documents may be:

    • Provided by statutory and regulatory bodies.

    • Standards prescribed by industry bodies and standard setting organizations such as ISO.

    • Requirements documents of existing systems.

    • Feature documents of competing systems.

    • Error reports of existing systems.

    • Complaints and feedbacks on existing systems.

    Systems

    Since most applications need to interact with other applications, interface requirements are needed for most applications. Similarly, Business Analysts can get insights into requirements from competing systems available in the market.

    • Existing or predecessor systems

    • Other interfacing systems.

    • Competing solutions.

    Important information of the stakeholder documentation
    Stakeholders can be classified as internal or external.

    Internal stakeholders are within the organization: e.g. employees and management. External stakeholders are outside the organization: e.g. government and trade associations etc.

    Stakeholders can also be classified as Primary, Secondary and key stakeholders

    Primary stakeholders are directly affected by the system such as end-users, management etc. Secondary stakeholders are indirectly affected, e.g. government and media. Key stakeholders are the ones who are most significantly affected or those with maximum influence.

    4.1.3 Stakeholder management

    Identifying relevant stakeholders is a key task of Business Analysts. Identify stakeholders and determine the impact of proposed changes on them to determine the needs, wants, and expectations to be satisfied by a solution. Some individuals may play a variety of roles in the same project, and different roles in different projects. Early identification of stakeholders helps in timely delivery of requirements deliverables. Stakeholders are the MOST important source of requirements. Business Analysts gather, document, and consolidate conflicting goals and requirements of different stakeholders.

    Not considering stakeholders (could be due to non-identification) will result in significant negative impact for the project progress. Significant change requests can result during system operation as critical requirements may remain undetected. Modifying the system late causes high additional costs. Hence it is critical to identify all stakeholders in the beginning itself. Change-driven approaches better accommodate this risk, but cannot eliminate it.

    Another technique for stakeholder identification is maintaining stakeholders’ checklist. This allows planned elicitation from relevant stakeholders. If the stakeholder list is not updated at right time or incomplete, the result may be that some stakeholders are missed from elicitation.

    Stakeholder elicitation often begins with suggestions of relevant stakeholders made by management or by domain experts.

    Enterprise architecture describes organizational units in the enterprise, their interactions with each other, customers, and suppliers, responsibilities within the organization, and roles, and relationships within each organizational unit.

    Project manager, and Business Analyst share the responsibilities of stakeholder identification and management. Project manager is accountable for project team meeting commitments made to stakeholders, assignment of stakeholders to project tasks, their involvement in project execution, ensuring project scope is managed.

    Business Analysts assist Project managers in defining which project team members and stakeholders should be involved in developing, reviewing or approving IT Business Analysis deliverables.

    Stakeholder management process

    Advantages
    • Ensures no stakeholders have been left out.

    • Involving stakeholders can build trust.

    Disadvantages
    • May add non-critical stakeholders to the project leading to additional requirements, cost and schedule.

    Ensuring agreement with stakeholders

    It is essential that all stakeholders agree to a common requirement for the system to be developed. Hence Business Analysts along with stakeholders should define a protocol to work. A stakeholder charter is a great tool to do so. The agreement process can be verbal or written. A sample stakeholder charter can be:

    • All stakeholders will deal with all stakeholders in a dignified professional manner, treat each other with civility and respect

    • To carry out activities as per project scope

    • All stakeholders agree to listen and be open to the diverse points of view expressed by other participants

    • Needs beyond project scope can be discussed and agreed by Steering committee

    • Respect time of each stakeholder

    • All stakeholders agree to provide other stakeholders the level of commitment and support expected in terms of time and effort minimum 2 weeks in advance

    • As an effective team, all stakeholders agree that the issues will be judged on the merit of the issues only

    • All stakeholders will co-operate and support each other to make the project a success

    • All stakeholders shall raise any concerns about the project or the process with an open and timely manner

    • All stakeholders agree to attend all review meetings,

    • In case they are unable to attend, nominate a representative

    • All stakeholders agree to provide approval / objection to the requests within 1 week

    • Meeting if need to be re-scheduled, should be done at least 3 days in advance

    • To save time on travel, stakeholders can participate calls through tele-conferencing means

    Usually many stakeholders are involved in large projects. Due to limited resources, Business Analysts MUST carefully select stakeholders MOST suitable for IT Business Analysis. Principles in dealing with stakeholders are:

    Comprehensive identification

    Comprehensive identification ensures no stakeholders are left out from the IT Business Analysis process.

    Constant prioritization

    Since stakeholders are not static, it is essential for Business Analysts to keep the stakeholder register updated and prioritized.

    Continuous involvement and constant communication

    Continuous involvement and periodic communication with stakeholders help in better collaboration. Address stakeholder grievances.

    Collaborative (Win-win) mindset

    Business Analysts and project managers need to convince stakeholders regarding project benefits.

    Defined protocol for engagement

    To avoid misunderstandings and disputes, Business Analysts should develop formal communication and approval mechanism. This should include deliverables, tasks, roles, responsibilities and approval authorities. Also determine communication paths and feedback loops for stakeholders. Organizations differ greatly on formality on approvals, which could be ranging from being verbal to ink signature sign-off.

    [Rupp, Klaus Pohl and Chris 2015]

     

    4.1.4 Principles in dealing with stakeholders Stakeholder’s rights & duties

    Stakeholders play vital role in IT Business Analysis process. They have deep understanding of the domain and its processes. Stakeholders’ responsibilities include:

    • Provide requirements,

    • Prioritize and rank requirements,

    • Review documented requirements,

    • Accept requirements trade-offs,

    • Approve requirements,

    • Assist Business Analysts in understanding domains and application,

    • Communicate requirements promptly,

    • Adhere to defined requirements development and change processes.

    4.1.5 Business Analysis approaches

    In software development, Business Analysis approaches range from Waterfall (plan-driven) to Agile (change-driven) approach, proprietary in- house methodologies, customs, and practices.

     

    Attribute

    Plan driven

    Change driven

    Focus

    To detail as much as possible in the beginning to maximize control, and reduce risk.

    To discover on the go.

    Authority to approve

    Sponsor.

    Designated person.

    Applicable situation

    Complex, high cost of failure, well drafted requirements possible, challenging stakeholder interactions.

    Low cost of failure, requirements amorphous.

    Model

    Water-fall.

    Agile / Iterative.

    Level of detail

    High.

    Low.

    Change management

    Formal process through standardized template. Accept change only when justified.

    Through prioritized product backlog, time box driven.

    Communication

    Formal. Documented. Periodic.

    Informal. Verbal. Frequent.

    Documentation

    Prior to implementation.

    Post implementation.

    Emphasis on requirements priotization

    Low

    High

    Source: BABoK

    Business Analysts can combine elements from different approaches. Organizational process assets are typically known as Quality Management System in many organizations. Organizational process needs, and objectives include:

    • Compatibility with other organizational processes.

    • Constraints on time-to-market.

    • Compliance with regulatory, and governance frameworks.

    • Desire to evaluate new approaches to solution development.

    • Other business objectives.

    Organizations usually have formal or informal standards regarding how to conduct IT Business Analysis, and how it fits into project, and other activities. Review existing organizational standards, guidelines, and processes relating to the initiative. These may suggest or mandate Business Analysis approach. Even if a standard approach exists, tailor it to the needs of a specific initiative. Organizational standards govern tailoring of IT Business Analysis processes, specifying permitted approaches, elements that can be tailored, and guidelines for selecting an approach.

    If no standards exist, work with appropriate stakeholders to determine the Business Analysis approach. Business Analysis approach often follows project approach but can also be independent. For example, project may follow an iterative approach but Business Analysis approach can be waterfall.

    Especially, collect non-functional requirements in water-fall approach as changing non-functional requirements will be very difficult once the product is designed and built.

    4.1.6 Plan for requirements communication

    Determine how best to receive, distribute, access, update and escalate information from project stakeholders and how best to communicate with them. Requirements can be presented in any format, as long they as are understandable for the reviewer. This task decides formats appropriate for a particular initiative, and its stakeholders. Requirements must be clear, concise, accurate, and at appropriate level of detail.

    Typically, IT Business Analysis communication plan is integrated into overall project communications plan. On small projects, it may be very brief, and may not be formally documented. On projects with many stakeholders, it may be a separate document or at least an essential part of the overall project communications plan.

    4.2 Activities

    4.2.1 Plan for understanding requirements context

    Purpose: To plan for understanding requirements context from the sponsor and key stakeholders.

    Stakeholders: Sponsor*, Domain SME*, Project Manager*.

    Inputs

    Elements

    Outputs

    1.Enterprise architecture

    2.Business needs

    1.Plan for understanding requirements context.

    2.Get system and application landscape.

    3.Estimate effort needed for understanding requirements context.

    1.Plan to understand requirements context

    2.System and application landscape

    Tools and Techniques: IT Business Analysis plan.

     

    Example:

    Stakeholder Name

    Desig.

    Key Topics for Discussion

    Target Date

    Est. effort

    Technique

    Status

    Dave Richards

    CEO

    KPIs and Dashboards.

    10-Feb

    8

    Interview

    Completed

    Mike Dent

    CDO

    Non-functional business requirements

    10-Feb

    8

    Interview

    Completed

     

     

    Project monitoring business requirements

    10-Feb

     

    Interview

    Completed

     

     

    Operational Dashboards.

    10-Feb

     

    Interview

    Completed

    Dinesh Pandey

    Head-PMO

    Process compliance business requirements.

    12-Feb

    4

    Interview

    Completed

    Lee Fung

    Head-IT

    IT standards

    12-Feb

    4

    Interview

    Completed

     

     

    Expectations from GRC system

    12-Feb

     

    Interview

    Completed

    Adi Gururaj

    Head-HR

    Expectations from GRC system

    14-Feb

    4

    Interview

    Completed

    Iqbal Mohammed

    Head-Administration

    Expectations from GRC system

    14-Feb

    4

    Interview

    Completed

     

    4.2.2  Understand and document requirements context

    Purpose: To understand and document requirements context for guiding the IT Business Analysis activities.

    Stakeholders: Sponsor*, Domain SME*, End users*, Customers*.

    Inputs

    Elements

    Outputs

    1.Plan to understand requirements context

    2.System and application landscape

    1.Discuss project vision with sponsor, domain SME and Project manager.

    2.  Understand the rationale behind the new / improved system.

    3. Understand current and likely future needs of the organization.

    4. Define requirements context.

    1.Business objectives / opportunities

    2.Current system challenges

    3.Requirements context

    4. Objectives of new / improved system

    5.Interfacing requirements

    Tools and Techniques: Interviews, Document analysis, Context diagram

     

    Example:

     

    4.2.3 Define system boundary and solution scope

    Purpose: To define system boundary and solution scope.

    Stakeholders: Sponsor*, Domain SME*, End users*, Customers*.

    Inputs

    Elements

    Outputs

    1. Plan to understand requirements context

    2. System and application landscape

    3. Requirements context

    4. Objectives of new / improved system

    1. Define requirements context

    2. Define system boundary

    3. Define solution scope

     

    1. System boundary

    2. Solution scope

    Tools and Techniques: Interviews, Document analysis, Context diagram, Requirements management plan.

     

    Example

    In Scope

    Req ID

    Requirement

    Req Type

    Criticality

    User Contact

    10000

    Project and program dashboard

    Functional

    Must Have

    Dinesh Pandey

    20000

    Manage schedule

    Functional

    Must Have

    Lily Vasantini

    30000

    Manage defect

    Functional

    Must Have

    Shalini Paul

    40000

    Manage risk

    Functional

    Must Have

    Sara Lee

    50000

    Manage requirements

    Functional

    Must Have

    Nori Masa

    60000

    Track effort

    Functional

    Must Have

    Gajendra Battalla

    70000

    Manage audit and compliance

    Functional

    Must Have

    Rebecca Randad

     

     

    Out of Scope

    Req ID

    Requirement

    Short Description

    Reason for exclusion

    Req Type

    90001

    Financial accounting

    Invoicing, collection

    Not aligned to product vision

    Functional

    90002

    Recruitment management

    Plan and track recruitment activities

    Not aligned to product vision

    Functional

    90003

    Task dependency management

    Similar to MS Project features

    Extremely complex feature

    Functional

    90004

    Critical path

    Similar to MS Project features

    Extremely complex feature

    Functional

     

     

    Purpose: Identify requirements sources and suitable elicitation techniques for the initiative which may be regulatory, contractual and implicit requirements.

    Stakeholders: Sponsor, Domain SMEs, Project manager, Regulator.

    Inputs

    Elements

    Outputs

    1. Business and system context

    2. Objectives of new / improved system.

    1. Identify sources of government regulations.

    2. Identify pertinent standards published by industry associations.

    3. Identify requirements fulfilled by current systems.

    4. Identify requirements fulfilled by competitors’ products.

    1. Identified requirements sources

    Tools and Techniques: Interviews, System context diagram, Organization chart, Process models, Brainstorming.

     

    4.2.4 Identify requirements sources & suitable elicitation techniques

    Purpose: Identify requirements sources and suitable elicitation techniques for the initiative which may be regulatory, contractual and implicit requirements.

    Stakeholders: Sponsor, Domain SMEs, Project manager, Regulator.

    Inputs

    Elements

    Outputs

    3. Business and system context

    4. Objectives of new / improved system.

    5. Identify sources of government regulations.

    6. Identify pertinent standards published by industry associations.

    7. Identify requirements fulfilled by current systems.

    8. Identify requirements fulfilled by competitors’ products.

    2. Identified requirements sources

    Tools and Techniques: Interviews, System context diagram, Organization chart, Process models, Brainstorming.

     

    Example:

    Type of requirements

    Sources

    Elicitation techniques

    Modeling techniques

    Non-functional requirements

    Sponsor, Delivery managers

    Interview

    Non-functional requirements

    Process, data and UI requirements

    Delivery managers
    Project managers
    PMO Office

    Workshops

    Prototype, Activity diagram, State chart diagram

    Interfacing requirements

    System owners for Oracle Apps and Attendance System

    Interview

    Interface mapping template

    Legal requirements

    Finance

    Interview

    Business rules template

    Business rules

    Delivery managers
    Project managers
    PMO Office

    Document analysis, Interview and Workshop

    Business rules template

    Reporting requirements

    Delivery managers
    Project managers
    PMO Office

    Interview

    Reporting requirements template

    Implicit requirements

    Competitor systems

    Benchmarking

    Benchmarking template

     

    4.2.5 Identify and prioritize stakeholders

    Purpose: Identify stakeholders affected by a proposed initiative, determine their influences, and approval authority for project deliverables.

    Stakeholders: Sponsor*, Regulator*, Domain SME*, Project Manager*, and End Users*.

    Inputs

    Elements

    Outputs

    1. Business need

    2. Enterprise architecture

    3. Requirements context

    4. Stakeholder checklist

    1. Identify stakeholders.

    2. Determine their influences and interests.

    3. Prioritize stakeholders.

    1. Stakeholder list, roles, and responsibilities

    [Note: Describes which stakeholder is responsible, accountable, consulted, and informed for IT Business Analysis deliverables ]

    Tools and Techniques: BrainstormingInterviews, Organization model, Process model, Scope models.

     

    Example:

    Name of Stakeholder or Group

    Desig.

    Authority Level

    Inf.

    Int.

    Cri.

    Key Expectations / Special Needs

    Dave Richards

    CEO

    High

    5

    4

    High

    Project to be delivered within accepted budget and time.

    Mike Dent

    CDO

    High

    5

    5

    High

    Have a unified view/process implemented across the business divisions of ABCT.

    Dinesh Pandey

    Head-Quality and PMO

    High

    2

    5

    Medium

    Carefully gather business requirements and evaluate work pending vs. work done.

    Jan Lesher

    Project Manager

    High

    3

    5

    Medium

    Plan and track GRC project working closely with key stakeholders.

    Lee Fung

    Head-IT

    High

    4

    4

    High

    New project must fit into organizational IT policies and strategies.

     

    4.2.6 Determine Business Analysis approach

    Purpose: To select correct Business Analysis approach based on project context and stakeholder needs.

    Stakeholders: Sponsor*, Customer*, Domain SME*, Project manager*, End user, Supplier, Implementation SME, Tester, and Regulator.

    Inputs

    Elements

    Outputs

    1. Business need

    2. Requirements context

    3. Organizational process needs, and objectives

    4. Organizational process assets.

    1. Consult key stakeholders on selecting the Business Analysis approach.

    2. Decide Business Analysis approach based on timing of IT Business Analysis work, formality, and level of detail required for IT Business Analysis deliverables.

     

    1. Business Analysis approach

    Tools and Techniques: Brainstorming, Expert judgment.

     

     

     

    Example:

    Since the project approach is agile, Business Analysis approach will also be agile. This will allow the project team to deliver maximum possible value to stakeholders in shortest possible time.

     

    4.2.7 Plan for requirements communication

    Purpose: To plan for requirements communication based on stakeholder needs

    Stakeholders: Sponsor*, Domain SME*, Project Manager*, Customer*, Supplier, End user, Implementation SME, Operational support, Tester, Regulator.

    Inputs

    Elements

    Outputs

    1. Stakeholder list and expectations

    2. Organizational policies and processes

    3. Business Analysis approach

    1. Understand stakeholder needs.

    2. Consider geographic locations.

    3. Consider cultural diversity.

    4. Consider type of project.

    5. Determine communication frequency.

    6. Consider communication formality.

    7. Plan for requirements communication.

    1. Requirements communication plan

    Tools and Techniques: Brainstorming, Requirements management plan, Guidelines for requirements communications.

     

    Example:

    Frequency / Event

    Aspects to be reported

    Stakeholders to be communicated

    Template to be used

    Weekly

    RE progress

    Entire team

    WSR

    Monthly

    RE progress, Issues, Risks

    Steering committee

    MSR

     

     

    4.2.8 Identify IT Business Analysis risks, assumptions & mitigation actions

    Purpose: Ensure IT Business Analysis risks and assumptions are identified and suitable mitigation actions are designed.

    Stakeholders: Sponsor, Customer, Domain SME*, Project manager*.

    Inputs

    Elements

    Outputs

    1. Business Analysis approach

    2. RE activity plan

    3. Organizational risk database

    4. Past project experiences

    1. Identify sources of business IT Business Analysis risks.

    2. Identify business IT Business Analysis risks.

    3. Prioritize risks.

    4. Identify mitigation measures for critical risks.

    1. IT Business Analysis risks and mitigation plans

    Tools and Techniques: Risk management, Requirements management plan.

     

    Example:

    Risk description

    Probability

    Severity

    RPN

    Impact

    Mitigation Plan

    Domain SME availability

    Medium

    Critical

    9.00

    High

    Identify back-ups for all critical Domain SMEs.

    Increase in scope

    High

    Critical

    12.00

    High

    Discuss during steering committee meetings

    Stakeholders agreement on scope

    Very High

    Critical

    15.00

    High

    Sponsor to review efforts needed beyond 0.5 person-month to implement

    Completeness of requirements

    Medium

    Critical

    9.00

    High

    Prototypes to be approved by Domain SMEs

     

    4.2.9 Define constraints

    Purpose: To identify factors other than requirements affecting the viability of solutions.

    Stakeholders: All stakeholders, Implementation SME, and Project manager.

    Inputs

    Elements

    Outputs

    1. Business constraints

    2. Technical constraints

    1. Document business constraints.

    2. Document technical constraints.

    1. Constraints

    Tools and Techniques: Requirements templates.

     

    Example:

    No

    Category

    Constraint

    Remarks

    1

    Business

    Follow agile approach to development.

     

    2

    Business

    Budget limited to 2000K USD.

     

    3

    Business

    First go live within 6 months and subsequently every quarter.

     

    4

    Business

    Must adhere to ISMS policies.

     

    5

    Technical

    Must adhere to approved IT architecture.

    Documenting Requirements

    1.3 Requirements documentation

    Good requirements are foundations for successful projects. A good document design improves communication between stakeholders and increases quality of requirements. Requirement engineers MUST design appropriate documentation standard and adhere to the same. A requirements specification are collection of requirements, typically for a system or component.

    Reasons for documentation

    Requirements are basis of system development. Requirements influence all succeeding phases of project: analysis, design, implementation, test, acceptance and maintenance. Quality of requirements documentation has a strong impact on progress of the project and on its success.

    Key reasons for requirements documentation are:

    Communication vehicle among all stakeholders

    Requirements documents serve as the primary communication medium among stakeholders.

    Legal relevance

    Non-fulfilment of requirements can become a legal issue for the organization. Documenting requirements helps the organization during legal conflicts.

    Complexity

    Large systems have large number of requirements with complex interdependencies. Without proper requirements documentation, managing requirements will be near impossible task.

    Accessibility

    In a large and complex project, many stakeholders participate at different points in project life cycle.

    Requirements MUST be accessible to all stakeholders for the project and even after completion of the project.

    Sharing of knowledge

    Requirements documentation helps in sharing and maintaining organizational knowledge about processes and business rules.

    For future re-use

    Requirements documentation helps in requirements reuse. Requirements reuse saves significant effort and time for the organization. Requirements documents may also contain relevant information which are helpful for current and future projects.

    Use of requirements documents

    Over course of the project, requirements documents serve as basis for different tasks:

    Planning

    Requirements documents are used to develop concrete work packages and milestones for implementation of system requirements.

    Architectural design

    Requirements documents are used to develop detailed requirements (along with constraints) which serve as basis for design of system architecture.

    Implementation

    System is implemented by making use of architectural design and detailed requirements.

    Test

    Test cases can be developed from requirements to be used for system validation.

    Traceability management

    Requirements documents are also used for managing traceability between requirements and other associated documents.

    Change management

    When requirements change, requirements document can serve as basis to analyze extent to which other parts of system are impacted, thus helping in estimation of change effort.

    System usage and system maintenance

    Requirements document can be used to analyze defects and shortcomings those are discovered during system use. For example, one can decide if a defect is a result of incorrect usage, a defective requirement, or an implementation error.

    Contract management

    Requirements document is prime aspect of a contract between a client and a supplier in most cases. During any dispute, requirements documents serve as the basis for dispute resolution.

    1.4 Documentation types

    Requirements can be documented in 3 different ways: natural languages, conceptual models and hybrid approach.

           Requirements documentation using natural language

    Advantages of using natural language

    Most requirements originate as natural language text when stakeholders describe their needs. Text is natural to all stakeholders and no one needs to learn a new notation. Text can be used to express any kind of requirement and all 3 perspectives (Data – Logic – Behavior).

    Disadvantages of using natural language

    Natural language texts are prone to be ambiguous, leading to multiple interpretations. Requirements understandings can vary greatly depending on the stakeholder’s knowledge on the subject, their ability to express and understand. In natural language, it is also difficult to isolate information pertaining to a particular perspective, say data or behavior.

    Requirements documentation using conceptual models

    Advantages of conceptual models

    Conceptual models decrease ambiguity (i.e., fewer ways to interpret requirements) than natural language due to their notation formalities. They depict requirements in a concise manner. It is easier for a trained reader to understand conceptual model than natural language.

    Disadvantages of conceptual models

    Conceptual models require specific knowledge of modeling symbols and texts appropriate to the perspective (Data – Logic – Behavior).

    Hybrid requirements documents

    Hybrid requirements documents use both natural language and conceptual models, hence overcome dis-advantages of both text and conceptual models.

    Example of requirements structure:

    Requirement Type

    Description

    Attributes

    Stakeholder Request (STRQ)

    A request of any type—for example, Change Request, enhancement request, request for a requirement change, defect—from a stakeholder.

    Priority, Status, Cost, Difficulty, Stability, Assigned to

    Feature (FEAT)

    An externally observable service provided by the system which directly fulfills a stakeholder need.

    Priority, Status, Planned Iteration, Actual Iteration, Difficulty, Stability, Assigned to, Origin, Rationale, Cost, Enhancement Request, Defect

    Use Case (UC)

    A description of system behavior, in terms of sequences of actions. A use case should yield an observable result of value to an actor.

    Property, Affects Architecture, Planned Iteration, Actual Iteration, Assigned to, Rank, Test, Priority, Status, Difficulty, Stability, Cost, Enhancement Request, Defect

    Glossary Item (TERM)

    A term used in the project’s common vocabulary.

     

    Supplementary Requirement (SUPL)

    A description of a requirement not readily described by a Use Case.

    Priority, Status, Difficulty, Stability, assigned to, Cost, Enhancement Request, Defect, Test

    Basic rules to enhance readability of requirements

    1. Short sentences: Limiting requirements to 10 words per sentence is a good practice to follow.

    2. Short paragraphs: As human memory is limited, use 7 or less sentences in a paragraph.

    3. Formulate only one requirement per sentence: Avoid long, complicated interlaced sentences.

    4. Use business terminology: Use terminology used in business than using technical terms.

    5. Define and mandate glossary: Stakeholders interpret same terms differently which is a frequent cause for conflicts in IT Business Analysis. To avoid these conflicts, everyone involved in development process MUST share same understanding of terminologies used. Glossary MUST contain all relevant terms.

    6. Use active voice: Active voice is always better than passive voice.

    7. Use models and matrices where ever possible: Using models and matrices improves requirements clarity.

    • Quality criteria for requirements

    Quality criteria defined in IEEE standard can be used for individual requirements and requirements documents. In addition, few more quality criteria for individual requirements can be:

    Necessary

    Must be needed by stakeholders and MUST fulfill their needs.

    Feasible

    Requirements MUST be feasible given organizational, legal, technical, or financial constraints.

    Agreed

    All stakeholders agree to the requirement.

    Unambiguous (IEEE Std. 830)

    It MUST not be possible to interpret a requirement in different ways. All readers of requirement MUST arrive at same understanding of requirement. One example of ambiguous requirement:

    1. System shall calculate time taken to complete a service request as Date of completion of service request minus Date of arrival of service request. One stakeholder may interpret this as Calendar days (Elapsed days) where as another stakeholder may interpret as Number of working days elapsed between arrival and departure.

    2. The system shall have ability to support multiple browsers. Which all browsers?

    Consistent (IEEE Std. 830)

    Requirements MUST be consistent with other requirements, i.e., requirements MUST not contradict one another, irrespective of their level of detail or documentation type. Requirements should not contradict themselves.

    Verifiable (IEEE Std. 830)

    Requirements MUST be testable. Example: System should be extremely user friendly. This cannot be tested as “User-friendliness” is undefined quantitatively.

    Traceable (IEEE Std. 830)

    Requirements must be traceable to their origin.

    Complete (IEEE Std. 830)

    Each individual requirement MUST completely describe functionality it specifies. Incomplete requirements MUST be marked, for example by adding "TBD” (“to be determined”) into description or using a corresponding status.

    Each requirement MUST be documented completely. Describe all possible inputs, required responses, errors and exception cases and quality requirements for each desired system function.

    Understandable

    Requirements MUST be understandable to stakeholders. Type of requirements documentation can vary significantly, depending on development phase (and therefore, depending on involved staff). It is important to strictly define terms and use them.

    Correct (IEEE Std. 830)

    A requirement is correct if it adequately represents idea of stakeholder. This also means that requirement should not express more than what stakeholder communicates.

    Example: For any service request, actual end date of is always greater than actual start date. It may seem to be a correct requirement, but it is not. Correct requirement is, actual end date of a service request is always equal to or greater than actual start date of service request.

    Ranked (IEEE Std. 830)

    It is important to rank requirements, according to their importance, legal obligation, or priority.

    Valid and up-to-date

    Documented requirements MUST represent facts and conditions valid for current actualities.

    1.5 Assigning attributes to requirements

    Important attribute types for requirements

    Attribute Type

    Meaning

    Identifier

    Unique identifier of a requirement / artefact.

    Name

    A short description.

    Description

    Long description of the requirement.

    Rank

    Order of the requirement in a set of requirements. Rank should be unique in a chosen set of requirements for implementation.

    Version

    Current version of requirement.

    Author

    Specifies author of requirement.

    Source

    Specifies source of requirement

    Stability

    Specifies approximate stability of requirement. Possible values can be “Fixed”, “Established” and “Volatile”.

    Criticality

    Specifies impact of requirement on business. Possible values can be “High”, “Medium” and “Low”.

    Priority

    Specifies priority of requirement. Priority determines order implementation.

    Assigned to

    Specifies person, group of stakeholders, organization, or organizational unit that is responsible for the requirement.

    Requirement type

    Specifies type requirement (e.g., “Functional requirement”, “Quality requirement”, or “Constraint”).

    Status regarding content

    Specifies current status of requirement content, e.g., “Idea”, “Concept”, “Detailed content”.

    Status regarding validation

    Specifies current status of validation, e.g., “Un-validated”, “Erroneous”, “In correction”.

    Status regarding agreement

    Specifies current status of negotiation, e.g., “Not negotiated”, “Negotiated”, “Conflicting”.

    Estimated Effort

    Estimated effort to implement requirement.

    Release

    Release in which requirement shall be implemented.

    Legal obligation

    Specifies degree of legal obligation of requirement.

    Cross references

    Specifies relations to other requirements, for example, if it is known that implementation of requirement requires prior implementation of another requirement.

    Remarks

    Any information which is of stakeholders’ interest.

     

    1.6 Prioritizing requirements

    To prioritize requirements, follow these steps:

    1. Define goal (i.e., purpose) of prioritization.

    2. Document constraints of prioritization, such as availability of different stakeholders or resources available.

    3. Ensure requirements are at similar level of abstraction.

    4. Choose requirements prioritization criteria. Typical examples of requirements prioritization criteria:

    5. Choosing appropriate stakeholders to ensure required expert knowledge is available during prioritization.

    6. Select of the artifacts to be prioritized.

    1.7 Requirements traceability

    Requirements traceability is ability to trace requirements to business needs, work products based on requirements and relationships among requirements.

    Benefits of requirements traceability

    Aid in verification: Allows verifying whether a requirement has been implemented in the system.

    Identification of unneeded properties / requirements in solutions: Traceability allows identification of unneeded properties / requirements solutions of developed systems. Tracing properties / requirements back to their origin allows identifying requirements that do not contribute to business need and system goal. Unneeded requirements should not be implemented.

    Impact analysis: Allows for analysis of effects during change management. Allows identifying requirements and artefacts that MUST be changed when their underlying requirements change.

    Reuse: Allows for reuse of requirements artefacts in other the projects.

    Accountability: Traceability assists in determining accountability.

    Maintenance: Traceability of requirements allows for simplified system maintenance.

    Caution:

    It takes significant effort to establish and maintain traceabilities. Record information with clear purpose that it will serve.

    Three types of traceability relationships

    1. Pre-requirements traceability are traceability links between requirements and those artefacts that are basis for requirements (Prior artefacts).

    2. Post-requirements traceability are traceability links between requirements and artefacts of subsequent development activities, such as components, implementation, or test cases (Posterior artefacts).

    3. Traceability between requirements is about mapping dependencies between requirements. For example, a requirement refines another requirement, generalizes it, or replaces it.

    Representing requirements traceability

    Traceability can be represented using textual references, hyperlinks, trace matrices and trace graphs.

    Text-based references

    Mentioning source artefact name / description in the target document.

    Hyperlinks

    Establish a hyperlink between initial artefact and target artefact.

    Trace matrices, aka Traceability matrix, Coverage matrix

    Trace matrices are tables where rows contain source (initial artefacts, requirements) and columns contain target artefacts (development artefacts). If a relationship exists between artefact in row “p” and a artefact in column “f”, cell (p, f) is marked.

    Trace matrices are difficult to maintain as number of requirements increases. For example, a trace matrix documenting relation between merely 100 requirements contains over 10000 cells.

    1.8 Versioning of requirements

    Versioning of requirements aims at providing access to specific contents of requirements over time. Versions are marked by unique version numbers. Versioning can be applied to single text-based requirements, to entire requirements documents, and to models.

    Requirements versions

    When versioning requirements, one should distinguish between version number and increment number. For example, version number 4.2 references a requirement with version 4 and increment 2. As shown in figure, with smaller changes regarding content, increment is increased by one. If large changes are performed, version number is incremented. “V” is added in front of version number to make it easier to identify. 

     1.9 Requirements validation

    3 quality aspects of requirements

    Defined requirements quality criteria (e.g., completeness, understandability, agreement etc.) help to check requirements systematically. Requirements validation is carried out for:

    Content: Relevant requirements elicited and documented with appropriate level of detail.

    Documentation: Requirements documented as per defined guidelines and templates.

    Agreement: All stakeholders agree with documented requirements and known conflicts resolved.

    Stakeholders should approve requirements for further development activities only when all three quality aspects are verified.

    Using validation criteria for the quality aspects

    Quality aspect “Content”

    Validate requirements with respect to errors in content. The validation criteria are:

    • Completeness of individual requirements
    • Correctness and adequacy
    • Consistent – Necessary – Testable - Realizable
    • No premature design decisions.
    • Traceable to business needs

    Quality aspect “Agreement”

    Validate requirements for agreement between stakeholders. During the project, stakeholders may change already agreed requirements as they gain new knowledge. Requirements are agreed with all relevant stakeholders and all known requirements conflicts are resolved.

    1.10   Importance of requirements changes

    Requirements change over during life of a system due to errors or incomplete requirements, evolution of context, changes in stakeholders’ needs, legal changes, new technologies, or additional competition in market etc.

    Requirements changes per se may not be an issue as it may indicate stakeholders working closely with system and learning more about it. However, frequent requirements changes make it extremely difficult to develop a stable system. A high change frequency may also indicate inadequately performed IT Business Analysis. Frequent changes take up a lot of resources in project development.

    Change control board

    Change control board (CCB) evaluates and approves changes to requirements. It has following tasks:

    Ø Classification of incoming change requests.

    Ø Estimate effort for performing change.

    Ø Evaluate CRs for desirability (Benefit vs. cost).

    Ø Define new requirements based on CRs.

    Ø Approve or reject CRs.

    Ø Prioritize approved CRs.

    Ø Assign approved CRs to change projects.

    [Source: CPRE FL syllabus].

    Representatives in change control board

    CCB usually consist of following stakeholders: Change manager (Chairperson for CCB), Sponsor, Suppliers, Architect, Configuration manager, Customer representative, Product manager, Project manager, Quality assurance representative and Business Analyst.

    Change manager mediates between parties in case of conflicts, negotiate decisions with respective parties, documents and communicates decisions.

     

    Change request (CR)

    Change requests document desired change and associated information. In agile methodologies, CRs are called "Product backlog". CRs typically contain following information:

    1. Identifier: Uniquely identify a CR.

    2. Title: Summarizes CR in brief statement.

    3. Description: Describes change, also information on effects of changes as well.

    4. Justification: Reasons as to why change is necessary.

    5. Date created: Date at which change request was filed.

    6. Requestor: Person who raised CR.

    7. Requested priority: Importance of CR as per requestor.

    8. Impact analysis status: Indicates whether impact analysis has been performed on CR.

    9. Acceptance status: Indicates CCB acceptance status.

    10.   Accepted priority: CCB priority of CR.

    11. Assigned to: Person responsible for CR.

    12.   Release: Release for CR implementation.

    Classification of incoming change requests

    CRs can be classified as:

    1. Corrective CR: CR raised for fixing a failure of system during its operation attributed to an error in requirements.

    2. Adaptive CR: CR raised for modifying system behavior due to change in stakeholder needs or change in system context.

    CRs also can be classified as:

    1. Exceptional CR (hotfix): CR must be done immediately

    2. Normal CR (hotfix): CR which can follow planned release schedule.

     

    Basic method for implementing CRs

    * Can be tailored depending on organizational and project-specific needs.

    Analyze impacted components

    Identify all components (requirements, design, code, test cases, user manuals etc.) affected by change. Traceability matrices are helpful in analyzing impact of a CR. In absence of traceability matrices, Business Analysts should consult domain experts and development team to identify impacted components.

    Estimate effort and cost

    For each affected component, determine effort for implementing each change. Sum up efforts for finding total effort and then subsequent costs.

    Evaluate and approve / reject CR

    CCB evaluates CR based on objective criteria such as cost and benefit, availability of resources and approves / rejects the CR.

    Prioritize CRs

    CCB prioritizes approved CRs and assigns to projects or system releases for implementation.

    Implement approved changes

    Development team implements approved and prioritized CRs.

    Validate requirement changes

    CCB or person responsible validates implemented CRs.

    Elicit Requirements

    1.1 Key concepts

    • What is elicitation?

    Elicitation involves understanding underlying needs from stated requirements of stakeholders. It also involves eliciting all necessary information for successful development of a system from all identified sources.

    • Elicitation challenges

    Some of the common challenges faced in elicitation are:

    • Users omitting to identify requirements.
    • Users and analysts taking certain knowledge for granted and failing to ensure a common understanding.
    • Lack of clarity in the wordings.
    • Ambiguity of written language.
    • Conflicts between requirements.
    • No way to test.
    • Providing a solution rather than stating requirements.
    • Lack of consensus among business users.
    • Getting into solution domain.
    • Role of communication in IT Business Analysis

    Natural languages are the most important means to communicate requirements. However, stakeholders may understand natural language requirements differently due to their knowledge and background. Effectiveness of natural language communication depends on familiarity of stakeholders on the subject, their past experiences, cultural and educational backgrounds, etc. Hence, it is important to develop common terminology (glossary) and defined requirements constructs, i.e. describe requirements using a standard structure, while communicating in natural language. Expressing requirements using standard constructs helps in not forgetting essential information while using natural languages.

    Business Analysts can take help of modeling languages such as Unified Modeling Language (UML) and Business Process Modeling Notation (BPMN) which reduces ambiguity in communication using natural language.

     

    • Impact of communication mediums in IT Business Analysis

      Communication mediums (written or spoken) have significant effect in requirements communication (or miscommunication). When communicating in natural languages, all stakeholders MUST consciously focus on direct and simple communication. In verbal communication, success of the communication relies on expressed language, gestures and feedbacks. But in written communication, these are absent. Many often, requirements may be communicated incorrectly due to natural transformations that occur during human perceptions

     

    • Language effects

      Natural languages are inherently ambiguous and often interpreted in multiple ways. Requirements are described and referred by people with different knowledge, different social backgrounds and different experiences. Due to gaps in communications, developers develop something different from actual needs of stakeholders. Business Analysts MUST try to minimize such transformations and try to make requirements unambiguous.

     

    • Transformational effects

    As transformational effects adhere to specific rules, Business Analysts can exploit this to elicit deep structures (i.e., what requirement providers really meant) from its surface structures (i.e., stated requirements).

    5 most common transformational processes for requirements are:

    Nominalization (Compression of activities)

    Users tend to convert a long-lasting activity or group of nouns into a single event or noun, this is nominalization. For example, users may say “Manage schedule” when what they actually mean is “Create, Retrieve, Update, Delete, Import and Export schedule”. The way to minimize nominalization is to identify all verbs used in requirements. These verbs MUST be explained clearly in glossary and agreed upon by all stakeholders.

    Nouns without reference index

    Users tend to omit adverbs or use generic nouns. Common nouns which are incompletely specified are: user, system, message, data, or function. For example, let us study a requirement “Users shall update data using their devices”. The following questions arise: Which user? What data? Which devices? We can write the above requirements as: Privileged users can update schedule data using their laptops or mobile phones.

    Universal quantifiers

    Universal quantifiers group set of objects and generalize behavior or property for the group. Typical universal quantifiers are: All, always, every, never, no, none, or nothing etc. Most likely the specified behavior or property may not apply to all the objects in the specified group. Business Analysts MUST verify whether specified behavior or property really applies to all objects grouped through quantifiers.

    For example, let us consider a requirement “The system shall not allow anyone to delete projects”. In this case, following question must be asked: “Can no employee actually delete the name? What happens if someone created a project by mistake?”

    Incompletely specified conditions

    Conditions are usually associated with words such as if... then, in case, whether and depending on. Stakeholders sometimes specify behavior that MUST occur when condition is met, but forget to specify what should occur if condition is NOT met.

    For example, let’s consider requirement, “Only post graduates are eligible to attend the program”. In this example, at least one aspect remains unspecified: “Which programs shall be offered to graduates or lower”?

    Business Analysts should use decision tables and decision trees for complex conditional structures.

    Incompletely specified process verbs

    Some verbs need more than one noun to be completely specified. For example, verb “Communicate” requires at least three aspects for completeness: “What is being Communicated, who is communicating and to whom it is being Communicated”. Formulating requirements in active voice minimizes incompletely specified process words.

     

    • Elicitation using requirements models

    If you would have visited any new housing complex or a large building being constructed, you would have observed that a tiny replica is made with defined proportions, such as 100 meters: 10 centimeters. Such physical models allow designers and architects to visualize the entire property before constructing the actual property. They can understand if the open spaces will be adequate, what would be ideal places for provisioning the common amenities such as club-house, swimming pool etc.

    Obviously, the model is the real thing but it serves a great purpose: Be a guide for the architects and engineers. Same way, Business Analysts can model requirements which often provides requirements in a condensed manner and aids in completing the missing parts of the requirements.

    We can define models as: "Models are abstractions of an existing or desired reality”. Requirements models are usually diagrams, tables or mathematical equations. Requirements models make it easier to document requirements, understand requirements from different perspectives and reduce ambiguity.

    Elicitation and documentation of requirements in the form of conceptual models offers following advantages:

    • Information presented in pictures is quicker to understand,
    • Allow the targeted modeling of one or multiple perspectives on the requirements.

    Combining natural language and requirements models provides the advantages of both documentation types.

     

    • Aspects to take care during elicitation

    While conducting elicitation, Business Analysts should carry out concurrent activities for eliciting, documenting, validating, capturing attributes, modeling, verifying, and confirming requirements. However, it is not possible to complete all the work during elicitation. Still Business Analysts should keep an eye on above mentioned activities to get quality requirements at source.

     

    • Elicitation techniques

    Various techniques used for requirements development are:

    1. Survey techniques (e.g. interviews, workshops, questionnaires),
    2. Creativity techniques (e.g. brainstorming, brainstorming paradox, change of perspective, analogy technique),
    3.Document-centric techniques (e.g. system archaeology, perspective-based reading, requirements reuse),
    4.Observation techniques (e.g. field observation, apprenticing),

     

    • Factors influencing choice of elicitation techniques

    Factors influencing the choice of elicitation techniques are:

    1. Type of requirement - Conscious, unconscious and subconscious requirements to be elicited,

    2. Desired level of detail of the requirements, Time and budget constraints,

    3. Availability of stakeholders, Risks of the project, Context, Organizational influences,

    4. Human influences: Experience of Business Analysts and stakeholders with particular elicitation techniques.

    Techniques based on level of detail required

    Level of requirement

    Techniques

    Advantages

    Disadvantages

    Abstract requirements

    Creativity techniques

    (Interview, Brainstorming)

    Capture subconscious requirements

    Provide immediate feedback

    Time and effort consuming

    Medium

    Inquisitive (survey) techniques or observational techniques

    Questionnaire

    Precise and unbiased.

    Stakeholders unable to express their opinions can provide their inputs.

    Cost effective.

    Can be only employed to elicit requirements IT BA already knows.

    Do not provide immediate feedback.

    Creating right questionnaire is tricky, time-consuming and requires good knowledge of the domain.

    Finely detailed requirements

    Document-centric techniques

    Captures extensive details.

    Takes time.

    Can produce lots of requirements.

     

     

    Techniques based on availability of stakeholders

    Stakeholder availability

    # of stakeholders

    Techniques

    Co-located

    Limited

    Interviews, Workshops

    Distributed, Large

    Large

    Survey

    Techniques based on risks of project

    Low

    Medium

    High

    Survey

    Prototyping

    Interviews, Workshops

    Observation and document-centric techniques

    Techniques based on complexity of the project

    Simple

    Complex

    Survey

    Prototyping, Interviews, Workshops

    Observation and document-centric techniques

     

    1.2 Activities

    • Determine suitable elicitation techniques

    Purpose: Determine suitable elicitation techniques to elicit requirements.

    Stakeholders: Sponsor, Domain SMEs, Project manager, Regulator, Supplier.

    Inputs

    Elements

    Outputs

    1. Requirements context

    2. System scope

     

    1. Understand different types of requirements to be elicited.

    2. Determine suitable requirements techniques to elicit requirements.

    1. Identified elicitation techniques

    Tools and Techniques: Brainstorming, Elicitation techniques chart.

    Example:

    Type of requirements

    Elicitation techniques

    Modeling techniques

    Non-functional requirements

    Interview

    Non-functional requirements

    Process, data and UI requirements

    Workshops

    Prototype, Activity diagram, State chart diagram

    Interfacing requirements

    Interview

    Interface mapping template

    Legal requirements

    Interview 

    NA 

    Business rules

    Document analysis, Interview and Workshop

    Flow charts

    Reporting requirements

    Interview

     Report structure template

     

    • Prepare for elicitation

    Purpose: To prepare for conducting elicitations.

    Stakeholders: Business Analyst.

    Inputs

    Elements

    Outputs

    1. Identified Stakeholders

    2. RE activity plan

    1. Identify resources needed for conducting elicitations.

    2. Organize needed resources.

    1. Resources organized for elicitation

    Tools and Techniques: Audio and video recordings.

     

     

     

    Example:

    Prepare for eliciting business requirements

    Type of meeting

    Focus of workshop

    Participants

    Date

    Time

    Status

    Workshop

    Stakeholder commitment

     

    Dave Richards

    Mike Dent

    Dinesh Pandey

    Lee Fung

    17-Mar

    10:00 AM to 12:00 Noon

     

    Workshop

    Delivery Management

    Peter Lily

    Shalini Paul

    Gajendra Battalla

    Nori Masa

    19-Mar

    10:00 AM to 12:00 Noon

     

    Interview

    Audit management

    Rebecca Randad

    21-Mar

    10:00 AM to 12:00 Noon

     

    Interview

    Training manager

    Susan Thomas

    22-Mar

    10:00 AM to 12:00 Noon

     

    Interview

    Risk manager

    Sara Lee

    23-Mar

    10:00 AM to 12:00 Noon

     

    Interview

    Resourcing manager

    Jane Macrae

    26-Mar

    10:00 AM to 12:00 Noon

     

    Interview

    IT Manager

    Surya T

    27-Mar

    10:00 AM to 12:00 Noon

     

     

     

    • Elicit requirements

    Purpose: To elicit requirements from stakeholders and other sources.

    Stakeholders: Sponsor*, Customer*, Domain SME*, End user*, and Regulator*,

    Project manager, Implementation SME, Operational support, Tester, Supplier.

    Inputs

    Elements

    Outputs

    1. Business need and solution scope

    2. Scheduled resources

    3. Supporting materials

    1. Elicit non-functional, functional and implicit requirements.

    2. Elicit regulatory, statutory, contractual requirements.

    3. Elicit current and future requirements.

    4. Elicit interface requirements.

    5. Ensure requirements expressed are aligned to business need and solution scope.

    6. Capture requirement attributes.

    a. Elicited requirements

    Tools and Techniques: Requirements workshop, Interview, Observation, Survey/Questionnaire, Document analysis, Requirements Template.

     

    Example:

    Abstract of a discussion between Head of Delivery and Business analyst

    Michelle (BA): Good morning Mike. Thanks for taking time out to talk to me.

    Mike (CDO): Good morning Michelle. Pleasure meeting you.

    Michelle: I would like to congratulate you on our company receiving the prestigious Delloite Technology Fast 50 Award.

    Mike: Thanks Michelle. Yes, indeed this is a very good news for our organization. I hope you are enjoying your work in our organization.

    (Example of an ice-breaker and forming a rapport with the stakeholder).

    Michelle: As I had intimated you earlier, I am performing the role of Lead BA for the Governance, Risk and Compliance (GRC) management business for our organization. In this regard, I would like to discuss and collect business requirements for the business.

    Mike: Sure Michelle, go ahead.

    Michelle: Can you pls. describe in few sentences the key objectives behind the proposed GRC business?

    Mike: Let me describe why senior management would like to have a GRC business for the organization. We as a company have been growing at a rapid pace. We had 40 active projects 3 years back and now we have 120+ active projects. In next 3 years, we may have 200+ active projects. We could monitor and manage projects when the numbers were small. We should invest into a GRC business which allows us to grow further.

    Michelle: Good to know about our growth story. I would like to know conditions for the GRC business before I discuss the features of the business. Is that ok with you?

    Mike: That’s fine.

    Michelle: Would we like the GRC business to be deployed to our main development center in Seattle or to all development centers world-wide?

    Mike: This is a corporate initiative and all development centers will be part of the deployment. However, we plan to deploy it in phases starting with a small development center in New Jersy.

    Michelle: That’s good to know. Can you let me know who would be primary users of the business?

    Mike: Although senior management will be the primary stakeholders of the business, everyone in the organization will be using the business. Especially for attendance and effort tracking, all employees and contractors will be using the business.

    Michelle: That means we are expecting about 20000 users for the business.

    Mike: Yes. But this could grow up to 100000 users in next 5 to 10 years’ time frame.

    Michelle: Thanks for this information Mike. Since we are deploying the business world-wide, do you expect the business to support multiple languages and currencies?

    Mike: Multiple currencies is a must as this business needs to interface with our accounting business. In future, we would expect the business to enable us invoice our customers. We do not expect the business to support other languages other than English. However, we expect the architecture to be flexible to support other languages in future if needed.

    Michelle: What are the platforms and browsers would you like this business to support?

    Mike: On the end user front, we expect it to support 4 most popular browsers, IE, Chrome, Fire-fox and Opera.

    Michelle: Now that we have discussed key conditions for the business, I would like to capture key features of the business. Can you pls. let me know key user groups for the business?

    Mike: Sure Michelle. Although my group is championing the business, the business is envisioned to support GRC related requirements from other groups such as HR, IT, Compliance and Administration as well.

    Michelle: What are your key requirements from the GRC business?

    Mike: Let me explain my roles for the organization. The 2 key roles for me is to provide our management committee information about revenue projection from our current projects. I also need to monitor health of our client relations and projects.

    Michelle: How do we do that currently?

    Mike: Currently our PMO function shares an excel workbook which is filled by project managers and consolidated by PMO.

    Michelle: What are the challenges that we face in the current process?

    Mike: Challenges are many. We spend significant effort in collecting and consolidating the data. There is a high probability of data getting corrupted as it is a manual process. Due to manual process, there is problem with data not being up-to-date which means management is not able to take action when it should.

    Michelle: I understand, manual processes do have their challenges. As the Head of Delivery, what Features are a must for you?

    Mike: Senior management would like to have a visual dashboard about revenue projection and project health of all projects in the organization. We would like to have color coded indicators with ability to drill down. We would also like to track the actions being taken by project and account managers in rectifying any issue identified by senior management or client.

    Michelle: Sure Mike. Would you be able to share the current revenue projection process and dashboards with me?

    Mike: My colleague, Dinesh who heads our Quality and PMO function can help you with that.

    Michelle: Will do that Mike. Let me make a note of that. Would you like to describe any other critical feature from your perspective?

    Mike: I do not think so Michelle. For first iteration, let us focus on the revenue projection and dash board requirements. You can discuss other business requirements with Dinesh and other department heads.

    Michelle: Thanks Mike for your time and hope we complete the project soon.

    Mike: Thanks Michelle and see you again with the solution.

    Example for detailed requirements:

    Abstract of a discussion between Project Manager – Development Projects and Business Analyst for Schedule Management Feature

    Michelle (BA): Good morning Dave. Thanks for taking time out to talk to me.

    Dave (PM-Dev Projects): Good morning Michelle.

    Michelle: I would like to congratulate you on our company receiving the prestigious Delloite Technology Fast 50 Award.

    Dave: Thanks Michelle. Yes, indeed this is a very good news for our organization.

    Michelle: As I had intimated you earlier, I am performing the role of Lead BA for the Governance, Risk and Compliance (GRC) management system for our organization. I met Mike last week to elicit high level business requirements for the GRC system. Mike wanted me to meet you to understand system requirements for the schedule management module.

    Dave: Sure Michelle. Since I manage development projects, I can give you requirements for development projects. For other types of project, pls. do get in touch with Lily, Srini and Abdullah.

    Michelle: Can you pls. describe how our schedule management is currently performed in our organization?

    Dave: During proposal preparation phase, our Solutioning team provides a rough schedule with high level milestones to the client. Once the contract is awarded to us, the same details are passed on to the Project Managers. Project managers expand the schedule.

    Michelle: Good to know about the process Dave. Can you show me the template that is used by the Solutioning team for the same?

    Dave: The data captured is quite simple. The following table is filled-up by Engagement managers and Sales Managers.

    Milestone name

    Planned Start Week

    Planned End Week

    Responsible

    Key deliverables

    Billing %

     

     

     

     

     

     

     

    Michelle: Are there any business rules that we follow while preparing this data?

    Dave: Not very sure Michelle. This is prepared by Solutions team given our past data and reviewed by Senior Management for appropriateness.

    Michelle: Thanks Dave. How do you expand the schedule?

    Dave: This is highly non-standardized at this point in time and that’s what makes our projects vulnerable to failures. Each project manager expands the task list based on his or her prior experience.

    Michelle: I have noted that Dave. Would you like our new GRC system to standardize the process?

    Dave: That will be a great thing to happen. It will reduce our work as well reduce opportunities for failure. I know from my personal experiences that many projects have suffered heavily because the project manager forgot to include performance or security testing.

    Michelle: In the expanded schedule, do you capture any other information?

    Dave: Yes, Michelle. The expanded schedule has planned, re-planned and actual start and end dates, efforts and resource names.

    Michelle: Ok Dave. Is there any current template that you use?

    Dave: I have created an excel based template which I use for my projects. Being an excel based template, it is difficult to share with all team members. Especially collecting actual efforts become very hard as each week I am consolidating 40+ excel workbooks.

    Michelle: Thanks for this information Dave. I will collect the requirements for the effort tracking system some other time. However, I am noting that our schedule module will require integration with effort capture system, even possibly with our attendance tracking system.

    Dave: Sure, Michelle.

    Michelle: Are there any specific rules that we need to follow for schedule management?

    Dave: Of course, Michelle. Since tasks can have a hierarchy, the child elements must be contained with parent elements. End dates can never be prior to start dates.

    Michelle: Are there any specific interfaces that you would like to have schedules?

    Dave: Yes, Michelle. Since most of our planning may happen in MS-Project or MS-Excel, we would like the system to have feature for importing tasks from MS-Project and MS- Excel and exporting back as well.

    Michelle: What are the reports that you expect the system to provide?

    Dave: We need reports on task wise schedule variance and effort variance. This is a very key report for customer and for our senior management.

    Michelle: Ok Dave. Let me make a note of that. Would you like to describe any other critical feature from your perspective?

    Dave: We also would need alerts for task allocation and escalation for tasks delayed more than a week.

    Michelle: Anything else Dave?

    Dave: No Michelle. I am done from my side.

    Michelle: Thanks Dave for your time and hope we complete the project soon.

    Dave: Thanks Michelle and see you again with the solution.

     

    • Document elicitation results

    Purpose: To document stakeholder and other inputs elicited during elicitation.

    Stakeholders: Any stakeholder who has participated in elicitation tasks.

    Inputs

    Elements

    Outputs

    1. Requirements (Stated, Unconfirmed).

    2. Stakeholder concerns (Unconfirmed).

    1.   Document elicitation results with the stakeholders who provided the requirements.

    1. Documented elicitation results

    Tools and Techniques: Backlog, Enumerated list, Minutes of meeting, Audio and video recordings, Issue log.

    Example:

    #

    Captured elicitation results

    1

    The business must assist senior management to monitor project performances.

    2

    The business must support world-wide deployment.

    3

    Capture effort and attendance.

    4

    Support up to 100000 users.

    5

    Must support multiple currencies.

    6

    Business shall be designed for English. Must have provision to support other languages in future.

    7

    Must support to support 4 most popular browsers, IE, Chrome, Fire-fox and Opera.

    8

    Provide revenue projection to senior management.

    9

    Assist in monitoring health of client relationships and project’s health.

    10

    Provide visual dashboard about revenue projection and project health of all projects in the organization. Dashboards shall have color coded indicators with ability to drill down.

    11

    Ability to track the actions being taken by project and account managers in rectifying any issue identified by senior management or client.

     

    • Confirm elicitation results

    Purpose: To validate that stated requirements expressed by stakeholders match stakeholder’s understanding of the problem and their needs.

    Stakeholders: Any stakeholder who has participated in elicitation tasks.

    Inputs

    Elements

    Outputs

    3. Approved scope.

    4. Requirements (Stated, Unconfirmed).

    5. Stakeholder concerns (Unconfirmed).

    2.  Verify alignment of elicited elicitation results to approved scope.

    3.  Confirm elicitation results with the stakeholders who provided the requirements.

    4.  Confirm requirements elicited from document analysis with Domain SME and Sponsor.

    5.  Update business requirements document based on stakeholders’ feedbacks.

    2. Confirmed and prioritized requirements.

    Tools and Techniques: Interviews, Observation.

    Example:

    #

    Requirements

    Aligned to scope

    Stakeholder Priority

    Stakeholder Rank

    1

    The business must assist senior management to monitor project performances.

    Yes

    High

    1

    2

    The business must support world-wide deployment.

    Yes

    High

    4

    3

    Capture effort and attendance.

    Yes

    High

    3

    4

    Support up to 100000 users.

    Yes

    High

    5

    5

    Must support multiple currencies.

    Yes

    Medium

    7

    6

    System shall support English. Must have provision to support other languages in future.

    Yes

    Medium

    8

    7

    Must support to support 4 most popular browsers, IE, Chrome, Fire-fox and Opera.

    Yes

    Medium

    9

    8

    Provide revenue projection to senior management.

    Yes

    High

    6

    9

    Assist in monitoring health of client relationships and project’s health.

    Yes

    Medium

    10

    12

    Provide an option to evaluate developers’ performance every month.

    No

    NA

    NA

     

     

    Business Analytics Tools

    1.   Analyze requirements


    1.1     Key concepts

     

    • Models and their properties

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    Models are abstract representations of existing realities or desired realities. 3 important properties of models:

    Mapping of realities:

    Models map certain aspects of realities onto their modeling elements. Models can map existing realities, known as “As is” or “Descriptive models” or can map desired realities, also known as “To be” or “Prescriptive models”.

    Reduction of realities:

    Models reduce mapped realities through selection (only selecting a particular aspect, say for example only process steps for a system) and compression (providing high level overview than actual activities).

    High level requirements for GRCPerfect, an Enterprise Governance Risk and Compliance management system

     

     

     

    Detailed process requirement for defect management of GRCPerfect

    Mapping exact realities will result in highly complex and large outputs and would need considerably higher efforts. Hence, purposefully, during modeling, we reduce the complexities. One can consider a simple rule, models provide 80% values with 20% investment. For rest 20% value, one needs to invest 80% effort which does not make business sense.

    1.      Pragmatic property: Models are always constructed for specific purposes through selection or reduction, containing only information necessary for the respective purposes. The perspective could be data, flow, behavior (state) or user interaction. For example, above model only describes “Activity flow” for defect management. It does not describe data, state, or user interaction perspectives for defect management.

     

    • Elements of a conceptual modelling language

     

    Modeling languages are defined by their syntaxes and semantics.

    Syntax: Defines modeling elements and their valid combinations.

    Semantics: Defines individual modeling elements and helps in interpretation of models.

    Conceptual modeling languages are classified as formal (e.g. UML, BPMN) and informal (Flow charts, Swim-lanes) depending on degree of formalization.

    Requirements models

    Conceptual models that document requirements of a system are called requirements models. UML (Unified Modeling Language) is frequently used to develop requirements models. Extensive examples of modeling using UML can be found at OMG.ORG.

    1.2     Activities

     

    • Organize requirements

    Purpose: To organize requirements into appropriate requirements levels and categories.

    Stakeholders: Domain SME, End user, Implementation SME, and Project manager.

    Inputs

    Elements

    Outputs

    1.      Confirmed requirements

    2.     Organization process assets

    3.     Organize requirements according to type of requirement (Functional, non-functional, constraint), level of requirement (High level vs. detailed).

    1.      Organized requirements.

    Tools and Techniques: Functional decomposition, Requirements templates.

     

    Example:

    In this example, confirmed requirements are categorized as per their type and category.

    Confirmed Requirements

    Type

    Category

    The business must support world-wide deployment.

    Non-functional

    Business

    Support up to 100000 users.

    Non-functional

    Business

    Must support to support 4 most popular browsers, IE, Chrome, Fire-fox and Opera.

    Non-functional

    Business

    The business must assist senior management to monitor project performances.

    Functional

    Business

    Capture effort and attendance.

    Functional

    Business

    Provide revenue projection to senior management.

    Functional

    Business

    Provide visual dashboard about revenue projection and project health of all projects in the organization. Dashboards shall have color coded indicators with ability to drill down.

    Functional

    Business

     

    • Prioritize requirements

    Purpose: To ensure project efforts focus on the most critical requirements.

    Stakeholders: Sponsor*, Domain SME*, Implementation SME*, Regulator, and Project manager*.

    Inputs

    Elements

    Outputs

    1.      Business need

    2.     Business case

    3.     Organized requirements

    4.     Requirement prioritization guidelines

    5.     Stakeholder list, roles, and responsibilities

    1.      Enhance requirements attributes.

    2.     Prioritize requirements.

    3.     Manage requirements prioritization challenges.

    1.      Prioritized requirements

    Tools and Techniques: Ranking, Decision analysis, Risk analysis, MoSCoW analysis, Time-boxing, Budgeting and Voting

     

     

     

    Example:

    Requirement

    Type

    Stk. Pri.

    Stk.
    Rank

    Legal?

    Value

    Cost

    Impl. pri

    The business must support world-wide deployment.

    NFR

    H

    4

    NA

    NA

    NA

    H

    Support up to 100000 users.

    NFR

    H

    5

    NA

    NA

    NA

    H

    Must support to support 4 most popular browsers, IE, Chrome, Fire-fox and Opera.

    NFR

    M

    9

    NA

    NA

    NA

    H

    The business must assist senior management to monitor project performances.

    FR

    H

    1

    No

    5

    1

    H

    Provide revenue projection to senior management.

    FR

    H

    6

    No

    5

    1

    H

    Assist in monitoring health of client relationships and project’s health.

    FR

    M

    10

    No

    5

    1

    H

     

     

     

     

    • Model and elaborate requirements

    Purpose: To model and elaborate prioritized requirements using a combination of matrices, diagrams, and mathematical formulas.

    Stakeholders: Domain SME.

    Inputs

    Elements

    Outputs

    1.      Prioritized requirements

    1.      Elaborate requirements.

    2.     Model requirements.

    1.      Modeled requirements

    Tools and Techniques: Data flow diagram, Functional decomposition, Interface analysis, Non-functional requirements analysis, Organization modelling, Process modelling, Prototyping, Scenarios and use cases, State diagrams, and User stories, Matrix model, Use case specifications, Flow charts, Decision tables, Activity diagram.

     

    Models for schedule management

     

     

     

     

    • Prepare requirements package

    Purpose: To package set of requirements in an appropriate manner for effective stakeholder communication.

    Stakeholders: Primary responsibility of Business Analyst.

    Inputs

    Elements

    Outputs

    1.      Business analysis communication plan.

    2.     Organizational process assets.

    3.     Requirements.

    4.     Requirements structure.

    1.      Prepare work products, and deliverables.

    1.      Requirements package.

    Tools and Techniques: Requirements documentation, Requirements for vendor selection.

     

    Example:

    Since this is an excel workbook, this will be available on the book web-site.

     

    • Verify requirements

    Purpose: To ensure requirements and packages meet necessary standards of quality. To identify defects in the requirements before presenting to other stakeholders.

    Stakeholder: Primary responsibility of Business Analyst.

    Inputs

    Elements

    Outputs

    1.      Packaged requirements

    2.     Requirements quality criteria.

    1.      Review requirements.

    2.     Update requirements based on review.

    1.      Verified requirements

    Tools and Techniques: Requirements review checklist, Commenting, Inspection, Prototyping, Peer review, Structured walkthrough.

    Example:

    Date of review

    14-Jan-15

    Reviewed by

    LN Mishra

    Overview

    Yes/No/NA

    Remarks

    Check if prototyping requirements, if any, are documented

    Yes

     

    Check requirements for completeness

    Yes

     

    All stated requirements together, when implemented, will achieved the systems' stated objective

    Yes

     

    Check for consistency

    Yes

     

    Standards and methods are all consistent across all modules of the system

    Yes

     

    Check whether requirements are testable

    Yes

     

     

     

     

     

    • Validate requirements

    Purpose: To validate verified requirements before sharing the requirements for development or procurement.

    Stakeholders: All key stakeholders.

    Inputs

    Elements

    Outputs

    1.      Business need and solution scope.

    2.     Verified requirements.

    1.      Communicate review schedule.

    2.     Present requirements for review.

    3.     Gather observations during the review.

    4.     Seek information from documentation or stakeholders for the queries or clarifications raised by stakeholders.

    5.     Update requirements document with stakeholder feedbacks.

    6.     Obtain approval on requirements.

    1.      Minutes of review meeting

    2.     Approved requirements

    Tools and Techniques: Group review, Structured walkthrough, Inspection, Prototyping, Perspective based reading.

     

     

     

    Example:

    Requirements Group

    Requirements

    Priority

    Rank

    Approved?

    Dashboard

    The system must assist senior management to monitor project performances.

    High

    1

    Yes

    Dashboard

    Provide revenue projection to senior management.

    High

    2

    Yes

    Dashboard

    Assist in monitoring health of client relationships and project’s health.

    High

    3

    No

    Dashboard

    Provide visual dashboard about revenue projection and project health of all projects in the organization. Dashboards shall have color coded indicators with ability to drill down.

    High

    4

    Yes

    Project management

    Ability to track the actions being taken by project and account managers in rectifying any issue identified by senior management or client.

    High

    5

    Yes

    Project management

    Assist project managers in scheduling tasks

    High

    6

    Yes

    Project management

    Provide skill projection for projects.

    Medium

     

    Yes

    Project management

    Project IT asset requirements for projects.

    Medium

    8

    Yes

    Project management

    Assist Project Managers in tracking project risks.

    High

    9

    Yes

     

     

    Manage requirements

     

    1.1     Key concepts

     

    Requirements management knowledge area describes following tasks:

    ü  Allocate requirements

    ü  Communicate requirements

    ü  Manage requirements changes

    ü  Manage IT Business Analysis activities, risks and performance

    ü  Manage requirements conflicts

    ü  Define transition requirements

    ü  Define interface requirements

    ü  Validate new / improved solution

    ü  Identify workarounds and future improvements

    Assigning attributes to requirements

    Defining views on requirements

    Prioritizing requirements

    Tracing requirements

    Versioning requirements

    Managing requirement changes

     

    Requirements management manages individual requirements as well as complete requirements documents. It documents information about requirements throughout entire life cycle of a system. This includes, unique identifiers, name, author, person responsible and sources of requirement.

     

    • Significance of requirements conflicts

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    Requirements conflicts occur when stakeholders disagree on requirements. For example, one stakeholder may like to include a feature which another stakeholder may prefer to keep out. Unresolved requirements conflicts have negative impacts on the project including:

    1.      Stakeholder dissatisfaction.

    2.     Poor return on investment.

    3.     Some stakeholders’ requirements not implemented.

    4.     Operational system not accepted.

    5.     Operational system not sufficiently used.

    Conflict identification

    Conflict analysis

    Conflict resolution

    Documentation of conflict resolution

    At the same time, conflicts provide opportunity for Business Analysts to discover potential new ideas and different options for development. Resolving conflicts increases acceptance of the system. Requirements negotiation aims to develop consensus on requirements among relevant stakeholders. Requirements negotiation MUST be performed throughout IT Business Analysis needing additional efforts and costs. However, advantages of requirements negotiation (reduction of overall cost, increase in acceptance, supporting creativity and innovations) is significantly higher than these additional costs.

     

     

    Conflicts arise during throughout IT Business Analysis activities. Stakeholders provide contradicting requirements during elicitation. Business Analysts should identify potential conflicts early so that they can be analyzed and resolved early.

     

    • Workarounds

     

     

    When a problem is identified with the solution (i.e. a failure to meet a stakeholder need, whether or not the requirement was correctly specified), Business Analysts help the team to determine the most appropriate action.

    Some solution components, especially software applications, may require an Implementation SME to investigate the root cause of problems. Identify defects which MUST be rectified, which can be mitigated through workarounds or other approaches, and which can be accepted until resources are available to address them. If a defect cannot be resolved in an acceptable timeframe (due to complexity, or cause not identified, or not of high priority, etc.), and stakeholders cannot accept the defect, investigate options for mitigating the effects. Options can be additional quality control checks, new manual processes, removal of support for certain exception cases, etc.

    In spite of project and implementation team’s best efforts, situation could arise that the solution is not able to handle certain requirement(s). In such a situation, Business Analyst should identify possible workarounds. Workarounds are useful that they may not be the most elegant solution but they are highly cost-effective and can be implemented in a short duration.

    1.2     Activities

     

    • Allocate requirements

    Purpose: To allocate solution requirements among releases, and solution components to maximize possible business value.

    Stakeholders: Sponsor*, Domain SME*, Project manager*, Implementation SME*, Customers, Suppliers, End user, Operational support, Tester.

    Inputs

    Elements

    Outputs

    1.      Approved and prioritized requirements

    2.     Release plan

    3.     Solution components

    1.      Compute capacity of the releases.

    2.     Allocate requirements among releases and solution components.

    1. Allocated Requirements

    Tools and Techniques: Release plan.

     

    Example:

    Release name

    Capacity (Person-hours)

    Feature

    Effort needed

    Cumulative effort

    1

    900

    Login

    50

    50

     

     

    Basic Schedule

    400

    450

     

     

    Basic defect

    400

    850

    2

    900

    Basic issues

    300

    300

     

     

    Basic risk

    300

    600

     

     

    Basic estimation

    300

    900

    3

    900

    Dashboard

    400

    400

     

     

    Time tracking

    300

    700

     

     

    Advanced schedule

    200

    900

     

     

    • Communicate requirements to stakeholders

    Purpose: To communicate validated requirements to stakeholders.

    Stakeholders: Sponsor*, Domain SMEs*, Implementation SMEs* / Procurement team*, Testers*, Support team.

    Inputs

    Elements

    Outputs

    1.      Requirements communication plan.

    2.     Validated requirements.

    1.       Share validated requirements with stakeholders.

    2.      Send meeting invites if needed.

    3.      Explain requirements.

    4.      Clarify questions.

    5.      Explain rationale behind selection / non-selection of requirements.

    1.      Minutes of meeting.

    Tools and Techniques: Structured walkthrough, Email.

     

    Example:

    Date of Review

    1-Aug-14

    Start Time

    14:00

    End Time

    17:00

    Sl #

    Meeting Invitees

    Department

    Attended?

    Prepared?

    Role

    1

    Mike Dent

    CDO

    Yes

    Yes

    Reviewer

    2

    Dinesh Pandey

    Head-PMO

    Yes

    Yes

    Reviewer

    3

    Lee Fung

    Head-IT

    Yes

    Yes

    Reviewer

    4

    Peter Lily

    Delivery Manager

    Yes

    Yes

    Reviewer

    5

    Shalini Paul

    Delivery Manager

    Yes

    Yes

    Reviewer

    Discussion Topics and Action Items

    Sl #

    Section No. of Document

    Discussion point

    Action Item

    Responsible

    Target Date of Completion

    Status

    1

    NFR

    Testing of NFRs

    To describe testing approaches for NFRs

    Michelle

    30-Sep-14

    Open

    2

    Out of scope

    Out of scope elements

    To clearly specify aspects not in scope

    Michelle

    30-Sep-14

    Open

    3

    Application sizing

    Transaction volume estimates

    To estimate transaction volume estimates for critical features

    Michelle

    30-Sep-14

    Open

    Review Status

    Conditionally Accepted

                         

     

     

    • Manage IT Business Analysis activities, risks and performance

    Purpose: To manage performance of IT Business Analysis activities to ensure they are executed as effectively as possible. Monitor and report IT Business Analysis progress and take necessary corrective actions.

    Stakeholders: Sponsor, Project manager.

    Inputs

    Elements

    Outputs

    1.      Defined IT Business Analysis metrics.

    2.   IT Business Analysis performance

    1.      Prepare IT Business Analysis performance reports.

    2.     Review IT Business Analysis plan, risks and performance with key stakeholders.

    3.     Identify corrective actions to meet desired performance level.

    1.      Corrective actions.

    2.   Updated IT Business Analysis activity plan.

    Tools and Techniques: Status Reporting, Variance analysis, Problem tracking

    Example:

    IT Business Analysis status report for Week of 10-Feb-2014

    Requirements activity

    Target Date

    Status

    Re-planned End Date

    Reason

    Understand project vision

    3-Feb

    Completed

     

     

    KPIs and Dashboards.

    10-Feb

    Completed

     

     

    Non-functional business requirements

    10-Feb

    Completed

     

     

    Project monitoring business requirements

    10-Feb

    Completed

     

     

    Operational Dashboards.

    10-Feb

    Open

    15-Feb

    Stakeholder on leave for the week

    Risks and mitigations

    Risk description

    Probability

    Severity

    Impact

    Mitigation Plan

    Domain SME availability

    Medium

    Critical

    High

    Identify back-ups for all critical Domain SMEs.

    Increase in scope

    High

    Critical

    High

    Discuss during steering committee meetings

    Completeness of requirements

    Medium

    Critical

    High

    Prototypes to be approved by Domain SMEs

     

     

    • Manage requirements changes

    Purpose: To effectively manage requirements changes.

    Stakeholders: PM*, Domain SME*, End user, Sponsor, CCB*.

    Inputs

    Elements

    Outputs

    1.      Suggested requirements changes.

    1.      Record requirements changes.

    2.     Determine if change is acceptable as per project change management policy.

    3.     Propose change to change control board.

    4.     Update requirements documents once change is accepted.

    1.     Accepted requirements changes.

    Tools and Techniques: Requirements Change management, Problem / Issue Tracker, Brain storming.

     

    Example

    Req ID

    Requirement

    Req Type

    Requestor

    Crit.

    Benefit

    Cost

    Val.

    Idx.

    Accepted

    80100

    Support for task dependency

    Functional

    Gajendra Battalla

    Should Have

    3

    6

    50

    No

    80200

    Export of reports to ppt

    Functional

    Dave Richards

    Should Have

    5

    6

    83

    Yes

    80300

    Integration with BI tools

    Functional

    Sara Lee

    Should Have

    3

    4

    75

    Yes

    80400

    Support for Known error database

    Functional

    Nori Masa

    Should Have

    5

    6

    83

    No

     

     

    • Manage requirements conflicts

    Purpose: To effectively manage requirements conflicts.

    Stakeholders: PM*, Domain SME, Sponsor, End user*, Implementation SME.

    Inputs

    Elements

    Outputs

    1.      Requirements conflicts

    1.      Record requirements conflicts.

    2.     Explore options to manage conflicts.

    3.     Decide on the action for the conflict.

    1.      Resolved conflicts

    Tools and Techniques: Conflict management, Problem / Issue Tracker, Brain storming.

     

     

    Example:

    Conflict

    Cause

    Involved stakeholders

    Stakeholder Opinions

    Alternatives for conflict resolution

    Decision

    Reason for decision

    Incorporation of multiple currency

    Future scope of the product

    Domain SME, PM, Lead BA

    Lead BA - Will involve significant effort in reporting

    Domain SME - 90% of contracts are in one currency

    Convert other currency contracts into USD manually

    Convert other currency contracts into USD

    To save project effort

     

     

    • Define transition requirements

    Purpose: To define requirements for transitioning from an existing solution to a new solution.

    Stakeholders: Sponsor*, Implementation SME*, Domain SME*, Project manager*, End user, Operational support.

    Inputs

    Elements

    Outputs

    1.      Existing solution data model

    2.     New solution data model

    3.     Stakeholder list

    1.      Determine data migration requirements.

    2.     Map data elements between existing application data model and New / Updated application data model.

    3.     Develop transformation rules, if needed.

    4.     Determine options to perform ongoing work, and new solution concurrently for defined duration.

    5.     Plan for end user trainings, if needed.

    6.     Manage organizational change.

    7.     Manage on-going work along with new work.

    1.    Transition requirements

    2.   Training plans (Optional)

    3.   Data migration approach

     

    Tools and Techniques: Business rules analysis, Data flow diagrams, Data modeling, and Data mapping template.

     

    Example:

    Since the organization did not have a project management system earlier, there is no need to migrate data. Only a training plan is prepared to enable end-users use the new system effectively.

    Stakeholder group

    Workshops planned

    Date

    Status

    Project managers

    Project management features

    21 to 28 Nov - 2 PM to 5 PM

    Open

    Administrators

    Product administration

    15 and 16 Oct - 10 AM to 4 PM

    Open

    End users

    Time and defect tracking

    5 to 22 Dec - 2 PM to 4PM

    2 batches – 1 hour each

    Open

     

     

     

     

    • Define interfacing requirements

    Purpose: To define requirements for interfacing new application with existing applications.

    Stakeholders: Sponsor*, Implementation SME*, Domain SME*, Project manager*, End user, Operational support.

    Inputs

    Elements

    Outputs

    1.      Existing solution data model

    2.     New solution data model

    4.     Stakeholder list

    1.      Determine data interfacing requirements.

    2.     Map data elements between existing application data model and New / Updated application data model.

    3.     Decide interfacing frequency

    1.      Interfacing requirements

    Tools and Techniques: Data flow diagrams, Data modeling, Data mapping template, Interfacing template.

     

    Example:

    Since the organization has an existing ERP system (Oracle Apps), following interfaces are designed between Oracle Apps and GRCPerfect.

    Source

    Destination

    Data

    Frequency

    Oracle Apps

    GRCPerfect

    Employees, Projects, Allocations

    Once in 15 minutes

    GRCPerfect

    Oracle Apps

    Effort data

    Once a day - midnight 12 AM

    GRCPerfect

    Reporting DB

    Schedule, Defect, Risk and Effort data

    Once a day - midnight 12 AM

     Identify workarounds and future improvements

    Purpose: To validate that a solution meets the business need, and determine the most appropriate response to identified defects.

    Stakeholders: Domain SME, Implementation SME, End user, Sponsor, Project manager, Tester, Operational support, and Regulator.

    Inputs

    Elements

    Outputs

    1.      Solution (Constructed)

    2.     Requirements (Prioritized, and Validated)

    1.      Investigate defective solution outputs.

    2.     Assess defects, and issues.

    3.     Identify possible workarounds to defects where developing permanent solutions may not be gainful.

    4.     Obtain feedback from stakeholders on the workarounds.

    1.      Identified defects

    2.     Mitigating actions

    3.     Solution validation assessment

    Tools and Techniques: Acceptance evaluation criteria definition, Problem tracking, and Root cause analysis, Workarounds.

     

    Example:

    In few of the projects, the stakeholders expected GRCPerfect data to be exported Microsoft Project. However, this was technically very difficult as the internal structure of MS Project is not available to development team. Hence, it was decided that GRCPerfect will export data to MS Excel which will be manually updated in MS Project.

      Previous Next  

    Related Posts

    Write Comment

    Write Comment