You are on page 1of 52

Introduction to Business Analysis

Who is a Business Analyst?

Business Analysts have emerged to have a key role in recent business scenarios. Some people think that the role of a Business Analyst is to make money for the organization, which may not be true in direct context. But indirectly, the action and decision taken by Business Analysts do leave an impact on the financial prospects of the organization.

A primary job responsibility of Business Analyst is to communicate with all stakeholders & to elicit, analyze and validate the requirements for changes to business processes, information systems, and policies.

A professional business analyst plays a big role in moving an organization toward efficiency, productivity, and profitability.

Before we jump into the tutorial, we will see some basic perspective of a Business Analyst to help the organization succeed. The foremost priority for any business analyst will be to try understanding following things

Understand what business does and how it does

Determine how to improve existing business processes

Identify the steps or tasks to support the implementation of new features

Design the new features to implement

Analyze the impact of implementing new features

Implement the new features

Different Business Analyst Role

Business Analyst can be from any sector, and the role differs based on the sector. Business Analyst are classified into various categories like

Business Analyst

Business Process Analyst

IT Business Analyst

Business System Analyst

System Analyst

Data Analyst

Functional Architect

Usability or UX Analyst

Characteristics of a good Business Analyst

Basically, a good business analyst is judged on these four attributes

Introduction to Business Analysis Who is a Business Analyst? Business Analysts have emerged to have afinancial prospects of the organization. A primary job responsibility of Business Analyst is to communicate with all stakeholders & to elicit, analyze and validate the requirements for changes to business processes, information systems, and policies. A professional business analyst plays a big role in moving an organization toward efficiency, productivity, and profitability. Before we jump into the tutorial, we will see some basic perspective of a Business Analyst to help the organization succeed. The foremost priority for any business analyst will be to try understanding following things  Understand what business does and how it does  Determine how to improve existing business processes  Identify the steps or tasks to support the implementation of new features  Design the new features to implement  Analyze the impact of implementing new features  Implement the new features Different Business Analyst Role Business Analyst can be from any sector, and the role differs based on the sector. Business Analyst are classified into various categories like  Business Analyst  Business Process Analyst  IT Business Analyst  Business System Analyst  System Analyst  Data Analyst  Functional Architect  Usability or UX Analyst Characteristics of a good Business Analyst Basically, a good business analyst is judged on these four attributes " id="pdf-obj-0-110" src="pdf-obj-0-110.jpg">

Typical Qualities of a Good Business Analyst:

Analytical skills- An outstanding analytical skills will separate out a good business analyst. A good part of BA role includes analyzing

data, workflow, user or stakeholders inputs, documents, etc. Leadership skills- directing team members, forecasting budget, helping team members with the problem, etc.

Business process and planning- Planning the project scope, understanding and implementing requirement of project, identifying resources required for the project and so on

Technical skill- If a business analyst is in the IT sector, few technical aspect are expected to know like operating systems, hardware capabilities, database concepts, networking, SDLC methodology, etc.

Tools of the Trade

To make their work easier, the business analyst often depends on tools like

TopTeam Analyst: This tool helps in providing a complete solution for requirements gathering and management

Certifications

SmartDraw: It is a graphic diagramming tool that use stencils for organizational charts, swim lanes, data flow diagram, etc.

Blueprint: This tool produces a blue print of the project artifacts like development models, test scenarios, use cases, flow charts, etc.

to ensure that everything is falling in line and as per expectation Survey Monkey: It allows you to send survey to stakeholders, capture their feedback, rank and prioritize their view and turn them

into requirements There are many other tools like iServer, Meetingsense,Ravenflow,AnalystPro, which could be used by Business Analyst during the project.

As per the International Institute of Business Analysis (IIBA), CBAP (Certified Business Analysis Professional) certification is a recognized certificate for a professional Business Analyst. They provide two types of certifications. The certification exam is computer based and consists of multiple choice questions.

Certification of Competency in Business Analysis: Pre-requisite for this certification is atleast 3750 hours of work experience

Jobs

Certified Business Analysis Profession (senior level): Pre-requisite for this certification is atleast 7500 hours of work experience

For off-shore students, they can appear certification exam online. For more information, you can visit thewebsite.

Job prospectus for Business Analyst rises every year, especially for the IT sector. The average salary of business analyst is estimated around $80,000 - $130, 000, even at entry level.

International Institute of Business Analysis (IIBA) is growing exponentially indicating increasing demand of Business Analyst. Business Analyst always remain an organization priority since they have to work in a close proximity to top executives, clients, and stakeholders.

According to U.S Bureau of Labor Statistics, the BA job are predicted to increase by 19% between 2012 and 2022.

Conclusion:

The business analyst role is promising and has to deal with different layers of an organization. Business analyst are classified into various categories like Business Process Analyst, IT Business Analyst and so on.

A good business analyst should encompass skills like

o

Analytical skills

o

Leadership skills

o

Business process and Planning

o

Technical Skills

Various tools that can help Business Analyst are TopTeam Analyst, SmartDraw, Blueprint, etc.

Online certification course for BA available by recognized institute IIBA

According to U.S Bureau of Labor Statistics, the BA job is predicted to increase by 19% between 2012 and 2022.

Stakeholder Needs Analysis

Stakeholder Analysis is done to map the interest of your stakeholders. It is a process of systematically analyzing and gathering qualitative information to determine whose interest should be taken into account.

Stakeholder Analysis is important because it helps project leaders and managers to access a stakeholder's interest, positions, alliances and knowledge related to the project.

When Stakeholder Analysis need to be done?

Stakeholder analysis should always be done at the beginning of a project. Such analysis is helpful in the drafting of a log frame. Log frame is nothing but a general approach to project planning, monitoring, and evaluation in the form of a 'logframe matrix'. Whenever log frames are reconsidered during the life cycle of a project, a stakeholder analysis will be useful. Which means whenever mid-term reviews or annual monitoring is handled, stakeholder analysis should be the part of it.

Stakeholders Categorization

Stakeholders are categorized into two categories

Internal stakeholders

External stakeholders

Within the organization: Employees and Management

Process for Stakeholder Analysis

Outside the organization: Government & Trade Association

Following are the primary aspect needs to be considered for stakeholder analysis

Step 1) Identify your stakeholders: Your boss, your team, senior executives, prospective customers, your family, etc.

Step 2) Assess how those stakeholders could be impacted or have an effect on the organization

Step 3) Prioritize your Stakeholders-

   

StakeHolder Type

Action

High power, interested people

- Keep satisfied

   

High power, less interested people-

- Manage closely

Low power, interested people

- Monitor with minimum effort

   

Low power, less interested people

- Keep informed

Step 4) Identify areas of conflicts (organization vs. stakeholder, stakeholder vs. stakeholder)

Step 5) Prioritize, reconcile and balance stakeholders

Step 6) Align significant stakeholder needs with organizations strategies and actions

Things to take care while dealing with stakeholders

Could you eliminate processes, which do not add stakeholder value?

How would you communicate with stakeholders?

Do your communications encourage stakeholder exchange?

Do you communicate the stakeholder the value of the deal?

Important questions to ask for Stakeholder Analysis

 
   

Different

attribute

check

for

Question to ask your stakeholders

stakeholder

Identification of stakeholder

 

Who is paying for the project? Who will receive the deliverables or profits from the project? Both from your organization and client organization who will work with you to implement the project? Identify the expert for the project domain in the organization.

   

Interest

What direct benefit do stakeholders expect to get from the project? What outcomes do stakeholders expect as a result of the project? What changes do stakeholders need to make as a result of the project? Are there any conflicts of interest amongst the stakeholders?

Influence

What legitimate authority do stakeholders have in the organization? Who controls the project assets and resources? What degree of influence or negotiation power do your identified stakeholders carry in the organization?

   

Impact

How much impact stakeholder could have on the project and does this going to affect the success of the project

Also, you need to figure out when stakeholders will become involved in the following-

Project Vision

Project Scope Definition

Business Process Analysis

Needs Elicitation

Requirement Validation

Design reviews

User acceptance testing You can create a "Participation Matrix Table" for the stakeholders as given below

Participation Type Inform Consult Partner Control Needs Assessment Planning
Participation Type
Inform
Consult
Partner
Control
Needs Assessment
Planning

Implement

Monitoring & Evaluation
Monitoring & Evaluation

Tips to manage your Stakeholders

Do not complain. Accept stakeholders as they are

For guaranteed success, get the key leadership involved.

Make sure, you involve your stakeholders early in the business analysis process

In case of a sensitive issue, ensure full confidentiality to all stakeholders to win their trust.

To avoid conflicts, help all stakeholders in realizing their personal gains from the project.

Guide to SDLC , STLC & V-Model

This tutorial explains in detail the Software/System Development Life Cycle (SDLC) like the Waterfall cycle & Iterative cycle like RAID & Agile. And further, it proceeds to explain the V-Model of testing and STLC (Software Test Life Cycle).

Please be patient. The Video will load in some time. If you still face issue viewing video click here

Video Transcript with Key Takeaways Highlighted:

Suppose, you are assigned a task, to develop a custom software for a client. Now, irrespective of your technical background, try and make an educated guess about the sequence of steps you will follow, to achieve the task.

