Full completed BRM Notes from Week 1 - 11 PDF

Preview

Summary

BRM NOTES WEEK 1: INTRO TO BUSINESS ANALYSIS WEEK 2: REQUIREMENTS PROCESS WEEK 3: REQUIREMENTS ELICITATION WEEK 4: BUSINESS PROCESS MODELLING WEEK 5: DATA MODELLING DEVELOPMENT WEEK 6: SOFTWARE REQUIREMENTS SPECIFICATION (SRS) AND AGILE WEEK 7: AGILE DEVELOPMENT WITH USER STORIES WEEK 8: USE CASE MO...

Description

BRM NOTES WEEK 1: INTRO TO BUSINESS ANALYSIS

2

WEEK 2: REQUIREMENTS PROCESS

7

WEEK 3: REQUIREMENTS ELICITATION

16

WEEK 4: BUSINESS PROCESS MODELLING

26

WEEK 5: DATA MODELLING

36

WEEK 6: SOFTWARE REQUIREMENTS SPECIFICATION (SRS) AND AGILE DEVELOPMENT

45

WEEK 7: AGILE DEVELOPMENT WITH USER STORIES

54

WEEK 8: USE CASE MODELLING

58

WEEK 9: OBJECT ORIENTED MODELLING

71

WEEK 10: INTERACTION MODELLING WITH SEQUENCE DIAGRAMS

80

WEEK 11: STATE AND EVENT MODELLING WITH STATE TRANSITION DIAGRAM

88

WEEK 1: INTRO TO BUSINESS ANALYSIS Who are Stakeholders? ● An individual, team or organisation who have interest in, or participate in the development of requirements and relative software system ● Stakeholders have different roles based on their interest and responsibility in an organisation ● Failure to discover all stakeholders can mean failure to discover all their needs ● Eg. Project Manager, Business Analyst, Sponsor, End User, Owner, Subject Matter Expert etc. ● Failure to discover all stakeholders can mean failure to discover all their needs. ○ Find all parties who will be affected by the product and find their requirements/needs Stakeholder Classes: Roles ● Users: They have an interest in having a product that does their work correctly. Will be ultimately be hands on operators of the product ● Sponsor: An owner representative and represents the owner's interest. Pays for the development of the product ● Subject Matter Experts: People who have specialised knowledge of the business subject, individuals with in-depth knowledge of a topic relevant to the business need or solution scope. ● Customer: Buys the product one it’s developed. They are a stakeholder outside the boundary of a given organisation or organisational unit. Knowing this person well helps to understand what he/she finds valuable and what appeals to them ● Developers/Software Engineers: Are responsible for the construction of software applications. Areas of expertise among developers or software engineers include particular languages or application components ● Project Manager: Are responsible for managing the work required to deliver a solution that meets a business need, and for ensuring that the project’s objectives are met while balancing the project constraints, including scope, budget, schedule, resources, quality, risk and others

What are Requirements? ● A condition or capability needed by a stakeholder to solve a business problem or achieve an objective ● A requirement is a usable representation of a need. ○ Focuses on understanding what kind of value could be delivered if a

requirement is fulfilled ○ May be a document, but can vary depending on the circumstances ● A statement of need that must be met by a particular product or service to solve a business problem or achieve an objective ● Eg. A customer must be able to place an order for a book on the phone in less than 5 minutes between 9am and 5pm

Why Requirements? ● Requirements are needed for: ○ Developing a new or altering an existing business process, service or product eg. order management process ○ Developing a new or altering an existing software system eg. online order processing system

What is Modelling? ● Is an abstraction ● A representation of a real world entity or object or subject of interest ○ Eg. business process model, data model, software system model etc. ● AS IS (Current State) and TO BE (Future State) Models

What is Business Requirements Modelling? ● Involves understanding the client’s business problems and needs (requirements), and developing a set of diagrams knows as requirements models, each of which focuses on a different aspect of the user’s needs (business needs) ○ People or Stakeholders (Modelling) ○ Process (Modelling) ○ Data (Modelling) ○ Object Oriented Modelling Stakeholders Modelling

