• Business Analysis is the set of tasks
Ø knowledge
Ø and techniques required to identify business needs
Ø and determine solutions to business problems.
• Solutions often include a systems development component,
Ø may also consist of process improvement or organizational change.
• Folks performing business analysis are today known by a number of titles
Ø such as business analyst,
Ø business systems analyst,
Ø systems analyst
Major roles of BA
• What is a BA ?
• BA acts as liaison (communication source) between the business team (have a business problem) and the technical team (knows how to create automated solutions).
• BA responsible to gather, detail and document requirements in a format that is useful to business team and the technical developers.
What is a Requirement?
Ø A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard specification, or other formally imposed documents.
Ø Requirements serve as the foundation of systems or system components.
Ø Requirements can be described as a condition or capability a customer needs to solve a problem or achieve an objective. For clarification purposes, a descriptor should always precede
Requirements;
· For example, business requirements, user requirements, system requirements, operational requirements, contract requirements, and test requirements.
The cost of bad requirements
The following are a few key findings and data from the study:
1. Companies with poor business analysis capability will have three times as many project failures as successes.
2. 68% of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis. In fact, 50% of this group’s projects were “runaways” which had any 2 of:
• Taking over 180% of target time to deliver.
• Consuming in excess of 160% of estimated budget.
• Delivering under 70% of the target required functionality.
3. Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects.
4. Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization.
5. The vast majority of projects surveyed did not utilize sufficient
business analysis skill to consistently bring projects in on time and
budget. The level of competency required is higher than that employed within projects for 70% of the companies surveyed.
Effective Requirements Practices
Ø Use of effective requirements definition and management practices leads to
· successful projects
· satisfied customers
· and increased professionalism in the industry.
Ø Benefits include:
· A clear understanding of the needs of users, customers and stakeholders
· A collaborative relationship between the users, customers and stakeholders and the technical team
Types of Requirements
Ø Visible Functional Requirements
“The system will deliver cash to the customer”
“Cash will be delivered after card was taken out”
Ø Qualitative Requirements
“The authorization process will take no more than 1 sec”
“The user interface will be easy to use”
Ø Hidden Requirements
“Database maintenance processes will occur every night”
Qualitative
Requirements
Source of Requirements
Ø Initial requirements come from the customer, by:
Documents, such as RFI/RFP
Meetings, reports
Advanced requirements come from the analysts, after studying:
Scope and price
Feasibility (technological, organizational etc)
Prototypes
Final requirements are stabilized in an iterative process.
Business Scenario’s
Ø Business scenarios are a valuable technique used prior to, and as a key input to, the development of the business architecture to help identify and understand business needs, and
· Thereby to derive the business requirements and constraints that the architecture development must address.
· Business scenarios are used to depict what should happen when planned and unplanned events occur.
· It is highly recommended that business scenarios be created for planned change, and for unplanned change.
Project Scope and purpose
The project scope must explain the project purpose and the goals of the project.
Ø Project Scope documentation includes
· Project Vision (project viewpoint)
· Organize and name all the stakeholders involved in the project
· Prepare Business Case (evaluates risk management, staffing,
project plan, cost, schedule, profit tradeoffs)
· High-level description of business processes
Ø Manage Change Control Process to assure if any scope changes has been formally approved by the Project team management.
Ø Prepare Glossary (for maintaining all the information gathered during the project)
Gather Requirements!
Three different kind of requirements gathering
• Business Requirements: Business needs of project (Project
Manager , Business Experts, Business Architects)-> [Project Vision,
Business case, candidate architecture]
• Functional Requirements: Software Functionality towards the
automated solution for the project. (Project Manager & System
Analyst) -> [System Prototype, Screen Design, Use Case Diagrams]
• Technical Requirements: Technical description of the software
modules for the system. (System Analyst & Developers) [Use Case
Diagram, Class Diagram, Object Diagram]
• Skills required to gather requirements
Interviews, surveys, questionnaires, existing document, learn on
existing automated systems, note-taking.
Categorize & prioritize the requirements
Skills of BA
- Lead project team to have consensus (opinion) on project scope.
- Gather requirements that are critical to project scope.
- Interview, surveys, meetings etc (better communication with peers)
- Project Management (documenting, categorizing and packaging the
requirements gathered)
- Identify and detail documentation of requirement components such
as (data, process, externals, rules)
- Testing principles for requirements
- Conduct requirement review (JAD session, formal/informal
presentation, meetings)