Implement Monitoring & Evaluation Tips to manage your Stakeholders  Do not complain. Accept stakeholders ashere Video Transcript with Key Takeaways Highlighted : Suppose, you are assigned a task, to develop a custom software for a client. Now, irrespective of your technical background, try and make an educated guess about the sequence of steps you will follow, to achieve the task. The correct sequence would be. Different phases of Software Activities performed in each stage Development Cycle Requirement Gathering stage Gather as much information as possible about the details & specifications of the desired software from the client. This is nothing but the Requirements gathering stage. Design Stage Plan the programming language like Java , PHP , .net; database like Oracle, MySQL, etc. Which would be suited for the project, also some high-level functions & architecture. " id="pdf-obj-4-55" src="pdf-obj-4-55.jpg">

The correct sequence would be.

Different

phases

of

Software

Activities performed in each stage

Development Cycle

 

Requirement Gathering stage

Gather as much information as possible about the details & specifications of the desired software from the client. This is nothing but the Requirements gathering stage.

   

Design Stage

Plan the programming language like Java, PHP, .net; database like Oracle, MySQL, etc. Which would be suited for the project, also some high-level functions & architecture.

Built Stage

After design stage, it is built stage, that is nothing but actually code the software

   

Test Stage

Next, you test the software to verify that it is built as per the specifications given by the client.

Deployment stage

Deploy the application in the respective environment

   

Maintenance stage

Once your system is ready to use, you may require to change the code later on as per customer request

All these levels constitute the waterfall method of software development lifecycle. As you may observe, thattesting in the model starts only after implementation is done.

But if you are working in the large project, where the systems are complex, it's easy to miss out the key details in the requirements phase itself. In such cases, an entirely wrong product will be delivered to the client and you might have to start afresh with the project OR if you manage to note the requirements correctly but make serious mistakes in design and architecture of your software you will have to redesign the entire software to correct the error.

Assessments of thousands of projects have shown that defects introduced during requirements & design make up close to half of the total number of defects.

Also, the costs of fixing a defect increases across the development life cycle. The earlier in life cycle a defect is detected, the cheaper it is to fix it. As the say, "A stitch in time saves a nine."

To address this concern, the V model of testing was developed where for every phase, in the Development life cycle there is a corresponding Testing phase

Built Stage After design stage, it is built stage, that is nothing but actually code the

The left side of the model is Software Development Life Cycle - SDLC

The right side of the model is Software Test Life Cycle - STLC

The entire figure looks like a V, hence the name V - model Apart from V model, there are iterative development models, where development is carried in phases, with each phase adding a functionality to the software. Each phase comprises of its independent set of development and testing activities.

Good examples of Development lifecycles following iterative method are Rapid Application Development, Agile Development

Conclusion

There are numerous development life cycle models. Development model selected for a project depends on the aims and goals of that project.

Testing is not a stand-alone activity, and it has to adapt the development model chosen for the project.

In any model, testing should performed at all levels i.e. right from requirements until maintenance.

Lifecycle of a Requirement

Requirement lifecycle involves a number of phases and at times it can be a complicated process. The nature of the process depends on the methodology you choose for your software development like Agile, Waterfall, Incremental, etc. Each phase may involve a lot of paperwork and approval procedure. It also deals with the project documents like a project proposal, project management plan, project scope, and the business case. Let see some of the common requirement lifecycle required to know for a Business Analyst.

 Testing is not a stand-alone activity, and it has to adapt the development model chosen

Requirement Definition

It is one of the primary phases of the requirement gathering process commonly known as Requirement extraction.

Once the requirement is gathered, it can be organized in folders logically as per product release or sprint.

These requirements are analyzed further to prepare facts and figures for a business analyst to track possible result based on analysis. This procedure is referred as Impact Assessment.

Requirement Validation

The requirement validation phase includes analyzing the needs or conditions required to meet a new or altered product considering needs of the various stakeholders.

For the success of any project, validating requirements is very important. Requirement validation includes checking the specification, wireframe, High Fidelity Simulation, Traceability Analysis, etc.

There are requirement validation tools that do validation with very less human intervention.

Requirement Documentation

Requirement documents should cover following things

Project stakeholders requirement

Business analysis plan

Current state analysis

Scope statement specification

Requirement Management

Requirement Management process includes planning, monitoring, analyzing, communicating and managing of those requirements. If the requirement is not managed well, the end product will get affected adversely. There are requirement management tool available online which help you to manage the requirement with minimum

What is SDLC or Waterfall Model?

Waterfall Model or SDLC, introduced in 1970 by Winston Royce, is a sequential model divided into different phases of software development activity. Each phase is designed for performing specific activity during SDLC phase.

Different Phases of Water-Fall Models Different phases of Software Activities performed in each stage Development CycleJava , PHP , .net or database like Oracle, MySQL, etc. Or other high-level technical details of the project Built Stage After design stage, it is built stage, that is nothing but coding the software Test Stage In this phase, you test the software to verify that it is built as per the specifications given by the client. Deployment stage Deploy the application in the respective environment Maintenance stage Once your system is ready to use, you may later require change the code as per customer request When to use SDLC Waterfall Model Waterfall model can be used when  Requirements are not changing frequently  Application is not complicated and big  Project is short  Requirement is clear  Environment is stable  Technology and tools used are not dynamic and is stable  Resources are available and trained Advantages and Disadvantages of Waterfall-Model " id="pdf-obj-7-2" src="pdf-obj-7-2.jpg">

Different Phases of Water-Fall Models

Different

phases

of

Software

Activities performed in each stage

Development Cycle

 

Requirement Gathering stage

During this phase, detailed requirements of the software system to be developed are gathered from client

   

Design Stage

Plan the programming language like Java, PHP, .net or database like Oracle, MySQL, etc. Or other high-level technical details of the project

 

Built Stage

After design stage, it is built stage, that is nothing but coding the software

 
   

Test Stage

In

this phase,

you

test

the software to

verify

that

it

is

built

as

per

the

specifications given by the client.

 

Deployment stage

Deploy the application in the respective environment

 
   

Maintenance stage

Once your system is ready to use, you may later require change the code as per customer request

When to use SDLC Waterfall Model

Waterfall model can be used when

Requirements are not changing frequently

Application is not complicated and big

Project is short

Requirement is clear

Environment is stable

Technology and tools used are not dynamic and is stable

Resources are available and trained

Advantages and Disadvantages of Waterfall-Model

   

Advantages

Dis-Advantages

Before the next phase of development, each phase must be completed

Error can be fixed only during the phase

   

Suited for smaller projects where requirements are well defined

It

is

not

desirable

for

complex

project

where

requirement

changes frequently

 

They should perform quality assurance test (Verification and Validation) before completing each stage

Testing period comes quite late in the developmental process

   

Elaborate documentation is done at every phase of the software's development cycle

Documentation occupies a lot of time of developers and testers

Project is completely dependent on project team with minimum

Clients

valuable

feedback

cannot

be

included

with

ongoing

client intervention

development phase

 
   

Any

changes in software is

made during the process

of the

Small changes or errors that arise in the completed software

development

 

may cause a lot of problems

What is RAD (Rapid Software Development) Model? Advantages & Disadvantages

RAD or Rapid Software Development process is an adoption of the waterfall model; it targets at developing software in a short span of time. RAD follow the iterative

RAD model has following phases

     Business Modeling Data Modeling Process Modeling Application Generation Testing and Turnover
Business Modeling
Data Modeling
Process Modeling
Application Generation
Testing and Turnover

It focuses on input-output source and destination of the information. It emphasizes on delivering projects in small pieces; the larger projects are divided into a series of smaller projects. The main features of RAD model are that it focuses on the reuse of templates, tools, processes and code.

Different phases of RAD model includes Phases of RAD model Activities performed in RAD Model Business

Different phases of RAD model includes

   

Phases of RAD model

Activities performed in RAD Model

Business Modeling

On basis of flow of information and distribution between various business channels, the product is designed

   

Data Modeling

The information collected from business modeling is refined into a set of data objects that are significant for the business

Process Modeling

The data object that is declared in the data modeling phase is transformed to achieve the information flow necessary to implement a business function

   

Application Generation

Automated tools are used for the construction of the software, to convert process and data models into prototypes

Testing and Turnover

As prototypes are individually tested during every iteration, the overall testing time is reduced in RAD.

When to use RAD model

:

When system needs to be produced in a short span of time (2-3 months)

When the requirements are known

When the user will be involved all through the life cycle

When technical risk is less

When there is a necessity to create a system that can be modularized in 2-3 months of time

When budget is high enough to afford designers for modeling along with the cost of automated tools for code generation

Advantages and Disadvantages of RAD

Advantages

Disadvantages

Flexible and adaptable to changes

It can't be used for smaller projects

   

It is useful when you have to reduce the overall project risk

Not all application is compatible with RAD

It is adaptable and flexible to changes

When technical risk is high, it is not suitable

   

It is easier to transfer deliverables as scripts, high-level abstractions and intermediate codes are used

If developers are not committed to delivering software on time, RAD projects can fail

Due to code generators and code reuse, there is a reduction of manual coding

Reduced features due to time boxing, where features are pushed to later version to finish a release in short period

   

Due to prototyping in nature,

there

is

a

possibility

of lesser

Reduced scalability occurs

because

an

RAD developed

defects

application begins as a prototype and evolves into a finished

application

Each phase in RAD delivers highest priority functionality to client

Progress and problems accustomed are hard to track as such there is no documentation to demonstrate what has been done

   

With less people, productivity can be increased in short time

Requires highly skilled designers or developers

 

What is Incremental model in SDLC? Advantages & Disadvantages

Incremental model are broken down into multiple standalone modules of software development cycle. These cycles are further divided into smaller and more manageable iterations.

Due to code generators and code reuse, there is a reduction of manual coding Reduced features