Process Modelling ● The analytical representation or illustration of an organisation’s business processes ● It is used to map out an organisation’s current (or AS IS) process to create a baseline for process improvements and to design future (or TO BE) processes

Data Modelling ● Data Models model people, things, places and concepts about whom data is required ● Data Models identifies the entities or objects that the organisation will need to hold data about

Object Oriented Modelling ● Object Oriented Models (OO models) use Unified Modelling Language (UML) Examples of OO Models: ● Use Case Diagram ● Class Diagram ● Sequence Diagram ● State and Event Diagram

What is Business Analysis? ● The practice of enabling change in an enterprise by defining its needs and rationale for change, and then design, describe and recommend solutions that deliver value to its stakeholders ● Business Analysis can be used to understand the current state, to define the future state, and to determine the activities required to move from the current to the future state

Role of a Business Analyst (BA) ● ● ● ● ● ● ● ●

Business/Domain knowledge: Understand what does the business do Understand problems and needs of business (requirements) Manage stakeholders and communication with them Modelling: Develop and communicate business requirements models Review business requirements with stakeholders Obtain Sign Off Recommend software solutions, alternatives and cost estimates Engage in Software testing

BA Skills/Competencies ● Analytical Thinking and Problem Solving Skills ○ Creative thinking, Decision making, Learning, Problem solving, Systems thinking, Conceptual thinking, Visual thinking ● Behavioural Characteristics/Skills ○ Ethics, Accountability, Trustworthiness, Organisation and time management, Adaptability ● Business Knowledge ○ Business acumen, Industry knowledge, Organisation knowledge, Solution knowledge, Methodology knowledge ● Communication Skills ○ Verbal communication, Non-verbal communication, Written communication, Listening ● Interaction Skills ○ Facilitation, Leadership and influencing, Teamwork, Negotiation and Conflict Resolution, Teaching ● Tools and Technology ○ Office productivity tools and Technology, Business analysis tools and technology, Communication tools and technology

Techniques used by a BA ● Interviews, Surveys/Questionnaires, Requirements workshops, Observation, Prototyping ● Modelling: ○ Stakeholders Modelling ○ Process Modelling via BPMN 2.0 ○ Data Modelling via ERD and Data Dictionary ○ Object Oriented Modelling

WEEK 2: REQUIREMENTS PROCESS Requirements Engineering ● Software system development is driven by “Requirements Engineering” ● RE refers to the process of defining, documenting, and maintaining requirements and to the subfields of systems engineering and software concerned with this process

The Waterfall System Development Process ● The waterfall model is a sequential design process, used in software development processes, in which progress is seen as flowing steadily downwards through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance.

● The waterfall model maintains that one should move to another phase only when its preceding phase is reviewed and verified ● One phase is completed in its entirety before moving on to the next phase ● Rarely revisit a phase once it is completed.

Agile System Development Process ● A group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, crossfunctional teams. ● Promotes adaptive planning, evolutionary development, early delivery, continuous improvement and encourages rapid and flexible response to change, focusing on delivering working software with the minimum amount of work

Scrum ● An iterative and incremental agile software development framework for managing product development. ● "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal", and challenges assumptions of the "traditional, sequential approach" to product development. ● A key principle is its recognition that during a project the customers can change their minds about what they want and need (often called "requirements churn"), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. The Scrum process Sprint ● The basic unit of development in Scrum ○ A “timeboxed” effort, meaning it is restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month. ● Each sprint is started by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and ended by a sprint review-and-retrospective meeting, where the progress is reviewed and lessons for the next sprint are identified.

Iterative and incremental development ● Develops a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system. ● Learning comes from both the development and use of the system , where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. ● Incremental development slices the system functionality into increments (portions). ○ In each increment, a slice of functionality is delivered through crossdiscipline work, from the requirements to the deployment.

