Agile methodology is an iterative and collaborative approach for software development life cycle. Agile methodology is more of people oriented. Agile methodology helps us to increase productivity and reduce risks. Agile aims to reduce risk by breaking projects into small, time-limited modules or timeboxes ("iterations") with each iteration being approached like a small, self-contained mini-project, each lasting only a few weeks. Each iteration has it own self-contained stages of analysis, design, production, testing and documentation. In theory, a new software release could be done at the end of each iteration, but in practice the progress made in one iteration may not be worth a release and it will be carried over and incorporated into the next iteration. The project's priorities, direction and progress are re-evaluated at the end of each iteration. People believe that there is less documentation in Agile. But Agile also includes documentation and it can be used for either small or large projects.
Agile methodology’s aims and characteristics include:
• Customer satisfaction by rapid, continuous delivery of useful software.
• Working software is delivered frequently (weeks rather than months).
• Working software is the principal measure of progress.
• Even late changes in requirements are welcomed.
• Close, daily, cooperation between developers and customers.
• Face-to-face conversation is the best form of communication.
• Projects are built around motivated individuals, who should be trusted (rather than micro-managed).
• Continuous attention to technical excellence and good design.
The Waterfall Model is a popular version of the software development life cycle model for software engineering. Often considered the classic approach to the software development life cycle, the waterfall model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back.
• Project planning, feasibility study: In this phase we establishes a high-level view of the intended project and determines its goals.
• Systems analysis, requirements definition: In this phase we refines project goals into defined functions and operation of the intended application. Also, analyzes the end-user information needs.
• Systems design: This phase of Waterfall model is all about describing desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
• Implementation: The real code is written in this phase of Waterfall Model.
• Integration and testing: In this phase we bring all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.
• Acceptance, installation, deployment: This is the final stage of initial development, where the software is put into production and runs actual business.
• Maintenance: This phase is all about what happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.
The advantage of Waterfall development is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps.
The disadvantage of Waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. Alternatives to the waterfall model include JAD, RAD , Agile and RUP.
The Software Development Life Cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.
In general, an SDLC methodology follows the following steps:
1. The existing system is evaluated. Deficiencies are identified. This can be done by interviewing users of the system and consulting with support personnel.
2. The new system requirements are defined. In particular, the deficiencies in the existing system must be addressed with specific proposals for improvement.
3. The proposed system is designed. Plans are laid out concerning the physical construction, hardware, operating systems, programming, communications, and security issues.
4. The new system is developed. The new components and programs must be obtained and installed. Users of the system must be trained in its use, and all aspects of performance must be tested. If necessary, adjustments must be made at this stage.
5. The system is put into use. This can be done in various ways. The new system can phased in, according to application or location, and the old system gradually replaced. In some cases, it may be more cost-effective to shut down the old system and implement the new system all at once.
6. Once the new system is up and running for a while, it should be exhaustively evaluated. Maintenance must be kept up rigorously at all times. Users of the system should be kept up-to-date concerning the latest modifications and procedures.
There are several methodologies or models that can be used to guide the software development life cycle. Some of these include:
A Business Analyst is responsible for identifying the business needs of their clients and stakeholders (the directors, vendors, employees, and customers) to help determine solutions to business problems. They typically have a high degree of industry experience and are a key facilitator within an organization, acting as a bridge between the client, stakeholders and the solution team.
The Business Analysts study the overall business and information needs of an organization in order to develop appropriate solution strategies. As the key liaison between business and information technology departments, the business analyst is responsible for gathering and documenting business requirements and translating them into functional system design specifications that can be successfully executed by IT development teams.
The Business Analyst discloses, analyzes, validates and documents business, organizational and operational requirements. Solutions are not predetermined by the Business Analyst, but are driven solely by the requirements of the business. Solutions often include a systems development component, but may also consist of process improvement or organizational change. The Business Analyst can have a significant impact on development costs and help the business minimize project delays.
Responsibilities:
• Define and document business and user requirements after thorough fact-finding with customers and analysis of business workflows and system requirements.
• Produce, explain and clarify specifications for customers and project team members.
• Work closely with developers in translating business requirements into high level design specifications.
• Provide realistic estimates and updates of the work necessary to complete all relevant deliverables, and complete all tasks within targeted timeframes.
• Review and provide feedback on test cases and documentation.
A good Business Analyst is creative, a people person. Someone wanting a more hands on approach to business and problem solving. The good Business Analyst will look for opportunities to grow and learn. He or she will listen attentively to what others are saying. The good Business Analyst is like a walking encyclopedia about the company he or she works within. They will know people from every department.
What makes a good business analyst is the ability to listen to what is being said and hear what is not. The good business analyst can read into the meaning of stakeholders words. He or she can understand the needs being expressed when the stakeholders do not always know what they are. The good Business Analyst will be able to determine if the requests from stakeholders or end users are viable. In some cases they are not and it is up to the business analyst to inform what can be done versus what is wanted.
A good Business Analyst is a visionary, a creative thinker, and innovative. He or she is fun to work with and carries a positive attitude.
To summarize, a good Business Analyst must possess following qualities.
1) Quality of a Business Analyst may include some degree in technology.
2) Another quality a Business Analyst should have is the ability to be comfortable in the board room as well as in front of the drawing board.
3) Another best attribute for the Business Analyst is being able to supply options. He or she will know what is available and from whom.
4) Being open minded is a good quality for the Business Analyst.
5) A Business Analyst should be able to analyze the attributes of another individual. He or she can show that person where their expertise can help a project.
6) A Business Analyst should possess a quality that allows him to look into the future to see where business and technology are going.
There are times when services from outside sources may be utilized by the business. The business analyst is trained to understand the importance or lack of need for these sources. He or she can determine the most cost effective way to use the sources. The business analyst may find directing the designated tasks to in-house departments more beneficial to the company. This is part of researching the project proposal. The Business Analyst is to determine the most cost effective way to reach the goal and still succeed with a bottom line net profit. Learn more about the roles and responsibilities of a Business Analyst. Knowledge, Skills and Abilities of the Business Analyst
• Business knowledge: The Business Analyst should have some background knowledge of the subject to make the requirements gathering efficient, although it is not always a must and depends highly on the complexity of the project.
• IT knowledge: The Business Analyst should understand what the company information systems can and cannot do. A skilled business analyst does not need to have a deep technical knowledge but should have some general knowledge of network, operating systems, hardware capabilities, database concepts, and the System Development Life Cycle and project methodology.
• Interpersonal and communication skills (both written and verbal): The Business Analyst should be a great communicator and diligent team member. Because she or he has to liaise with various business units to gather requirements and resolve different business issues.
• Data collecting skills: The Business Analyst should know what data do the company currently have and need to be carried over into the new systems or analysis around what can be achieved with a new system by projecting previous figures of a successful project on the business.
• Analytical and problem solving skills: The Business Analyst needs to have the ability to assemble, analyze and evaluate data and to be able to make appropriate and well-reasoned recommendations and decisions to support the Business stakeholders and the Project team. The Business Analyst should also be able to analyse the feasibility of requirements in terms of efforts, inputs, time, and costs. Identify and resolve issues
• Ability to understand and document business processes: The Business Analyst should be able to recognize, analyze and map processes, model and improve business process and anticipate future state.
To summarize, qualities and skills of a Business Analyst are:
A good Business Analyst will be one of the best assets a company or organization can invest in. Finding a Business Analyst with these qualities is like finding a pot of gold at the end of a rainbow.
The term 'Business Analyst’ has different meaning in different organizations. To some, the business analyst's job is specifically limited to defining information, usually in terms of IT system requirements. For an increasing number of organizations, however, the business analyst has a wider role that examines the environment in which the IT system operates, to ensure that the identified requirements are justified.
The reality is that if you ask ten hiring managers what a business or systems analyst does you are likely to get ten different answers. Job titles and descriptions for analysts vary widely between organizations and the professional analysts may have titles as diverse as: Business Analyst, Systems Analyst, Business Systems Analyst, IT Specialist, Requirements Analyst, Consultant, Programmer/Analyst, etc.
A Business Analyst is a business problem solver, capable of analyzing the business to identify problems and/ or opportunities and to define solution characteristics. A Business Analyst can be a liaison between the business and technical worlds, but is not intoxicated by technology, and not the end user. They provide the process, questions, and techniques to efficiently extract the information needed from the Business Users for successful application development projects. A Business Analyst can also be an integral part of strategic planning, business innovation, or reengineering effort to help select the right projects and/or facilitate the analysis of what needs to be done to bring the business to a desired future state.
"The Modern Analyst bridges the gap between the Business and the Technology"
The Analyst is the primary liaison between the business community, technology organization and external partners for all project requirements during the analysis phase of a project. He or she is responsible for proactively conducting interviews with all project stakeholders to elicit functional requirements, modeling those requirements in an organized manner, then managing and communicating those requirements throughout the project life cycle. Upon establishment of the requirements baseline, he or she will address change management issues and assist in test planning.
In order to be effective, today’s Modern Analyst must understand “The Business”. He must have an intimate knowledge of the business processes and needs of the organization they are working for.
At the same time, the Modern Analyst must understand the challenges of technology and the needs of the development team. He has to realize that technology, while a great advent, it’s not easy to employ – and it requires highly specialized technical skills and resources.
A Business Analyst performs one or more of the following activities:
1. Scope the system. During the initial phase of a project, often called “iteration zero” or simply the inception phase, BA may be the only “development staff” assigned to the project. At this point they will work with key project stakeholders to formulate and communicate the business vision, to envision initial requirements, and to scope the project. Their fundamental goal is to get the project focused early by translating the initial high-level vision into something realistic. They may also help to identify potential areas of automation and even to aid in reengineering the underlying business process.
2. Translate business needs. A major responsibility of BA is to work with project stakeholders to translate their requirements into something that developers can understand as well as to translate the resulting questions that the developers have into something the stakeholders can understand. This is an iterative process throughout the project.
3. Translate technical issues. BA also explains technical/architectural complexities to project stakeholders, such as why your HTML-based application can’t have as slick of a user interface as a Visual Basic application. BAs often explain what the developers are doing and why they need to do it, including explanations of the basis of schedules and estimates.
4. Model and document. BA often works with project stakeholders to identify, model, and then document their requirements and business domain details.
5. Act as a communication broker. BA typically have very good connections within the business community and therefore are in a position to help development teams find the right people to work with.
6. Political mentor. BA often help project teams through the political minefields within their organizations, particularly when the BA has worked within the same organization for several years.
7. Test and validation. BA work with project stakeholders to validate their requirements and analysis models via techniques such as reviews, walkthroughs, and play acting. BA often aid in writing user acceptance test (UAT) test cases and act as a liaison between project stakeholders and your testing organization during UAT.
8. Represent stakeholders. When project teams don’t have direct access to their project stakeholders, clearly not a good situation, BA act as “stakeholder surrogates”. Typically developers treat a BA as the “customer” from which requirements, domain information, and business priorities are provided. The BA in-turn work with the stakeholders to obtain information and to verify decisions.
1. Is a simple, complete, well-structured sentence that
a. States one thing and states it well
b. Does not contain conjunctions (and, or, but, . . .)
c. Avoids the use of limiting phrases (unless, except, . . .)
d. Does not depend on other sources of information
e. Contains subject, verb, object and appropriate modifiers
f. Defines what an actor should or should not do OR is an external constraint that must be
enforced
2. Emphasizes “what” should be done, not “how” to do it will
a. Avoids preconceived solutions
b. Describes business logic (rules), not the technology needed
c. Expresses the what (destination), not the how (journey)
3. Targets components that are in scope for your project
a. Defines a desired behavior or feature of a component of the system
b. Is within your authority to implement
c. Does not impact out-of-scope components
4. Is understandable, unambiguous and clear
a. Has a single possible interpretation
b. Is easily understood by knowledge peers
c. Avoids confusion
d. Is written to the readability level of the target audience
5. Is objectively measurable
a. Clearly states what the solution has to do
b. Defines acceptable behavior for the solution in measurable terms
c. Specifies what data the solution creates or consumes
6. Is one of a complete, internally consistent, non-redundant, set of prioritized
requirement statements.
How to Become Agile in Business Analysis.
Agile software development has established itself as a viable option for delivering information technology that works. Some "Agilists" consider business analysis and requirements gathering to be unnecessary activities. Actually, real Agilists know that figuring out what the business community needs or wants and what the information technology group can deliver have been and still are critical steps in the system development process. It is not a question of whether business analysis and requirements gathering is needed – it is merely a question of how much, how thorough, when, and by whom these critical activities need to be done.
In this course, we present the concepts that make a project – or an organization – agile. We evaluate how this evolving approach impacts the still evolving discipline of business systems analysis. We take a detailed look at Scrum, XP (Extreme Programming), Agile Modeling, Lean Software Development (LSD), and other agile development concepts.
The goal of the class is to help you determine how to leverage the best of business analysis with the best agile development approaches to improve the quality of the delivered technology in useful increments with more contained costs. This course assumes that you have the skills necessary to do business analysis. On the first day, both business analysis managers and practioners should attend to assess the impact that Agile will have on their business analysis efforts. The second day targets specifically the business analysis practtioner with concrete ways of adapting your current business analysis skills to an Agile project, and introduces "User Stories", a very powerful requirements discovery technique from the agile approach.
Define “agile” approaches and how they change the software development paradigm
List the 6 major flavors of agile methods
Present the rationale, risks and rewards of agile development
Describe the daily Scrum meeting and how it can help your project
Defend the need for the business analyst role on agile projects
Discuss the pros and cons of the Agile Manifesto and why it is relevant
Use a checklist to test the viability of an agile approach on a project
Explain how business analysts have to change to become more agile
Present agile modeling concepts, principles and practices
List and rank business analysis techniques that make requirements determination agile
Define basic agile modeling rules
List models that business analysts can use on agile projects
Identify the 7 most significant challenges to organizations adopting agile methods
Apply a “Just in Time/Just in Case” (JIT/JIC) philosophy to analysis activities
Define the critical business analysis skills needed for agile team members
Discuss the impact that Agile has on current development methodologies
Capture and track user stories to document business requirements
How to discover and develop USE CASE?
The critical success factor for any solution is whether or not the end users will be able to use it to do what they need to do. The concept of using use cases to define end-user interaction with a proposed information technology solution is invaluable for interactive applications.
A use case diagram is a visual tool that shows who will interact with an evolving information technology solution. A single use case is a textual tool for representing how individual end-users and other involved parties or systems (collectively referred to as "actors:") will interact with the proposed system. Knowing why you need a use case, when it should be created, and where to put what information is critical to creating quality functional requirements. Without a common understanding of the purpose and structure of use case diagrams and the use case document, use cases can quickly become "useless cases".
Define the evolving role of business systems analysts
List 5 methods for discovering use cases
Distinguish between "business" and "system" use cases
Use business event models to initiate and scope an IT project
Present the transition from business events to use cases
Document proposed user interaction in use cases and use case diagrams
Structure basic use case information in a use case document
Apply use case diagrams as a scoping tool
Define and describe scenarios to discover use cases
Clarify the major components of the use case
Detail the sequence of interaction steps for the most common situation
Determine how to handle alternate and exception situations
Create and analyze activity diagrams to show use case flow of events
Identify 18 business requirement categories and map them to use case components
Review and critique use case documents and use case diagrams
Have a use case development kit for use on future projects
Write audience-focused use cases
Differentiate between level of detail and level of focus of a use case
Introduction to Business Use Case documentation and modeling.
A use case diagram is a visual tool that shows who will interact with an evolving information technology solution. A single use case is a textual tool for representing how individual end-users and other involved parties or systems (collectively referred to as “actors :”) will interact with the proposed system. Knowing why you need a use case, when it should be created, and where to put what information is critical to creating good, usable use cases.
Outline
Definition of a Use Case
Of Business Events and Use Cases
From Business Events to Use Cases
Introducing the Actor
Naming Actors
Use Case Diagram Symbols and Rules
Naming Use Cases
User Scenarios:
Paths in a Use Case
Use Case Example: Process Payment
Define the evolving role of business systems analysts
Differentiate between ievent–driven and process–driven information technology
List the major components of a use case document
Explain the meaning of a use case diagram
Describe the connection between business events and use cases
Define standard, alternate, and exception paths
How to Capture Functional Requirements with Use Cases and Diagrams
The use case is the ultimate answer to the question, "How will someone use the solution I am developing once it is complete?" The answers to this question can become quite complex and require a considerable amount of structuring to make sense to both the business user and the developers who will ultimately deliver the technology solution. This class teaches techniques for gathering the information and structuring it into use case templates that transition easily into the real world of business analysis.
Outline
Identifying Business Use Cases
Inside the Use Case
Use Case Example: Process Payment
Paths in a Use Case
Numbering Schemata {Best Practices}
Depicting conditions id a use case
Second Cut Use Case
User Scenarios:
A Bottom-Up Approach to Use Cases
The Advantage of Scenarios
Use Case Scenario Structure:
Donald Pays For Insurance
Extracting Use Cases from Scenarios
Basic Use Case Documentation
Requirements Categories Addressed
Use Case Diagram Conventions
Drawing a Use Case Diagram
Advanced Use Case Diagrams
Present the transition from business events to use cases
Document proposed user interaction in use cases and use case diagrams
Differentiate between business and system use cases
Depict conditional logic in the use case paradigm
Develop standard, alternate, and exception paths for a use case
Sequence the steps in the use case using a standard numbering scheme
How to Clarify and Confirm Business Requirements with Use Cases
Use cases are considered to be an ideal representation of the functional requirements for a technology solution. Beyond the functions, information technology systems need to meet informational, behavioral, and environmental requirements. This class is designed to teach you how to use these different dimensions of the requirements to flush out critical details of the solution before the project goes too far.
Outline
Introducing a Requirements Taxonomy
Depicting Functional Requirements in a Use Case
Data: The Missing Dimension
Use Cases and Performance Considerations
Of Metrics and Measures
Frequency versus Urgency Considerations
Documenting Informational Accuracy and Volumes
Use Cases and Usability Requirements
Understanding Trainability Issues
Environmental Factors and Use Case Documentation
Prototying versus Use Case Analysis
Use Cases and Business Process Improvement
Top-Down versus Bottom-Up Use Case Development
Use Case Document Component Review
A Business Use Case Template
Identify 18 business requirement categories and map them to use case components
Ascertain and document critical metrics needed at the use case level
Explain the connection between use cases and process models
Review and critique use case documents and use case diagrams
Have a use case development kit for use on future projects
How to Discover Use Cases through Business Events
Business events are the trigger for any usage of information technology. They are also the essence of any business. Because they are what the business community deals with on a day-to-day basis, they are a firm foundation upon which to build. Business event analysis has proven itself to be a very realiable technique for identifying business use cases which in turn drive business requirements collection and documentation.
Outline
Business Events
Definitions
Event Naming Conventions
Finding Events
Identifying Scope
Triggering Business Events
Determining Event Responses
Response Naming Conventions
Documenting Events and Responses
Event Response Tables
Business Event Metrics
From Business Events to Use Cases
Use business event models to initiate and scope an IT project
Transition from business events to use cases
Apply common naming conventions for events and responses
Evaluate the use of business event tables
Capture and document business event metrics
**** How to Gather, Analyze, and Define Business System Requirements
Requirements are the foundation upon which systems are constructed. They are the key connection points between the business and system developers. However, business requirements and system specifications are not the same thing. The two major groups (business and systems) speak different languages and think in different ways. The starting point is the business requirements that are most often written or verbalized by business personnel and reflect how the business wants to operate. It is critical to capture and understand the business requirements before trying to create system specifications.
We provide a proven set of core techniques, methods and tricks to help create clear, unambiguous, complete requirements. Most requirements start with language and to create "good Requirements" you must know and use the "language and techniques" of Requirements Definition. The course also includes a set of techniques to help you evaluate requirements written by someone else.
NOTE: The techniques taught in this course are relevant to traditional, UML or Agile development environments.
Capture (Gather) Requirements
Manage questions and open items lists
Categorize requirements based on focus
Identify the problem with language based requirements
Identify stakeholders
Evaluate a management vision statement
Prepare, perform and follow up requirements interviews
Develop and process surveys
Describe how “analysis by walking around” creates requirements
Use 10 critical requirements questions to guide the requirements capture process
Develop requirements based on business events and responses
Describe how to use the six types of requirements gathering workshop sessions
Identify the pros and cons of prototyping for requirements
Clarify (Understand) Requirements
Apply the five rules of a “good” requirement sentence
Use templates to guide writing requirements
Verify the “testability” of a requirement
Group requirements based on shared characteristics
Decompose requirements into the major types of requirements and their subtypes
Identify and document business rules as requirements
Apply the four rules for managing a group of requirements
Further clarify business rules, performance and constraining requirements
Prioritize requirements
Identify exceptions as requirements
Discuss the difficulties in writing quality, "-ability" requirements (ex: reliability)
Confirm (determine relative importance and feasibility) of requirements
Create a requirement/problem matrix to confirm requirements completeness
Evaluate the completeness of requirements
Confirm feasibility
Identify high-risk requirements and list risk reduction alternatives
Evaluate your requirements development process
Identify the value of good requirements
a)Introduction to Business System Requirements
Business requirements are the foundation upon which systems are constructed. Business Analysis is the most common name for the role that is responsible for capturing, clarifying, confirming and managing business requirements. The primary duties of this critical role include translating business needs into business requirements for information technology solutions. This workshop is designed to give participants a detailed overview of current and emerging tools and techniques that are the core of business analysis.
Outline
The IT Project Landscape
Will the Real Problem Please Stand Up!
The Cost of Errors
Requirements Activities
Current and Future Situations
Analysis of Business Systems Analysis
Two Critical Success Factors of System Development
What is an Integrated Business Solution?
The Uncertainty Principle
The Fate Chart
A Question File
A Problem with Language
Things to Talk About . . .
Categories and Types of Requirements
Another Common Classification
The Three C’s of Requirements Definition
What Do Business Analysts Do?
What Skills Do Business Analysts Need?
The Business Analyst Curriculum
IIBA (International Institute of Business Analysts)
Define the evolving role of business analysts in the information technology landscape
List the 8 major activities that business analysts do
Distinguish between business analysis and system analysis
Predict the consequences of inadequate requirements gathering efforts
Have a basis for further training in critical skills for business analysts
b)How to Get Business Requirements in Interviews and Workshops
Business requirements are the foundation upon which systems are constructed. They are the key connection points between the business and system developers, who often think and speak differently. Capturing business requirements that reflect how the business wants to operate is a critical activity. This course focuses on ways of capturing text-based requirements in a variety of interviewing and workshop situations.
Outline
Ten Critical Requirements Questions
Identifying Stakeholders
User Bill of Rights and Responsibilities
Vision Statements
Interviewing
Characteristics of a Good Interviewer
Interview Steps
Interview Types
Interview options
Interviewing by Email
Survey (Delphi) Technique
Observing
Analysis by Walking Around
Workshop Sessions
Brainstorming
Focus Groups
User Groups
Time Compressed
Identify stakeholders
Manage Questions and Open Items Lists
Evaluate a management vision statement
Prepare, perform and follow up problem and requirements interviews
Develop and process surveys
Describe how to use the six types of requirements gathering workshop sessions
c)How to Get Business Requirements with Business Events and Problem Analysis
Business requirements are the foundation upon which systems are constructed. They are the key connection points between the business and system developers, who often think and speak differently. Capturing business requirements that reflect how the business wants to operate is a critical activity. This course focuses on ways of capturing text-based requirements based on the definition and analysis of business events and business problems that need solving.
Outline
Problem Statements as a Source of Requirements
Defining Business Problems
Problem/Symptom Reduction
Writing Problem Statements
Getting Problem Statements
From Problems to Requirements
Requirements vs. Problems Matrix
Current Business Information Usage
Business Events
Definitions
Event Naming Conventions
Finding Events
Identifying Scope
Determining Event Responses
Response Naming Conventions
Documenting Events and Responses
Develop requirements based on business events and responses
Extract Requirements from Business Data Usage
Identify the pros and cons of prototyping for requirements
Write clear, easy-to-understand problem statements
Relate Problems and Symptoms
Create business requirements from problem statements
d)How to Write Effective, Understandable Business Requirement Statements
Written business requirements define an acceptable information technology system from the subject matter expert’s (SME’s) perspective. Poorly written requirements are the number one cause of IT project failure. Improving you ability to write clear concise, and comprehensive business requirements for IT solutions is the quickest way to get the systems your business needs. This workshop provides a proven set of core techniques, methods and tricks to help business professionals create and clarify business requirements (i.e., meaning the kind of requirements that the IT professionals need to do their job well).
Outline
A Problem with Language
Write a "Good" Requirement Sentence
Do’s
Ex: What’s good about these requirements?
Ex: How would you make them better?
Don’ts
Ex: What’s bad about these requirements?
Ex: How would you fix them?
Making a good requirement better
Peer Reviews Clarify Requirements
Rewriting and Posting Your Requirements for Review
Write "good" business requirements
Distinguish between business requirements and system requirements (specifications)
Categorize requirements based on focus
Identify and document business rules as requirements
Write business requirements that express the what and avoid the how
Use templates to guide writing requirements
Reduce the number of wrong assumptions by using a question file
e)How to Clarify, Confirm, and Complete Business Requirements
Business requirements are the foundation upon which systems are constructed. They are the key connection points between the business and system developers, who often think and speak differently. Clarifying the meaning and confirming the testability of each business requirement is essential to the delivery of a business technology solution that meets, or better, exceeds the customers expectations.
Outline
Q&A Session
How to Interpret a Requirement
Reviewing and Challenging Requirements
Major Subjects of Requirements
Functional Requirements
Identifying Processes and Data Requirements
Performance Requirements
Identifying Performance Requirements
Business Rules and Constraints
Identifying Rules and Constraining Requirements
Using Requirements Subjects to Test Your Understanding of a Requirement
Using a Template to Decompose a Set of Requirements
Applying: Decomposing and Posting Your Requirements for Review
Find missing requirements using the components of a business information system
Recognize the impact that ambiguity has for requirements
Translate business needs into well-structured business requirement statements
Confirm that your requirements are in scope for your project
Apply 3 simple rules to create component-focused business requirements
Evaluate the completeness of your written business requirements
**** How to Write Effective Business Requirements for IT Projects
Written business requirements define an acceptable information technology system from the subject matter expert’s (SME’s) perspective. Poorly written requirements are the number one cause of IT project failure. Improving you ability to write clear concise, and comprehensive business requirements for IT solutions is the quickest way to get the systems your business needs.
This workshop provides a proven set of core techniques, methods and tricks to help business professionals create, clarify, and confirm business requirements (i.e., meaning the kind of requirements that the IT professionals need to do their job well). This is the "business side" of the techniques we teach to business systems analysts and developers to enhance communications and deliver the technology the business community really needs.
Write "good" business requirements
Distinguish between business requirements and system requirements (specifications)
Categorize requirements based on focus
Identify and document business rules as requirements
Group written requirements based on shared characteristics
Evaluate a requirement for testability
Discuss the difficulties in writing Quality, "-ability" requirements (e.g., reliability)
Use templates to guide writing requirements
Evaluate the completeness of your written business requirements
**** How to Model, Analyze, and Improve Business Processes
Business processes are the day to day drivers for most businesses. They are often a key connection between the business and the business customer. They are a combination of business operating procedures, business rules and supporting computer systems. Yet, many business processes are often undocumented, misunderstood, not optimized, error-prone and inefficient.
This training workshop gives you a time proven set of techniques, methods, and tricks to help you model, analyze, and improve both the business and system processes. These approaches will help you create business process models including workflow diagrams and swim lane (activity) diagrams. Creating the business process model will increase your understanding of the actual business processes and business rules involved. With this foundation in place, special techniques will help you analyze the business processes and extract requirements for business process improvement. These techniques will support optimization and improvement of the AS IS business system or requirements for a new TO BE business .
Identify business events
Document existing business processes
Model the AS IS business process
Use the process models to identify business process problems
Localize business process timing conflicts and anomalies
Identify error and exception processes and how they work
Communicate the operation of the business process to other business personnel
Identify process measurements to evaluate initial and continuous improvement
Identify measures to track ongoing progress
Develop a list of process improvements and/or requirements
Document the details of each process using the most appropriate technique
Extract, document, and analyze business rules embedded on the processes
a)Introduction to Business Process Analysis
Business processes and data are the key drivers for all organizations. They are what the business does and how the business keeps track of its activities. They are a combination of business operating procedures, business rules and supporting information technology. Creating visual models of the processes and data is an essential first step to understanding and improving them. Business analysts should be aware of the competing conventions for modeling the business process.
Outline
Communications Channels
Analysis of Business Systems Analysis
Two Critical Success Factors of System Development
What is an Integrated Business Solution?
Things to Talk About . . .
Categories and Types of Requirements
Another Common Classification
The Three C’s of Requirements Definition
Context Models
Business Process Models
Workflow Diagrams
Swimlane Diagrams
Business Process Analysis Techniques
Describe business process models and related analysis techniques
List 5 improvement methods that are based on business process and data models
Distinguish between the three most common process modeling techniques
State the pros and cons of each method
b)How to Model Business Processes using Context Diagrams
Business processes are what a business does. This workshop shows you how to create process models using context diagrams and leveled process models. These models serve as the basis for analyzing, understanding, and improving your organization’s business processes. Without these or similar models, your business process improvement projects are at risk.
Outline
System Modeling - A Short History
Process Models (The Symbols)
A Rigorous Physical Process Model
Process-Based Swim Lanes
Context Level Process Model
Physical Model to Context Diagram
Finishing the Context Diagram
Top Level Process Model
Leveling Process Models
Process Hierarchy
Finding Processes Inside Processes
Process Specifications (requirements)
Business Process Analysis Techniques
Completely Leveled Process Models
Process Model Versus Swimlane Diagram
Comparison of Techniques
Document existing business processes
Model the AS IS business process
Communicate the operation of the business process to other business personnel
Develop context diagrams as a tool for depicting project scope
Decompose business processes models to discover hidden requirements
c)How to Model Business Processes with Swimlane Diagrams
Business processes are what a business does. This workshop shows you how to create process models using Swimlane (a.k.a. Activity) diagrams and Workflow diagrams. These models are an essential prerequisite to analyzing, understanding, and improving your organization’s business processes.
Outline
Activity Diagramming Conventions
Example of an Activity Diagram
Creating an Activity Diagram
Concurrency and More
Modeling Concurrent Activities
Introducing Swimlanes
Activity Diagram with Swimlanes
Modeling Swimlanes
Introducing Object Flow
Modeling Object Flow
When to Use Activity Diagrams
Activity Diagrams versus Process Models
Present complex business logic in activity diagrams
Explain the purpose of swimlane diagrams
Identify potential business problems and bottlenecks using swimlane diagrams
Discover non-value-added processes as candidates for elimination
d)How to Analyze Business Processes using Models
Business processes are what a business does. Creating models of the business process is a critical first step to making intelligent changes to processes without putting your project — or your organization — at risk. This workshop assumes you already know how to create business process diagrams and builds on that knowledge by presenting a series of techniques for analyzing the models to identify potential problems or areas for improvement.
Outline
Overview
Functional Analysis of the Current Situation
Process Model for Functional Analysis
Swimlane Diagram for Functional Analysis
Problem Analysis
Process Model for Problem Analysis
Swimlane Diagram for Problem Analysis
Timing Analysis
How to Show Timings
Process Model for Timing Analysis
Swimlane Diagram for Timing Analysis
Exception Identification
Process Model for Exception Analysis
Information Usage Analysis
Order Document for Information Usage Analysis
Use the process models to identify business process problems
Locate timing conflicts and anomalies
List error and exception process impacts
Develop a list of improvements and/or requirements
e)How to Improve Business Processes using Process Models
Business process improvement transforms organizations by replacing inefficiencies and waste with effective, goal-oriented use of all resources. It removes unnecessary hand-offs and reduces wait times. The concept has evolved over the past two decades and the organizations that started applying these principles in the 90’s are today’s success stories. The challenge is how to do business process improvement without betting the farm.
Outline
Requirements Taxonomy
Requirements Definitions Document
Other course support
Case study
Business Events Defined
Event-Response Tables
Event-Response Diagrams
Error and Exception Events
Business Events and Process
Review of Process Modeling
Identifying Business Functions
Grouping Functions
Developing the Main Line
Adding Support Functions
Dealing with Errors and Exceptions
Identifying Potential Bottlenecks
Simplifying Process Logic
Meeting Constraining Requirements
Implementing Process Measurements
Selecting Functional Controls
Ensuring Business Data Integrity and Completeness
Describe the business process modeling approach to new process design
Perform the steps of business process driven design
Modify a business process model for constraints and performance requirements
Identify appropriate controls for a business process
Evaluate a process model for complexity and instability
Posts