Each iteration passes through the requirements, design, coding and testing phases. And each subsequent release of the system adds function to the previous release until all designed functionality has been implemented.

Due to code generators and code reuse, there is a reduction of manual coding Reduced features

The system is put into production when the first increment is delivered. The first increment is often a core product where the basic requirements are addressed, and supplementary features are added in the next increments. Once the core product is analyzed by the client, there is plan development for the next increment.

Characteristics of Incremental module includes

System development is broken down into many mini development projects

Partial systems are successively built to produce a final total system

Highest priority requirement is tackled first

Once the incremented portion id developed, requirements for that increment are frozen

   

Incremental Phases

Activities performed in incremental phases

Requirement Analysis

Requirement and specification of the software are collected

   

Design

Some high-end function are designed during this stage

Code

Coding of software is done during this stage

   

Test

Once the system is deployed, it goes through the testing phase

When to use Incremental models?

Requirements of the system are clearly understood

When demand for early release of product arises

When team resources are not very well skilled or trained

When high-risk features and goals are involved

Such model is more in use for web application and product based companies

Advantages and Disadvantages of Incremental Model

Advantages

Disadvantages

Software will be generated quickly during the software life cycle

It requires a good planning designing

   

It is flexible and less expensive to change requirements and scope

Problems might cause due to system architecture as such not all requirements collected up front for the entire software life cycle

Thought the development stages changes can be done

Each iteration phase is rigid and does not overlap each other

   

This model is less costly compared to others

Rectifying a problem in one unit requires correction in all the units and consumes a lot of time

Customer can respond to each built

   

Errors are easy to be identified

What is Spiral Model? When to Use? Advantages & Disadvantages

The spiral model was first mentioned by Barry Boehm in his 1986paper. It is a combination of a waterfall model and iterative model. Each phase in spiral model begins with a design goal and ends with the client reviewing the progress.

The development team in Spiral-SDLC model starts with a small set of requirement and goes through each development phase for those set of requirements. The development team adds functionality for the additional requirement in every-increasing spirals until the application is ready for the production phase.

Spiral Model of SDLC spans into four phases: Spiral Model Phases Activities performed during phase Planning

Spiral Model of SDLC spans into four phases:

   

Spiral Model Phases

Activities performed during phase

Planning

It includes estimating the cost, schedule and resources for the iteration. It also involves understanding the system requirements for continuous communication between the system analyst and the customer

   

Risk Analysis

Identification of potential risk is done while risk mitigation strategy is planned and finalized

Engineering

It includes testing, coding and deploying software at the customer site

   

Evaluation

Evaluation of software by the customer. Also, includes identifying and monitoring risks such as schedule slippage and cost overrun

When to use Spiral-SDLC Model?

When project is large

When releases are required to be frequent

When creation of a prototype is applicable

When risk and costs evaluation is important

For medium to high-risk projects

When requirements are unclear and complex

When changes may require at any time

When long term project commitment is not feasible due to changes in economic priorities

Advantages and Disadvantages of Spiral Model

Advantages

Disadvantages

Additional functionality or changes can be done at a later stage

Risk of not meeting the schedule or budget

   

Cost estimation becomes easy as the prototype building is done

It

works

best

for

large

projects

only

also

demands

risk

in small fragments

assessment expertise

 

Continuous or repeated development helps in risk management

For its smooth operation followed strictly

spiral model

protocol needs to be

   

Development is fast and features are added in a systematic way

Documentation is more as it has intermediate phases

There is always a space for customer feedback It is not advisable for smaller project, it might cost them a lot

Agile Model and Methodologies: Guide for Developers and Testers

To understand the concept of agile testing, first let's understand-

What is Agile?

AGILE is a methodology that promotes continuous iteration of development and testing throughout the software development life cycle of the project. Both development and testing activities are concurrent unlike the Waterfall model

I hope we got an idea of Agile!!! Now, we can step on to Agile Testing.

Development is fast and features are added in a systematic way Documentation is more as it

The agile software development emphasizes on four core values.

  • 1. Individual and team interactions over processes and tools

  • 2. Working software over comprehensive documentation

  • 3. Customer collaboration over contract negotiation

  • 4. Responding to change over following a plan Agile versus Waterfall Method Agile and Waterfall model are two different methods for software development process. Though they are different in their approach, both methods are useful at times, depending on the requirement and the type of the project.

Agile Model

Waterfall Model

Agile method proposes incremental and iterative approach to software design

Development of the software flows sequentially from start point to end point.

   

The agile

process is

broken

into

individual

The design process is not broken into an individual models

models that designers work on

 

The customer has

early

and frequent

The customer can only see the product at the end of the project

opportunities to look at the product and make

decision and changes to the project

   

Agile model is considered unstructured

Waterfall

model

are

more

secure

because

they

are

so

plan

compared to the waterfall model

oriented

Small projects can

be

implemented

very

quickly. For large projects, it is difficult to

estimate the development time.

All sorts of project can be estimated and completed.

   

Error can be fixed in the middle of the project. Only at the end, the whole product is tested. If the requirement error is found or any changes have to be made, the project has to start from the beginning

Development process is iterative, and the project is executed in short (2-4) weeks iterations. Planning is very less.

The development process is phased, and the phase is much bigger than iteration. Every phase ends with the detailed description of the next phase.

   

Documentation

attends

less

priority

than

Documentation is a top priority and can even use for training staff

software development

 

and upgrade the software with another team

Every iteration has its own testing phase. It allows implementing regression testing every time new functions or logic are released.

Only after the development phase, the testing phase is executed because separate parts are not fully functional.

   

In agile testing when an iteration end,

All

features

developed

are

delivered

at

once

after

the

long

shippable features of the product is delivered to the customer. New features are usable right after shipment. It is useful when you have good contact with customers.

implementation phase.

 

Testers and developers work together

Testers work separately from developers

   

At the end of every sprint, user acceptance is performed

User acceptance is performed at the end of the project.

It requires close communication

with

developers and together analyse requirements

and planning

Methodologies of Agile Testing

Developer does not involve in requirement and planning process. Usually, time delays between tests and coding

Small projects can be implemented very quickly. For large projects, it is difficult to estimate the

There are various methods present in agile testing, and those are listed below:

Scrum

SCRUM is an agile development method which concentrates specifically on how to manage tasks within a team based development environment. Basically, Scrum is derived from activity that occurs during a rugby match. Scrum believes in empowering the development team and advocates working in small teams (say- 7 to 9 members). It consists of three roles, and their responsibilities are explained as follows:

SCRUM is an agile development method which concentrates specifically on how to manage tasks within a

Scrum Master

o

Master is responsible for setting up the team, sprint meeting and removes obstacles to progress Product owner

o The Product Owner creates product backlog, prioritizes the backlog and is responsible for the delivery of the functionality at each

iteration

Scrum Team

o

Team manages its own work and organizes the work to complete the sprint or cycle

Product Backlog

This is a repository where requirements are tracked with details on the no of requirements to be completed for each release. It should be maintained and prioritized by product owner, and it should be distributed to the scrum team. Team can also request for a new requirement addition or modification or deletion

Scrum Practices

Practices are described in detailed:

 Scrum Team o Team manages its own work and organizes the work to complete the

Process flow of Scrum:

Process flow of scrum testing is as follows:

Each iteration of a scrum is known as Sprint

Product backlog is a list where all details are entered to get end product

During each Sprint, top items of Product backlog are selected and turned into Sprint backlog

Team works on the defined sprint backlog

Team checks for the daily work

At the end of the sprint, team delivers product functionality

eXtreme Programming (XP)

Extreme Programming technique is very helpful when there is constantly changing demands or requirements from the customers or when they are not sure about the functionality of the system. It advocates frequent "releases" of the product in short development cycles, which inherently improves the productivity of the system and also introduces a checkpoint where any customer requirements can be easily implemented. The XP develops software keeping customer in the target.

 Team works on the defined sprint backlog  Team checks for the daily work Security related information and gathering  Service Level Agreements and its conditions Analysis  Capturing of Stories in Parking lot  Prioritize stories in Parking lot  Scrubbing of stories for estimation  Define Iteration SPAN(Time)  Resource planning for both Development and QA teams Design  Break down of tasks  Test Scenario preparation for each task " id="pdf-obj-16-27" src="pdf-obj-16-27.jpg">

Business requirements are gathered in terms of stories. All those stories are stored in a place called the parking lot.

In this type of methodology, releases are based on the shorter cycles called Iterations with span of 14 days time period. Each iteration includes phases like coding, unit testing and system testing where at each phase some minor or major functionality will be built in the application.

Phases of eXtreme programming:

There are 6 phases available in Agile XP method, and those are explained as follows:

Planning

Identification of stakeholders and sponsors

Infrastructure Requirements

Security related information and gathering

Service Level Agreements and its conditions

Analysis

Capturing of Stories in Parking lot

Prioritize stories in Parking lot

Scrubbing of stories for estimation

Define Iteration SPAN(Time)

Resource planning for both Development and QA teams

Design

Break down of tasks

Test Scenario preparation for each task

Regression Automation Framework

Execution

Coding

Unit Testing

Execution of Manual test scenarios

Defect Report generation

Conversion of Manual to Automation regression test cases

Mid Iteration review

End of Iteration review

Wrapping

Small Releases

Regression Testing

Demos and reviews

Develop new stories based on the need

Process Improvements based on end of iteration review comments

Closure

Pilot Launch

Training

Production Launch

SLA Guarantee assurance

Review SOA strategy

Production Support