Requirements Process ● Process is a set of steps (phases) that a software program goes through when developed. ● It is a structure imposed on the development of a software product ○ Requirements process includes: ■ stages/phases (e.g. Planning, Analysis, Elicitation, Specification, etc.) ■ activities and tasks (within each stage/phase) ■ Techniques ■ Tools for discovering the purpose of the “software”, and the needs of the users to support their activities. ■ Identify stakeholders and their needs ■ Documenting needs/requirements in the form of a model that is amenable to analysis, communication and subsequent implementation

Requirements Process Stages: 1. Requirements Elicitation ● Process of seeking, uncovering, acquiring, and elaborating requirements for computer-based systems. ● Requirements are elicited rather than just captured or collected. This implies there are discovery, emergence, and development elements to the elicitation process. ● A complex process involving many activities with a variety of available techniques, approaches, and tools. ● Identifies the various sources of requirements and analyses all the relevant stakeholders. ● One verified, various elicitation techniques can apply: ○ Brainstorming, Interviews, Requirements Workshops, Document Analysis, Observation, Prototyping, Survey questionnaires.

2. Requirements Analysis & Modelling ● Requirements Analysis: Determining whether the stated requirements are clear, complete, consistent and unambiguous, and resolving any apparent conflicts. ● Requirements Modelling: Developing a set of diagrams known as requirements models, each of which focuses on a different aspect of the users' needs. ○ Business Process Modelling with BPMN ○ Data Modelling with ERD ○ Object Oriented Modelling with UML

3. Requirements Specification & Requirements Validation ● Requirements Specification: Requirements are specified and documented in a software requirements specification (SRS) document. ● Requirements Verification and Validation: Checking that the documented requirements and models are consistent and meet stakeholder needs. Requirements Quality ● Requirements are SMART ○ Specific: A good requirement is specific and not generic. It is clearly defined and not open to mis-interpretation when read by others. ○ Measurable: Whether you will be able to verify the completion of the project and that requirement. You should avoid signing up for any requirement that cannot be verified as complete. ○ Attainable: Ensures that the requirement is physically able to be achieved given existing circumstances. Can they be implemented? ○ Realistic: Whether the requirement is realistic to deliver when considering other constraints of the project and requirements. ■ Are the requirements and other project constraints in their entirety, able to be met? E.g. stakeholders access, time constraints, skills of team etc, ○ Time-bound (timely, traceable): Each requirement should be timebound or specify by when or how fast a requirement needs to be completed or executed. Also whether a requirement is traceable? 4. Requirements Management ● Requirements Management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. ● It is a continuous process throughout a project. ● Ensures that an organisation documents, verifies, and meets the needs and expectations of its customers, and internal or external stakeholders. ● Tools eg.: Requirements Backlog, Burndown charts, Requirements Register or Excel Spreadsheet, IBM JazzHub, JIRA

Types of requirements: Functional Requirements (things product/system must do) ● Describes the behavior and information that the solution will manage. ● They describe capabilities the system will be able to perform in terms of behaviors or operations—specific information technology application actions or responses. ● Examples: ○ The software system should be able to produce a monthly sales report for a given month. ○ The system shall enable hotel guests to book a room online. Non-Functional Requirements (qualities product/system must have) ● Describes environmental conditions under which the solution must remain effective or qualities that the systems must have. ● AKA quality or supplementary requirements. ○ These can include requirements related to capacity, speed, safety, security, availability and the information architecture and presentation of the user interface. ○ Examples include software performance requirements, external interface requirements, software design constraints and software quality attributes. ● Examples: ● The software system should be able to produce a monthly sales report for a given month in less than 5 seconds ● The software system should be able to produce a monthly sales report for a given month in less than 5 seconds and display it on iPad Requirements Activities/Tasks Requirements are: ● Identified ● Captured ● Managed ● Communicated ● Prioritised ● Estimated ● Scoped ● De-scoped ● Signed Off