There are two storyboards available to track the work on a daily basis, and those are listed below for reference.

o

Story Cardboard This is a traditional way of collecting all the stories in a board in the form of stick notes to track daily XP activities. As this manual

activity involves more effort and time, it is better to switch to an online form.

o

Online Storyboard Online tool Storyboard can be used to store the stories. Several teams can use it for different purposes. Crystal Methodologies

Crystal Methodology is based on three concepts

  • 1. Chartering: Various activities involved in this phase are creating a development team, performing a preliminary feasibility analysis, developing an initial plan and fine-tuning the development methodology

  • 2. Cyclic delivery: The main development phase consists of two or more delivery cycles, during which the

  • 1. Team updates and refines the release plan

  • 2. Implements a subset of the requirements through one or more program test integrate iterations

  • 3. Integrated product is delivered to real users

  • 4. Review of the project plan and adopted development methodology

  • 3. Wrap Up: The activities performed in this phase are deployment into the user environment, post- deployment reviews and reflections are performed. Dynamic Software Development Method (DSDM) DSDM is a Rapid Application Development (RAD) approach to software development and provides an agile project delivery framework. The important aspect of DSDM is that the users are required to be involved actively, and the teams are given the power to make decisions. Frequent delivery of product becomes the active focus with DSDM. The techniques used in DSDM are

1. Time Boxing
1.
Time Boxing
1. Time Boxing
  • 2. MoSCoW Rules

  • 3. Prototyping The DSDM project consists of 7 phases

  • 1. Pre-project

  • 2. Feasibility Study

  • 3. Business Study

  • 4. Functional Model Iteration

  • 5. Design and build Iteration

  • 6. Implementation

  • 7. Post-project Feature Driven Development (FDD) This method is focused around "designing & building" features. Unlike other agile methods, FDD describes very specific and short phases of work that has to be accomplished separately per feature. It includes domain walkthrough, design inspection, promote to build, code inspection and design. FDD develops product keeping following things in the target

  • 1. Domain object Modeling

  • 2. Development by feature

  • 3. Component/ Class Ownership

  • 4. Feature Teams

  • 5. Inspections

  • 6. Configuration Management

  • 7. Regular Builds

  • 8. Visibility of progress and results Lean Software Development Lean software development method is based on the principle "Just in time production". It aims at increasing speed of software development and decreasing cost. Lean development can be summarized in seven steps.

  • 1. Eliminating Waste

  • 2. Amplifying learning

  • 3. Defer commitment (deciding as late as possible)

  • 4. Early delivery

  • 5. Empowering the team

  • 6. Building Integrity

  • 7. Optimize the whole Kanban Kanban originally emerged from Japanese word that means, a card containing all the information needed> to be done on the product at each stage along its path to completion. This framework or method is quite adopted in software testing method especially in agile testing.

Difference between Scrum and Kanban

Scrum

Kanban

In scrum technique, test must be broken down so that they can be completed within one sprint

No particular item size is prescribed

   

Prescribes a prioritized product backlog

Prioritization is optional

Scrum team commits to a particular amount of work for the iteration

Commitment is optional

   

Burndown chart is prescribed

No particular item size is prescribed

 

Between each sprint, a scrum board is reset

A Kanban board workflow state

is persistent.

It

limits the number

of items

in

   

It cannot add items to ongoing iteration

It can add items whenever capacity is available

 

WIP limited indirectly

WIP limited directly

   

Timeboxed iterations prescribed

Timeboxed iterations optional

 

Agile metrics:

Metrics that can be collected for effective usage of Agile is:

Drag Factor

o

Effort in hours which do not contribute to sprint goal

o

Drag factor can be improved by reducing number of shared resources, reducing the amount of non-contributing work

o

New estimates can be increased by percentage of drag factor -New estimate = (Old estimate+drag factor)

Velocity

o

Amount of backlog converted to shippable functionality of sprint

No of Unit Tests added

Time taken to complete daily build

Bugs detected in an iteration or in previous iterations

Production defect leakage

Learn Software Requirements Analysis with Case Study

Software requirement is a functional or non-functional need to be implemented in the system. Functional means providing particular service to the user.

For example, in context to banking application the functional requirement will be when customer selects "View Balance" they must be able to look at their latest account balance.

Software requirement can also be a non-functional, it can be a performance requirement. For example, a non-functional requirement is where every page of the system should be visible to the users within 5 seconds.

So, basically software requirement is a

Functional or

Non-functional need that has to be implemented into the system. Software requirement are usually expressed as a statements.

Types of Requirements

  • 1. Business requirements: They are high-level requirements that are taken from the business case from the projects. For example, a mobile banking service system provides banking services to Southeast Asia. The business requirement that is decided for India is account summary and fund transfer while for China account summary and bill payment is decided as a business requirement

Country

Company providing Banking Functionalities or services

India

Account Summary and Fund Transfer

China

Account Summary and Bill Payment

  • 2. Architectural and Design requirements: These requirements are more detailed than business requirements. It determines the overall design required to implement the business requirement. For our educational organization the architectural and design use cases would be login, course detail, etc. The requirement would be as shown below.

   

Banking use case

Requirement

Bill Payment

This use case describes how a customer can login into net banking and use the Bill Payment Facility.

The customer will can see a dashboard of outstanding bills of registered billers. He can add, modify, and delete a biller detail. The customer can configure SMS, email alerts for different billing actions. He can see history of past paid bills.

The actors starting this use case are bank customers or support personnel.

  • 3. System and Integration requirements: At the lowest level, we have system and integration requirements. It is detailed description of each and every requirement. It can be in form of user stories which is really describing everyday business language. The requirements are in abundant details so that developers can begin coding. Here in example of Bill Payment module where requirement will be mentioned for adding a Biller

Bill Payment

Requirements

Add Billers

Utility Provider Name Relationship/Customer Number

Auto Payments Yes/No Pay Entire Bill Yes/No Auto Payment Limit Do not pay if Bill is over specified amount

Sometimes for some project you might not receive any requirements or documents to work with. But still there are other sources of requirements that you can consider for the requirement or information, so that you can base your software or test design on these requirements. So the other sources for requirement you can rely on are

Other Sources of Requirements

Knowledge transfer from colleagues or employees already working on that project

How to Analyze Requirements

Talk about project to business analyst, product manager, project lead and developers

Analyze previous system version that is already implemented into the system

Analyze the older requirement document of the project

Look into the past Bug reports, some of the bug reports are turned into enhancement request which may be implemented into

current version Look into installation guide if it is available to see what are the installation required

Analyze the domain or industry knowledge that team is trying to implement

Whatever source of requirement you get make sure to document them in some form, get them reviewed from other experienced and knowledgeable team members.

Consider example of an educational software system where a student can register for different courses.

Lets study how to analyze the requirements. The requirements must maintain a standard quality of its requirement, different types of requirement quality includes

Atomic

Uniquely identified

Complete

Consistent and unambiguous

Traceable

Prioritized

Testable

Auto Payments – Yes/No Pay Entire Bill – Yes/No Auto Payment Limit – Do not pay

Let understand this with an example, there are three columns in the table shown here,

  • 1. The first column indicates- "requirement quality"

  • 2. The second column indicates- "bad requirement with some problem"

  • 3. The third column is same as second column but "converted into a good requirement".

Requirement Example of bad requirement Example of good requirement Quality Atomic Students will be able to
Requirement
Example of bad requirement
Example of good requirement
Quality
Atomic
Students will be able to enroll to undergraduate and
post graduate courses
Students will be able to enroll to undergraduate courses
Students will be able to enroll to post-graduate courses
Uniquely
identified
1- Students will be able to enroll to undergraduate
courses
Course Enrolment
Students will be able to enroll to undergraduate courses
Students will be able to enroll to post-graduate courses
1- Students will be able to enroll to post-graduate
courses
Complete
A
professor
user
will
log
into
the
system
by
providing
his
username,
password,
and
other
A professor user will log into the system by providing his
username, password and department code
relevant information
Consistent and
A student will have either undergraduate courses or
post-graduate courses but not both.
A student
will
have
either
under-graduate
or
post
unambiguous
graduates but not both
Some courses will be open to both under-graduate
and post-graduate
Traceable
Maintain
student
information-mapped
to
BRD
Maintain student information-Mapped to BRD req ID 4.1
req.ID?
Prioritized
Registered student-Priority 1
Register Student-Priority 1
Maintain User Information-Priority 1
Maintain User Information-Priority 2
Enroll courses-Priority 1
Enroll courses-Priority 1
View Report Card-Priority 1
View Report Card-Priority3
Testable
Each page of the system will load in an acceptable
time-frame
Register student and enrol courses pages of the system will
load within 5 seconds

Now let's understand each of these requirement in details starting with Atomic.

Atomic

Atomic So each and every requirement you have should be atomic, which means it should be

So each and every requirement you have should be atomic, which means it should be at very low level of details it should not be possible to separated out into components. Here we will see the two examples for requirements, at Atomic and uniquely identified requirements levels.

So let us continue with example of system build for education domain. Here, the bad requirement is "Students will be able to enroll to undergraduate and post graduate courses" . This is a bad requirement because it is not atomic because it talks about two different entities undergraduates and post-graduates courses. So obviously it is not a good requirement but bad requirement, so correspondence good requirement would be to separate it out into two requirements. So one talks about the enrolment to undergraduate courses while the other talks about the enrolment to the post-graduate courses.

Uniquely Identified

Atomic So each and every requirement you have should be atomic, which means it should be

Similarly the next requirement quality is to check for uniquely identified, here we have two separate requirement but they both have same ID#1. So, if we are referring our requirement with reference to ID#, but it is not clear which exact requirement we are referring to document or other part of the system as both have same ID#1. So separating out with unique id's, so good requirement will be re-return as section 1- course enrolments, and it has two requirements 1.1 id is enrolment to undergraduate courses while 1.2 id is enrolment to postgraduate courses.

Complete

Atomic So each and every requirement you have should be atomic, which means it should be

Also, each and every requirement should be complete. For example, here the bad requirement says a "professor user will log into the system by providing his username, password and other relevant information". Here the other relevant information is not clear, so the other relevant information should be spelt out in good requirement to make the requirement complete.

Consistent and Unambiguous

Atomic So each and every requirement you have should be atomic, which means it should be

Next each and every requirement should be consistent and unambiguous, so here for instance we have requirements "A student will have either undergraduate courses or post-graduate courses but not both" this is one requirement there is some other requirement that says "Some courses will be open to both under-graduate and post-graduate students".

The problem in this requirement is that from the first requirement it seems that the courses are divided into two categories under graduate courses and post graduate courses and student can opt either of two but not both. But when you read other requirement it conflicts with the first requirement and it tells that some courses will open to both post-graduate and under-graduate.

So it is obvious to convert this bad requirement into good requirement which is "A student will have either under-graduate courses or post-graduate courses but not both". Which means that every course will be marked either being as under-graduate course or post-graduate course

Traceable

The problem in this requirement is that from the first requirement it seems that the courses

Each and every requirement should be traceable because there are already different levels of requirement, we already saw that at the top we had business requirements, and then we have an architectural and design requirements followed by system integration requirements.

Now when we convert business requirement into architectural and design requirements or we convert architectural and design requirements to system integration requirements there has to be traceability. Which means that we should be able to take each and every business requirements and map it to the corresponding one or more software architectural and design requirement. So here is an example of bad requirement that says "Maintain student information mapped to BRD req ID?" the requirement id is not given over here.

So converting it to a good requirement it says same thing but it is mapped with the requirement id 4.1. So mapping should be there for each and every requirement. Same way we have high level and low level mapping requirement, the mapping is also there between system and integration requirement to the code that implements that requirement and also there is a mapping between the system and integration requirement to the test case which test that particular requirement.

So this traceability is all across entire project

Prioritized

     

Prioritized

Registered student-Priority 1

Register Student-Priority 1

Maintain User Information-Priority 1

Maintain User Information-Priority 2

Enroll courses-Priority 1

Enroll courses-Priority 1

View Report Card-Priority 1

View Report Card-Priority3

Then each and every requirement must be prioritized, so the team has guideline so which requirement that able to implement first and which can be done later on. Here you can see the bad priority has register student, maintain user information and each and every requirement has given priority-1. Everything cannot be at same priority, so requirement can be prioritized. So the example of good requirement over here is the register student and enroll courses is given the highest priority 1, while maintain user information comes below at priority 2 and then we have view report card at priority-3

Testable

     

Testable

Each page of the time-frame

system will load in an acceptable

Register student and enrol courses pages of the system will load within 5 seconds

Each and every requirement should be testable, here the bad requirement is "each page of the system will load in an acceptable time frame". Now there are two problems with this requirement first is that each page meaning that there can be many pages,

which going to blow up the testing efforts. The other problem is that it say the page is going to load in acceptable time frame, now what is acceptable time frame? Acceptable to whom. So we have to convert the non-testable argument into a testable argument, which specifically tells about which page we are talking about "register student and enroll courses pages" and the acceptable time frame is also given which is 5 seconds.

Conclusion

So this is how we have to look at each and every requirement at appropriate level. For example, if we are going to build a software with regards to system and integration requirements. We have to look in system and integration requirements given in the software requirement specifications or user stories and apply to each and every requirement quality. Then check whether each and every requirement is atomic, uniquely identified, and complete and so on.

Requirements Analysis and Transformation Techniques

As a Business Analyst, requirement analysis is the most important part of your Job. It will help you determining the actual needs of stakeholders. At the same time, enable you to communicate with the stakeholders in a language they understand (like charts, models, flow-charts,) instead of complex text.

A requirement analysis has a

Specific Goal

Specific Input

Specific Output

Uses resources

Has a number of activities to be performed in some order

May affect more than one organization unit

Creates value of some kind for the customer

Requirement Analysis Techniques

Requirement analysis techniques are mainly used to map the business workflow so that you can analyze, understand and make required changes to that workflow or process.

There are various requirement analyzing techniques that can be used as per the software development process like

1.

Business process modeling notation (BPMN)

BPMN (Business Process Modeling & Notation) is a graphical representation of your business process using simple objects, which helps the organization to communicate in a standard manner. Various objects used in BPMN includes

Flow objects

Connecting objects

Swim lanes

Artifacts.

A well design BPMN model should be able to give the detail about the activities carried out during the process like,

Who is performing these activities? What data elements are required for these activities? The biggest benefit of using BPMN is that it is easier to share, and most modeling tools support BPMN.

2. UML (Unified Modeling Language) UML is a modelling standard primarily used for specification, development, visualization

2.

UML (Unified Modeling Language)

UML is a modelling standard primarily used for specification, development, visualization and documenting of software system. To capture important business process and artifacts UML provides objects like

State

State

Object

Activity

Class diagram

There are 14 UML diagrams that help with modelling like the use case diagram, interaction diagram, class diagram, component diagram, sequence diagram, etc. UML models are important in the IT segment as it becomes the medium of communication between all stakeholders. A UML-based business model can be a direct input to a requirements tool. A UML diagram can be of two type's Behavioral model and Structural model. A behavioral model tries to give information about what the system do while a structural model will give what is the system consist of.

3.

Flow chart technique

A flowchart is a visual representation of the sequential flow and control logic of a set of related activities or actions. There are different formats for flowcharts which include Linear, Top-down and cross-functional (swim lanes). A flow chart can be used for different activities like representing data flows, system interactions, etc. The advantage of using Flowchart is that it can be easy to read and write even for non-technical team members, and can show the parallel process by function, critical attributes of a process, etc.

4. Data flow diagram Data flow diagrams show how data is processed by a system in

4.

Data flow diagram

Data flow diagrams show how data is processed by a system in terms of inputs and outputs. Components of data flow diagram includes

Process

Flow

Store

Terminator A logical data flow diagram shows system's activities while a physical data flow diagram shows a system's infrastructure. A data flow diagram can be designed early in the requirement elicitation process of the analysis phase within the SDLC (System Development Life Cycle) to define the project scope. For easy analyzing a data flow diagram can be drilled down into its sub-processes known as "levelled DFD".

4. Data flow diagram Data flow diagrams show how data is processed by a system in

5.

Role Activity Diagrams- (RAD)

Role activity diagram is similar to flowchart type notation. In Role Activity Diagram, role instances are process participants, which has start and end state. RAD requires a deep knowledge of process or organization to identify roles. The components of RAD includes

Activities

External events

States

Roles group activities together into units of responsibility, according to the set of responsibility they are

Roles group activities together into units of responsibility, according to the set of responsibility they are carrying out. An activity can be carried out in isolation with a role, or it may require coordination with activities in other roles.

External events are the points at which state changes occur.

States are useful to map activities of a role as it progresses from state to state. When a particular state is reached, it indicates that a certain goal has been achieved.

RAD is helpful in supporting communication as it is easy to read and present a detailed view of the process and permitting activities in parallel.

  • 6. Gantt Charts A Gantt chart is a graphical representation of a schedule that helps to coordinate, plan and track specific tasks in a project. It represents the total time span of the object, broken down into increments. A Gantt chart represents the list of all task to be performed on the vertical axis while, on the horizontal axis, it list the estimate activity duration or the name of the person allocated to the activity. One chart can demonstrate many activities.

7. IDEF (Integrated Definition for Function Modeling) IDEF or Integrated Definition for Function Modeling is a
  • 7. IDEF (Integrated Definition for Function Modeling) IDEF or Integrated Definition for Function Modeling is a common name referred to classes of enterprise modeling languages. It is used for modeling activities necessary to support system analysis, design or integration. There are about 16 methods for IDEF, the most useful versions of IDEF are IDEF3 and IDEF0.

7. IDEF (Integrated Definition for Function Modeling) IDEF or Integrated Definition for Function Modeling is a
  • 8. Colored Petri Nets (CPN) CPN or colored petri nets are graphically oriented language for specification, verification, design and simulation of systems. Colored Petri Nets is a combination of graphics and text. Its main components arePlaces, Transitions, and Arcs.

Petri nets objects have specific inscription like for    Places: It has inscription like

Petri nets objects have specific inscription like for

   Places: It has inscription like .Name, .Color Set, .Initial marking etc. While Transition
Places: It has inscription like .Name, .Color Set, .Initial marking etc. While
Transition : lt has inscription like .Name (for identification) and .Guard (Boolean expression consist of some of the variables)
Arcs: It has inscription like .Arc. When the arc expression is assessed, it yields multi-set of token colors.
9.
Workflow Technique
Workflow technique is a visual diagram that represent one or more business processes to clarify understanding of the process or to
make process improvement recommendations. Just like other diagrams like flowcharting, UML activity and process map, the
workflow technique is the oldest and popular technique. It is even used by BA for taking notes during requirements elicitation. The
process comprises of four stages
Information Gathering
Workflow Modeling
Business process Modeling

Implementation, Verification & Execution

10.

Object oriented methods