Requirements Elicitation: Stakeholders Analysis Identifying and understanding stakeholders ● Questions to consider when identifying the stakeholders and analysing the impact of new changes ○ Who is the new change and business transformation going to affect (who all will be impacted?)? ○ Who has an interest in these new changes and this project? ○ Who and how are you going to communicate these changes/requirements to the stakeholders? What is the communications plan? ○ Who are critical to this business transformation? Who can influence? ○ Who is paying for the project? ○ Who will be managing, reviewing and signing off? Why do it? ● Stakeholders analysis involves identifying all the relevant stakeholders and eliciting and understanding their needs (and any issues with the current system) ● Stakeholder analysis is the review and consideration of the impact stakeholders have on your business. Companies need to understand the interests of each stakeholder ● To understand the importance and influence of individual stakeholders on the project ● To utilise the vast amount of information and knowledge that stakeholders hold to find workable, efficient and sustainable solutions ● To gain support from powerful stakeholders which can help you to win more resources - this makes it more likely that your projects will have less obstacles and conflicts, hence be successful

Stakeholders Analysis and Identification Technique: Stakeholders Map/Register/Table

Empathy Map

● A visualisation tool designed to help teams use Emotional Intelligence to gain insight into a target group ● Provides a series of prompts to identify a target group’s requirements, rather than its own ● Example: ○ A product development team could use an empathy Map to consider how people might respond to a new device or a pain point ○ A manager might use one to asses his or her team’s reaction to a new workflow

What do we want from users? ● What? ○ Understand their problems - what is limiting them? ○ Understand the requirements of the current and future system ○ Understand the scope ○ Understand the requirements priority

Conflicts and Challenges ● Why are there conflicts? ○ Empires, power and fear ● Why are there differences between stakeholders? ○ Different views, time-frames, granularity, experiences ● What Influences these differences? ○ Communication, Openness

Understanding Conflicts ● Stakeholders may have differing or conflicting requirements ● Not understanding stakeholder differences can lead to ○ Poor communication ○ Miscommunication ○ Conflicts and failed software projects ● Without an understanding of what causes the conflicts, it is very difficult to determine appropriate trade-offs ● Facilitate communication between the stakeholders who are in conflict over the requirements in order to resolve the issue ● Conflicts may be resolved through formal meetings among affected stakeholders, through research, resolution by third party, or other methods as appropriate

WEEK 3: REQUIREMENTS ELICITATION Objectives ● Plan for and carry out elicitation of requirements from stakeholders and other sources ● Understand the benefits and drawbacks of different elicitation techniques ● Identify appropriate technique for eliciting requirements for a given situation ● Understand the differences between requirements elicitation for existing systems vs the new system

Requirements Elicitation Process ● The following activities could be included in any requirements elicitation process: ○ Understanding the application domain & the properties of the existing system ○ Identifying the sources of requirements ○ Identifying and analyzing all the relevant stakeholders ○ Selecting the approaches, techniques and tools for elicitation ○ Eliciting the requirements from the stakeholders and other sources using the selected techniques, approaches and tools

Present vs Future system ● Get a clear understanding of ○ The overall objectives of the enterprise ○ What do individual users of the system want to achieve in their job ● Understand ○ How the business is operating at present ○ How people are working right now and what they cannot do with the existing system ○ The problems with and inadequacies of the current system ● Hence, discover the “new requirements”

Requirements Elicitation Technique: Interview ● An interview is a systematic approach designed to elicit information from a person or group of people ○ One-on-one interviews are typically most common ○ In a group interview (with more than one interviewee in attendance) the interviewer must be careful to elicit responses from all attendees ● Interviewer formally or informally directs questions to a stakeholder ○ Used to explore issues and can collect some quantitative, but most qualitative data ● Widely used elicitation and fact finding technique and requires the most skill and sensitivity ● Requires good planning and preparation, good interpersonal skills and an alert and responsive frame of mind during the interview,and good analysis skills post interview ● Ensure that the biases and predispositions of the interviewer do not interfere with a free exchange of information ● Structured interview: whe...