Object-oriented modeling method uses object oriented paradigm and modeling language for designing a system. It emphasis on finding and describing the object in the problem domain. The purpose of object oriented method is

To help characterizing the system

The object has a state, and state changes are represented by behavior. So, when the object receives a message, state changes

To know what are the different relevant objects

How do they relate to each other

How to specify or model a problem to create effective design

To analyze requirements and their implications

This method is applicable to the system which has dynamic requirements (changes frequently). It is a process of deriving use cases, activity flow, and events flow for the system. Object oriented analysis can be done through textual needs, communication with system stakeholder and vision document.

through behavior.

11.

Gap Analysis

Gap Analysis is the technique used to determine the difference between the proposed state and current state for any business and its functionalities. It answers questions like what is the current state of the project? Where do we want to be? etc. Various stages of Gap Analysis include

Review System Development Requirements Comparison Implications Recommendations

How to Present Requirements as a Business Analyst

A business requirement is a formal document that addresses the need of the stakeholders for the project or product. There is no standard format to present the business requirement. However, it should cover the product or project description in enough detail to discuss, analyze, document and validate.

A business requirement can be presented in any of the following ways

A table or a spreadsheet

A diagram (workflow)

A graph

A model ( entity-relationship diagram)

A prototype or simulation

A structured sentence or text template

How to organize and present a business requirement

Step 1) Categorize the requirements

Place specific requirement to its relevant categories

For technical stakeholders there should be technical requirement category, for non-technical stakeholders there should be generic

requirement category Each organization should figure out which category suits their standards

Categorization can also be done based on their types (functional versus business). Though this is not applicable to all cases Step 2) Gather and arrange requirements in a logical order. So when stakeholders review the requirements, it is easy to navigate and also identify missing items.

Step 3) Prepare a list of the requirements that is meant to be reviewed by specific stakeholders.

For example, if a stakeholder is from technical background then he would like to know only the technical aspect of the product

Step 4) If tracing requirement to each other is difficult then use unique identifiers, ease in traceability.

Step 5) In certain scenarios, you might have to present same requirement in different ways for different stakeholders. For example, one stakeholder prefers a graphical format while other prefers a structured sentence format

Step 6) Prepare a table of content for all the requirements, it helps stakeholder to easily track requirements

Step 7) Use tools that help in presenting and categorizing the requirements

Step 8) In your requirement document, remove all unnecessary requirements, and organize requirement documents by process flow

Step 9) Map the requirements you have gathered to a particular step in a process flow, this will help reviewers to relate requirement to process flow

Step 10) Use a table for presenting complex requirement. Use bullet points to highlight the key aspect of requirement

Useful tips for presenting requirements

For better presentation and tracking of requirements for stakeholder, here are some tips that might be helpful to BA.

Categorizing requirement is time-consuming and may not be feasible for every organization to create new category each time. For

best practice, it is recommended that there should be a standard set of categories which can be commonly used by BAs, stakeholders, subject experts and technical teams Your requirement should be prepared in context to your audience. Understand who are the key players, influencers and decision

makers. (Stakeholders, technical staff, developers, etc.) Define one requirement at a time. Each requirement should be atomic

Avoid ambiguity by avoiding acronyms like etc., approx., and so on

Do not refer to a requirement that is yet to be defined

Avoid duplicate and contradictory statements

Break complex requirement into manageable and reviewable points

Avoid describing how the system will do something only mention what system will do

Change Control for IT Business Analyst What is Change Control?

Change Control is the process that a company uses to document, identify and authorize changes to an IT environment. It reduces the chances of unauthorized alterations, disruption and errors in the system.

Why require Change Control?

Whenever any new or different changes are requested for the system, especially by stakeholders, it is neither optional nor ignorable. It has to be implemented without affecting other components of the system. This is when the change control comes handy. It helps project teams to modify the scope of the project using specified controls and policies. Change Control is practiced whenever a project is not progressing as planned.

It is mandatory that a formal document for change request is completed and reviewed in order to keep control of change requests.

Number of question one might encounter while analyzing Change Control like

Who will approve the change?

Does it require to run through a change control board?

How much time will be required to research and implement the change?

What are the impacts of changes to other components of the system (schedules, cost, resources, etc.)?

Is there any threshold under which the project management can approve it?

Different factors of Change Control process

There are various factors that a Change Control process should consider

   

Steps in Change Control Process

Action taken in Change Control

Change request initiation and Control

Request for changes should be standardized and subject to management review Change requestor should be kept informed

   

Impact Assessment

Make sure that all requests for change are assessed in a structured way for analyzing possible impacts

Control and Documentation of Changes

A change log should be maintained that tells the date, person details who made changes and changes implemented Only authorized individual should be able to make changes A process for rolling back to the previous version should be identified

   

Documentation and Procedures

Whenever system changes are implemented the procedures and associated document should update accordingly

Authorized Maintenance

System access right should be controlled to avert unauthorized access

   

Testing and User signoff

Software should be thoroughly tested

Version Control

Control should be placed on production source code to make sure that only the latest version is updated

   

Emergency Changes

A verbal authorization should be obtained, and the change should be documented as soon as possible

Process of Change Control

Before we look into what is involved in Change Control process, we will get familiarize with what documents are used in Change Control. While carrying out Change Control, there are mainly two documents involved

Change Log: A change log is a document that list the details about all the Change Requests like project number, PCR (project change request) ID, priority, Owner details, Target date, status and status date, raised by, date when raised etc.

 Change Request Form : It is used to document details required to support the decision

Change Request Form: It is used to document details required to support the decision making process like type of change, benefits of change, name of resource requesting the change, time and estimate cost, priority of change, authorized person detail, change request status etc.

 Change Request Form : It is used to document details required to support the decision

Change Process Flow-Diagram

Change Process follows a specific pattern to implement the changes in the product or system. Here through flow-diagram we explained what are the steps involved in the Change Process.

Steps for Change Control Steps for Change Control Action Change request identification Identify the need for

Steps for Change Control

Steps for Change Control

Action

Change request identification

Identify the need for a change and describe it on the project change request form

   

Change request assessment

If the change is not valid, it has to be deferred or rejected Determine appropriate resources required to analyze the change request Perform quick assessment of the potential impact and update the change request form At this stage, rejected change request should stopped

Change request analysis

For analysis assign the change request to an authorized member Deferred change re-enter this analysis step At this stage, rejected change request should stopped

   

Change request approval

Identify change risk and complexity level before approval Identify the impact level of the change before approval Review impact of Change Request to authorized person for approval At this stage, rejected change request should stopped

Change request implementation

Update project procedure and management plans Inform about the changes to the team Monitor progress of change request Record the completion of change request

Close change request NOTE: The approval for Change Control may be done by Project Manager, Lead IT or Lead Developer, Stakeholder.

Change Management Vs Change Control

Change Management

Change

Control

It is responsible for managing and controlling change requests to effect changes to the IT infrastructure or any aspect of IT services to minimize the risk of disruption of services and promoting business benefit

RS Vs SRS : The Myth Busted Before we begin you must know

The difference between a Requirement and a Specification

Requirements

Specifications

 

They outline “what” the software must do

They outline “how” the software will be created

 

They outline the software from the end-user , business and

They

outline

the

software

from

the

technical

team

stakeholder perspective.

perspective.

 

There are a plethora of terms and terminology for various documents

Specification Documents like -

SRS - System Requirement Specifications

FRS - Functional Requirement Specifications

BRS - Business Requirement Specification

CRS- Compatibility Requirements Specifications

PRS - Performance Requirements Specifications

RRS- Reliability Requirements Specifications

CRS-Configurations Requirements Specification

Requirement Documents like -

BRD - Business Requirement Document

SRD - System Requirement Document

Points To Ponder

In many places these documents are not separate and are used interchangeably.

Specifications and requirements roughly communicate the same information, but to two completely different audiences.

For a given project which documents of above are created, depends on the “nature” of the project and the organizational “processes”

In this tutorial we will discuss SRS and BRS

BRS ( Business Requirement Specification) SRS (System Requirement Specification) It describes at very high level thehere Video Transcript with Key Takeaways Highlighted :  Software testing is a process used to identify the correctness, completeness, and quality of developed computer software. It  includes a set of activities conducted with the intent of finding errors in software so that it could be corrected before the product is released to the end users. In simple words, software testing is an activity to check whether the actual results match the expected results and to ensure that  the software system is defect free . Why is testing is important?  This is China Airlines Airbus A300 crashing due to a software bug on April 26, 1994, killing 264 innocent lives " id="pdf-obj-37-2" src="pdf-obj-37-2.jpg">

BRS ( Business Requirement Specification)

SRS (System Requirement Specification)

It describes at very high level the functional specifications of the software

It describes at a high level , the functional and technical specification of the software

It is a formal document describing about the requirement provided by client (written, verbal)

It specifies the functional and non-functional requirements of the software to be developed

Usually its created by the Business Analyst who interacts with clients

Usually its created by the System Architect who is an technical expert .

Though in smaller companies the BA will create SRS as well.

Some companies do not create SRS altogether. Their BRS is detailed enough to be used as SRS as well.

It is derived from client interaction and requirements

It is derived from the BRS

Introduction to Software Testing & its Importance

This tutorial introduces software testing to the audience and justifies its importance.

Please be patient. The Video will load in some time. If you still face issue viewing video click here Video Transcript with Key Takeaways Highlighted:

Software testing is a process used to identify the correctness, completeness, and quality of developed computer software. It

includes a set of activities conducted with the intent of finding errors in software so that it could be corrected before the product is released to the end users. In simple words, software testing is an activity to check whether the actual results match the expected results and to ensure that

the software system is defect free. Why is testing is important?

This is China Airlines Airbus A300 crashing due to a software bug on April 26, 1994, killing 264 innocent lives

Software bugs can potentially cause monetary and human loss, history is full of such examples

In April of 1999, a software bug caused the failure of a $1.2 billion military satellite launch, the costliest accident in history

In 1985, Canada's Therac-25 radiation therapy machine malfunctioned due to software bug and delivered lethal radiation doses to

patients, leaving 3 people dead and critically injuring 3 others

In may of 1996, a software bug caused the bank accounts of 823 customers of a major U.S. bank to be credited with 920 million US

dollars As you see, testing is important because software bugs could be expensive or even dangerous

As Paul Elrich puts it - "To err is human, but to really foul things up you need a computer."

What is User Acceptance Testing (UAT)?

User acceptance is a type of testing performed by the Client to certify the system with respect to the requirements that was agreed upon. This testing happens in the final phase of testing before moving the software application to Market or Production environment.

 Software bugs can potentially cause monetary and human loss, history is full of such examples

The main purpose of this testing is to validate the end to end business flow. It does NOT focus on the cosmetic errors, Spelling mistakes or System testing. This testing is carried out in separate testing environment with production like data setup. It is a kind of black box testing where two or more end users will be involved.

Who Performs UAT?

Client

End users

 Software bugs can potentially cause monetary and human loss, history is full of such examples

Need of User Acceptance Testing:

Once a software has undergone Unit, Integration and System testing the need of Acceptance Testing may seem redundant. But Acceptance Testing is required because

Need of User Acceptance Testing: Once a software has undergone Unit, Integration and System testing the

Developers code software based on requirements document which is their "own" understanding of the requirements and may not

actually be what the client needs from the software. Requirements changes during the course of the project may not be communicated effectively to the developers.

Acceptance Testing and V-Model

In VModel, User acceptance testing corresponds to the requirement phase of the Software Development life cycle(SDLC).

 Developers code software based on requirements document which is their "own" understanding of the requirements

How is UAT Performed

Prerequisites of User Acceptance Testing:

Following are the entry criteria for User Acceptance Testing:

Business Requirements must be available.

Application Code should be fully developed

Unit Testing, Integration Testing & System Testing should be completed

No Showstoppers, High, Medium defects in System Integration Test Phase -

Only Cosmetic error are acceptable before UAT

Regression Testing should be completed with no major defects

All the reported defects should be fixed and tested before UAT

Traceability matrix for all testing should be completed

UAT Environment must be ready

Sign off mail or communication from System Testing Team that the system is ready for UAT execution

User Acceptance Testing Process:

User Acceptance Testing Process: UAT is done by the intended users of the system or software.

UAT is done by the intended users of the system or software. This testing usually happens at the client location which is known as Beta Testing. Once Entry criteria for UAT are satisfied, following are the tasks need to be performed by the testers:

User Acceptance Testing Process: UAT is done by the intended users of the system or software.

Analysis of Business Requirements

Creation of UAT test plan

Identify Test Scenarios

Create UAT Test Cases

Preparation of Test Data(Production like Data)

Run the Test cases

Record the Results

Confirm business objectives

Analysis of Business Requirements

One of the most important activities in the UAT is to identify and develop test scenarios. These test scenarios are derived from the following documents:

Project Charter

Business Use Cases

Process Flow Diagrams

Business Requirements Document(BRD)

System Requirements Specification(SRS)

Creation of UAT Plan:

The UAT test plan outlines the strategy that will be used to verify and ensure an application meets its business requirements. It documents entry and exit criteria for UAT, Test scenarios and test cases approach and timelines of testing.

Identify Test Scenarios and Test Cases:

Identify the test scenarios with respect to high level business process and create test cases with clear test steps. Test Cases should sufficiently cover most of the UAT scenarios. Business Use cases are input for creating the test cases.

Preparation of Test Data:

It is best advisable to use live data for UAT. Data should be scrambled for privacy and security reasons. Tester should be familiar with the data base flow.

Run and record the results:

Execute test cases and report bugs if any. Re-test bugs once fixed. Test Management tools can used for execution.

Confirm Business Objectives met:

Business Analysts or UAT Testers needs to send a sign off mail after the UAT testing. After sign-off the product is good to go for production. Deliverables for UAT testing are Test Plan, UAT Scenarios and Test Cases, Test Results and Defect Log

Exit criteria for UAT:

Before moving into production, following needs to be considered:

No critical defects open

Business process works satisfactorily

UAT Sign off meeting with all stakeholders

Qualities of UAT Testers:

 No critical defects open  Business process works satisfactorily  UAT Sign off meeting with

UAT Tester should possess good knowledge of the business. He should be independent and think as anunknown user to the system. Tester should be Analytical and Lateral thinker and combine all sort of data to make the UAT successful.

Tester or Business Analyst or Subject Matter Experts who understand the business requirements or flows can prepare test and data which are realistic to the business.

Best Practices:

Following points needs to be considered to make UAT Success:

Prepare UAT plan early in the project life cycle

Prepare Checklist before the UAT starts

Conduct Pre-UAT session during System Testing phase itself

Set the expectation and define the scope of UAT clearly

Test End to End business flow and avoid system tests

Test the system or application with real world scenarios and data

Think as an Unknown user to the system

Perform Usability Testing

Conduct Feedback session and meeting before moving to production

UAT Tools

There are several tools in the market used for User acceptance testing and some are listed for reference:

Fitnesse tool : It is java tool used as a testing engine. It is easy to create tests and record results in a table. Users of the tool enter the formatted input and tests are created automatically. The tests are then executed and output is returned back to the user.

Watir : It is tool kit used to automate browser based tests during User acceptance testing. Ruby is the programming language used for inter process communication between ruby and Internet explorer.

Some Important points of UAT

Most of the times in a regular software developing scenarios, UAT is carried out in the QA environment. If there is no staging or UAT

environment UAT is classified into Beta and Alpha testing but it is not so important when software is developed for a service based industry

UAT makes more sense when the customer is involved to a greater extent

Conclusion:

UAT is one of the many flavors of testing that has emerged over last twenty five years. With UAT, the client can be sure "What to expect" from the product rather than assuming. The benefit of UAT is that there will be no surprises when the product is released to the market.

The complete Business Analysis Process

For any Business Analyst the biggest challenge after getting a project is, how to start and from where to start the project? Or what deliverables might be creating and how to complete the project successfully?

To help you with all sort of questions we have listed out some of the key techniques for a successful business process analysis.

It will give guide you step by step from the day 1 business analysis process till the end of the planning stage.

Step 1) - Gather all information about the project

It is business analyst's responsibility to gather all the details related to the project. By asking questions to people connected with the project (project manager, project sponsor, manager or business owner).

The information gathered should cover these topics

Project scope and boundaries

After gathering all this information, analyze your part in the project and make a checklist that as a Business analyst you can include

Current factors influencing the organization

Project risk and constraints

Broader organizational context

Stakeholders that are actively involved in it. This would be a good time to conduct Stakeholder Needs Analysis

like

From your previous experience what you can implement in your current project

Documentation and planning required into the current project

Discussing the possible outcome of the project with stakeholders

Sort out the members that are involved in the project

Look for any help from client - fixing a meeting with the stakeholders

An unclear agenda may lead to a failure of the project.

What are the expected deliverable and in what format it is required

What existing documentation you can review for better project idea

Find out what methodology (Agile or Waterfall) will be appropriate for your project

Step 2) Set up a review meeting with Project manager/ Stakeholder/ Team members

Be specific in what is expected out of the project.

Involve Project manager/ Stakeholder/ Team members in meeting and ask questions related to project

It is very likely that you might be working on completely new project, in that case, ask project manager or contact person who has worked in that domain before Step 3)Analyze all the project relevant documents like

Business process documentation

Business cases

Step 4) Record all the facts and information that you discover

Charts and flow diagrams

Project plans

Organization chart

Strategy documents and business plans

Policies and legislation

Uncover the information hidden in business requirement document and trace out any gaps with current systems, processes, procedures and operations. It is possible that document that is provided to you is out of date, so validate the information that you discover.

From your research and analysis, you may discover many useful information relevant to the project that has to be changed or implemented in the project. Record them.

Business requirements including reporting requirements

Business processes and supporting systems

Functional and non-functional requirements

Issues and risks that are currently influencing the project

Step 5) Understanding the problem domain

By now you will have a good insight of the project, now you can identify the problem domain in the project. You need to find out

Exactly which business function will be affected

Risks and factors affecting the business

Policies and constraints that influence the project

Values that determines the level of importance of the project

System currently supports the business activities

Document giving brief about the problem domain- e.g., Annual Report

Issues currently blocking the business to achieve the desired outcomes

On proposed change does it make any difference to problem domain

Step 6) Presenting your Business Requirement

Once you have gather all your business requirement and understand the problem domain. The next step ispresenting your Business Requirement to Stakeholders or Project Manager. There are numerous techniques which can be used for presenting requirement like

A table or spreadsheet

A diagram or graph

A prototype or simulation

A structured text template or structured sentence

Glossary of words that will give quick overview of business analyst process

Purpose: Defines the purpose of the business analysis activities required for the proposed initiative Scope: Defines the deliverables that are included and excluded

Root Cause: Define the root causes of the issues identified

Current Condition: Defines the problem that cause the need for change

Planned Activities: Defines the reason for the activity, deliverables, and delivery dates

Stakeholder Engagement plan: It gives an overview of the stakeholder engagement process

Quality Management: It describes the activities that will ensure the quality of project deliverables

Target Condition: Defines how critical issues identified will be addressed

Quick tips for Business Analyst

Ask questions in meetings Be prepared before stakeholder meeting or review

Be adaptable to change and new experience

Manage expectations

Respond to feedback

Learn ER Modeling with a Case Study

What is ER Modeling?

Entity Relationship Modeling (ER Modeling) is a graphical approach to database design. It uses Entity/Relationship to represent real world objects.An Entity is a thing or object in real world that is distinguishable from surrounding environment. For example each employee of an organization is a separate entity. Following are some of major characteristics of entities.

An entity has a set of properties.

Entity properties can have values.

Step 6) Presenting your Business Requirement Once you have gather all your business requirement and understands presenting your Business Requirement to Stakeholders or Project Manager. There are numerous techniques which can be used for presenting requirement like  A table or spreadsheet  A diagram or graph  A prototype or simulation  A structured text template or structured sentence  Glossary of words that will give quick overview of business analyst process  Purpose: Defines the purpose of the business analysis activities required for the proposed initiative Scope: Defines the deliverables that are included and excluded  Root Cause: Define the root causes of the issues identified  Current Condition: Defines the problem that cause the need for change  Planned Activities: Defines the reason for the activity, deliverables, and delivery dates  Stakeholder Engagement plan: It gives an overview of the stakeholder engagement process  Quality Management: It describes the activities that will ensure the quality of project deliverables  Target Condition: Defines how critical issues identified will be addressed  Quick tips for Business Analyst  Ask questions in meetings Be prepared before stakeholder meeting or review  Be adaptable to change and new experience  Manage expectations  Respond to feedback Learn ER Modeling with a Case Study What is ER Modeling? Entity Relationship Modeling (ER Modeling) is a graphical approach to database design. It uses Entity/Relationship to represent real world objects.An Entity is a thing or object in real world that is distinguishable from surrounding environment. For example each employee of an organization is a separate entity. Following are some of major characteristics of entities.  An entity has a set of properties.  Entity properties can have values. Let's consider our first example again. An employee of an organization is an entity. If "Peter" is a programmer (an employee ) at Microsoft, he can have attributes ( properties) like name, age, weight, height, etc. It is obvious that those do hold values relevant to him. " id="pdf-obj-44-144" src="pdf-obj-44-144.jpg">

Let's consider our first example again. An employee of an organization is an entity. If "Peter" is a programmer (an employee) at Microsoft, he can have attributes (properties) like name, age, weight, height, etc. It is obvious that those do hold values relevant to him.

Each attribute can have Values. In most cases single attribute have one value. But it is possible for attributes have multiple values also. For example Peter's age has a single value. But his "phone numbers" property can have multiple values.

Entities can have relationships with each other. Let's consider a simplest example. Assume that each Microsoft Programmer is given a Computer. It is clear that that Peter's Computer is also an entity. Peter is using that computer and the same computer is used by Peter. In other words there is a mutual relationship among Peter and his computer.

In Entity Relationship Modeling, we model entities, their attributes and relationships among entities.

Enhanced Entity Relationship (EER) Model

Enhanced Entity Relationship (EER) Model is a high level data model which provides extensions to originalEntity Relationship (ER) model. EER Models supports more details design. EER Modeling emerged as a solution for modeling highly complex databases.

EER uses UML notation. UML is the acronym for Unified Modeling Language; it is a general purpose modeling language used when designing object oriented systems. Entities are represented as class diagrams. Relationships are represented as associations between entities. The diagram shown below illustrates an ER diagram using the UML notation.

Each attribute can have Values . In most cases single attribute have one value. But it. ER Model with UML Notation Why use ER Model? Now you may think why use ER modeling when we can simply create the database and all of its objects without ER modeling? One of the challenges faced when designing database is the fact that designers , developers and end - users tend to view data and its usage differently . If this situation is left unchecked , we can end up producing a database system that does not meet the requirements of the users . Communication tools understood by all stakeholders(technical as well non-technical users) are critical in producing database systems that meet the requirements of the users . ER models are examples of such tools. ER diagrams also increase user productivity as they can be easily translated into relational tables. Case Study: ER diagram for "MyFlix" Video Library Let's now work with the MyFlix Video Library database system to help understand the concept of ER diagrams. We will using this database for all hand-on in the remainder of this tutorials MyFlix is a business entity that rents out movies to its members. MyFlix has been storing its records manually. The management now wants to move to a DBMS Let's look at the steps to develop EER diagram for this database- 1. Identify the entities and determine the relationships that exist among them. 2. Each entity, attribute and relationship , should have appropriate names that can be easily understood by the non-technical people as well. 3. Relationships should not be connected directly to eachother. Relationships should connect entities. " id="pdf-obj-45-28" src="pdf-obj-45-28.jpg">

Why use ER Model?

Now you may think why use ER modeling when we can simply create the database and all of its objects without ER modeling? One of the challenges faced when designing database is the fact that designers, developers and end-users tend to view data and its usage differently. If this situation is left unchecked, we can end up producing a database system that does not meet the requirements of the users.

Communication tools understood by all stakeholders(technical as well non-technical users) are critical in producing database systems that meet the requirements of the users. ER models are examples of such tools.

ER diagrams also increase user productivity as they can be easily translated into relational tables.

Case Study: ER diagram for "MyFlix" Video Library

Let's now work with the MyFlix Video Library database system to help understand the concept of ER diagrams. We will using this database for all hand-on in the remainder of this tutorials

MyFlix is a business entity that rents out movies to its members. MyFlix has been storing its records manually. The management now wants to move to a DBMS

Let's look at the steps to develop EER diagram for this database-

  • 1. Identify the entities and determine the relationships that exist among them.

  • 2. Each entity, attribute and relationship, should have appropriate names that can be easily understood by the non-technical people as well.

4.

Each attribute in a given entity should have a unique name.

Entities in the "MyFlix" library

The entities to be included in our ER diagram are;

Members - this entity will hold member information.

Members and movies

Movies - this entity will hold information regarding movies

Categories - this entity will hold information that places movies into different categories such as "Drama", "Action", and "Epic" etc.

Movie Rentals - this entity will hold information that about movies rented out to members.

Payments - this entity will hold information about the payments made by members.

Defining the relationships among entities

The following holds true regarding the interactions between the two entities.

A member can rent a more than movie in a given period.

Movies and categories entities

A movie can be rented by more than one member in a given period.

From the above scenario, we can see that the nature of the relationship is many-to-many. Relational databases do not support many-to-many relationships. We need to introduce a junction entity. This is the role that the MovieRentals entity plays. It has a one-to-many relationship with the members table and another one-to-many relationship with movies table.

The following holds true about movies and categories.

A movie can only belong to one category but a category can have more than one movie. We can deduce from this that the nature of the relation between categories and movies table is one-to-many.

Members and payments entities

The following holds true about members and payments

A member can only have one account but can make a number of payments. We can deduce from this that the nature of the relationship between members and payments entities is one-to-many.

Now lets create EER model using MySQL Workbench

In the MySQL workbench , Click - "Create New EER Model"

4. Each attribute in a given entity should have a unique name . Entities in the

Double click on Add Diagram button to open the workspace for ER diagrams.

Double click on Add Diagram button to open the workspace for ER diagrams. Following window appears

Following window appears

Double click on Add Diagram button to open the workspace for ER diagrams. Following window appears

Let's look at the two objects that we will work with.

The table object allows us to create entities and define the attributes associated with the particular

The table object allows us to create entities and define the attributes associated with the particular entity.

The table object allows us to create entities and define the attributes associated with the particular

The place relationship button allows us to define relationships between entities.

The members' entity will have the following attributes

Membership number Full names

Gender

Date of birth

Physical address

Postal address

Let's now create the members table

1.Drag the table object from the tools panel

2.Drop it in the workspace area. An entity named table 1 appears

3.Double click on it. The properties window shown below appears

3.Double click on it. The properties window shown below appears Next , 1. Change table 1

Next ,

  • 1. Change table 1 to Members

  • 2. Edit the default idtable1 to membership_number

  • 3. Click on the next line to add the next field

  • 4. Do the same for all the attributes identified in members' entity. Your properties window should now look like this.

3.Double click on it. The properties window shown below appears Next , 1. Change table 1

Repeat the above steps for all the identified entities.

Your diagram workspace should now look like the one shown below.

<a href=ER Model With all Entities Lets create relationship between Members and Movie Rentals 1. Select the place relationship using existing columns too 2. Click on membership_number in the Members table 3. Click on membership_number in the MovieRentals table " id="pdf-obj-49-2" src="pdf-obj-49-2.jpg">

Lets create relationship between Members and Movie Rentals

  • 1. Select the place relationship using existing columns too

  • 2. Click on membership_number in the Members table

  • 3. Click on membership_number in the MovieRentals table

Repeat above steps for other relationships. Your ER diagram should now look like this -

Repeat above steps for other relationships. Your ER diagram should now look like this -

Repeat above steps for other relationships. Your ER diagram should now look like this -

Summary

ER Diagrams play a very important role in the database designing process. They serve as a non-technical communication tool for

technical and non-technical people. Entities represent real world things; they can be conceptual as a sales order or physical such as a customer.

All entities must be given unique names.

ER models also allow the database designers to identify and define the relations that exist among entities. The entire ER Model is attached below. You can simple import it in MySQL Workbench