Business Analysis Notes - Edge-Locksmith-Services/Locksmith-website GitHub Wiki

Business Requirements Specification (BRS)

A Business Requirements Specification includes all the requirements requested by a client. This generally consists of the product’s purpose, users, the overall scope of the work, all listed features and functions, usability and performance requirements.

https://github.com/Edge-Locksmith-Services/Locksmith-website/blob/main/businessanalysis.md

Reading Notes

SWEBOKwiki Business or Mission Analysis

https://www.sebokwiki.org/wiki/Business_or_Mission_Analysis

  • The Starting Point of Engineering

  • The starting point of engineering any system-of-interest is understanding the socio-economic and technological context in which potential problems or opportunities reside. Then, the enterprise strategic goals and stakeholder needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of business or enterprise decision makers while also taking into account the views of users and customers.

  • Mission Analysis(MA) is part of the larger set of concept definition activities

29148-2018 6.2 Business or mission analysis process

29148-2018.pdf

  • 6.2.1 Purpose

  • The purpose of the Business or Mission Analysis process is to define the business or mission problem or opportunity, characterize the solution space, and determine potential solution class(es) that could address a problem or take advantage of an opportunity

  • 6.2.2 Outcomes

    • As a result of the successful implementation of the Business or Mission Analysis process:

          * a) The problem or opportunity space is defined. 
    
    * b) The solution space is characterized. 
 
    * c) Preliminary operational concepts and other concepts in the life cycle stages are defined.
 
    * d) Candidate alternative solution classes are identified and analyzed.
  
    * e) The preferred candidate alternative solution class(es) are selected.
  
    * f) Any enabling systems or services needed for business or mission analysis are available.
  
    * g) Traceability of business or mission problems and opportunities and the preferred alternative solution classes is established.

  • 6.2.3 Activities and tasks

    • 6.2.3.1 General

      • The project shall implement the following activities and tasks in accordance with applicable organization policies and procedures with respect to the business or Mission Analysis process.

    • 6.2.3.2 Prepare for Business or Mission Analysis

      • This activity consists of the following tasks:

        • Review identified problems and opportunities in the organization strategy with respect to desired organization goals or objectives.

        • Define the business or mission analysis strategy.

        • Identify and plan for the necessary enabling systems or services needed to support business or mission analysis.

        • Obtain or acquire access to the enabling systems or services to be used.

    • 6.2.3.3 Define the problem or opportunity

      • This activity consists of the following tasks:

        • Define preliminary operational concepts in life cycle stages.

          • a) The OpsCon outlines operational aspects of the system solution (new or evolved) in the context of the intended operation of the organization. It provides the lower-level operations-oriented concepts that address a part of the organization's ConOps
          • b) The Acquisition Concept describes the way the system solution will be acquired including aspects such as stakeholder engagement, source of the solution, requirements definition, solicitation and contracting issues, design, production and verification
          • c) The Deployment Concept describes the way the system solution will be validated, delivered and introduced into operations
          • d) The Support Concept describes the desired support infrastructure and manpower considerations for supporting the system solution after it is deployed. A support concept addresses operating support, engineering support, maintenance support, supply support and training support.
          • e) The Retirement Concept describes the way the system will be removed from operation and retired, including the disposal of any hazardous materials used in or resulting from the process

        • Identify candidate alternative solution classes that span the potential solution spaces

    • 6.2.3.5 Evaluate alternative solution classes

      • This activity consists of the following tasks:

        • Assess each alternative solution class

        • Select the preferred alternative solution classes

    • 6.2.3.6

      • This activity consists of the following tasks:

        • Maintain traceability of business or mission analysis

        • Provide key[artifacts and] information items that have been selected for baselines.

29148-2018 8.2.2 BRS example outline

29148-2018.pdf

image

Figure 5- Example BRS outline

29148-2018 9.3 Business requirements specification (BRS) content

29148-2018.pdf

  • 9.3.1 BRS overview

    • This sub clause defines the normative content of the BRS. The project shall produce the following information item content in accordance with the project’s policies with respect to the business requirements specification. Organization of the content such as the order and section structure may be selected in accordance with the project’s information management policies.

  • 9.3.2 Business purpose

    • Describe at the organization level the reason and background for which the organization is pursing new business or changing the current business in order to fit a new management environment.

  • 9.3.3 Business Scope

    • Define the business domain under consideration by:
      • a) identifying the business domain by name
      • b) defining the range of business activities included in the business domain concerned. The scope can be defined in terms of divisions in the organization and external entities that relate directly to the business activities, or functions to be performed by the business activities. It is helpful to show environmental entities that are outside of the scope
      • c) describing the scope of the system being developed or changed. The description includes assumptions on which business activities are supported by the system

  • 9.3.4 Business overview

    • Describe major internal divisions and external entities of the business domain concerned and how they are interrelated. A diagrammatic description is recommended.

  • 9.3.5 Major Stakeholders

    • List the major stakeholders or the classes of stakeholders and describe how they will influence the organization and business, or can be related to the development and operation of the system.

  • 9.3.6 Business environment

    • Define, external and internal environmental factors that should be taken into consideration in understanding the new or existing business and eliciting the stakeholder requirements for the system to be developed or changed.

  • 9.3.7 Mission, goals, and objectives

    • Describe the business results to be obtained through or by the proposed system.

  • 9.3.8 Business model

    • Describe methods by which the business mission is excepted to be achieved. The description should be concentrated on the methods supported by the system to be devolved or changed with the items such as product and services, geographies and locales, distribution channels, business alliance and partnership, and fiance and revenue model.

  • 9.3.9 Information environment

    • Describe the overall strategy for the organization level decisions on common bases for multiple information systems.
      • a) project portfolio - when multiple system projects are running or planned to pursue the same business goal, the priority, relative positioning and possible constraints come from the portfolio management strategy
      • b) long term system plan - when common system infrastructure or architecture has been decided or planned, it should be described as constraints on possible design decisions
      • c) database configuration - an organization level database configuration plan and possible constraints on availability and accessibility of organization global data should be specified.

  • 9.3.10 Business processes

    • Provide description of the procedures of business activities and possible system interfaces within the processes. The purpose of this information item is to represent how and in which context the system supports the business activities.

  • 9.3.11 Business operational policies and rules

    • Describe logical propositions applied in conducting the business processes. The propositions may be conditions to start, branch and terminate the sequence of the business activities in the business processes

  • 9.3.12 Business operational constraints

    • Describe conditions to be imposed in conducting the business process. The conditions may be on a performance constraint or may be from a management requisite such as 'every occurrence of the process shall be monitored and recorded

  • 9.3.13 Business operational modes

    • Describe methods to conduct the business operation in an unsteady state.An unsteady state of business operation includes a manual operation mode when the proposed system is not available due to some unexpected situation like an accident or natural disaster.

  • 9.3.14 Business operational quality

    • Define the level of quality required for the business operation

  • 9.3.15 Business structure

    • Identify and describe the structures in the business relevant to the system, such as organizational structure, role and responsibility structures, geographic structures and resource sharing structures. There may be a need to align the system functions to these structures and to support future structural changes

  • 9.3.16

    • High-level operational concept
      • Describe the proposed system in a high-level manner, indicating the operational features that are to be provided without specifying design details.
        • a) operational policies and constraints
        • b) description of the proposed system
        • c) modes of system operation
        • d) user classes and other involved personnel
        • e) support environment.

  • 9.3.17 High-level operational scenarios

    • Describe examples of how users/operators/maintainers will interact with the system in important contexts of use. The high-level scenarios are described for an activity or a series of activities of business processes supported by the system

  • 9.3.18 Other high-level life-cycle concepts

    • Describe how the system of interest is to be acquired, deployed, supported and retired.

  • 9.3.19 Project constraints

    • Describe constraints to performing the project within cost and schedule.

An Introduction to Business Analysis and the Business Analyst Process Framework

https://www.bridging-the-gap.com/business-analysis-process/

  • Step 1 – Get Oriented
    • Often as business analysts, we are expected to dive into a project and start contributing as quickly as possible to make a positive impact. Sometimes the project is already underway.
    • Taking some time, whether that’s a few hours, few days, or at the very most a few weeks, to get oriented will ensure you are not only moving quickly but also able to be an effective and confident contributor on the project.
    • Clarifying your role as the business analyst so that you are sure to create deliverables that meet stakeholder needs.
    • Determining the primary stakeholders to engage in defining the project’s business objectives and scope, as well as any subject matter experts, to be consulted early in the project.
    • Understanding the project history so that you don’t inadvertently repeat work that’s already been done or rehash previously made decisions.
    • Understanding the existing systems and business processes so you have a reasonably clear picture of the current state that needs to change.
  • Step 2 - Discover the Primary Business Objectives
    • It’s very common for business analysts and project managers to jump right in to defining the scope of the project. However, this can lead to unnecessary headaches. Uncovering and getting agreement on the business needs early in a project and before scope is defined is the quickest path forward to a successful project.
    • Discovering expectations from your primary stakeholders – essentially discovering the “why” behind the project.
    • Reconciling conflicting expectations so that the business community begins the project with a shared understanding of the business objectives and are not unique to one person’s perspective.
    • Ensuring the business objectives are clear and actionable to provide the project team with momentum and context while defining scope and, later on, the detailed requirements.
  • Step 3 – Define Scope
    • A clear and complete statement of scope provides your project team the go-forward concept to realize the business needs. Scope makes the business needs tangible in such a way that multiple project team participants can envision their contribution to the project and the implementation.
    • Defining a solution approach to determine the nature and extent of technology and business process changes to be made as part of implementing the solution to the primary business objectives.
    • Drafting a scope statement and reviewing it with your key business and technology stakeholders until they are prepared to sign-off or buy-in to the document.
    • Confirming the business case to ensure that it still makes sense for your organization to invest in the project
  • Step 4 – Formulate Your Business Analysis Plan
    • Your business analysis plan will bring clarity to the business analysis process that will be used to successfully define the detailed requirements for this project. Your business analysis plan is going to answer many questions for you and your project team.
    • Choosing the most appropriate types of business analysis deliverables, given the project scope, project methodology, and other key aspects of the project context.
    • Defining the specific list of business analysis deliverables that will completely cover the scope of the project and identifying the stakeholders who will be part of the creation and validation of each deliverable.
    • Identifying the timelines for completing the business analysis deliverables.

Research/ Information Literacy

https://sites.google.com/site/profvanselow/success/research

  • CRI Skill: Research
    • Description
      • Identifying and collecting credible, reliable information from many sources
    • Aspects
      • Collect
        • Think about the information and resources needed to help find a solution before researching.
        • Collect information from different sources (such as books, articles, and websites).
        • Keep hypothesis in mind while collecting.
        • Keep track of where all information comes from.
    • Identify
      • When information is needed, know where to find different kinds of information.
      • Use the Internet to find information and evidence for research (e.g. scholarly articles).
      • Evaluate
      • Separate fact from fiction.
      • Use the library for research.
    • Action Steps
      • Explore library resources with an expert
      • Learn about academic databases and how to use them
      • Get help from the school's writing center to learn how to find and collect information
      • For research assignments, gather information from multiple credible resources that support different views

Software Requirements Ch. 4 The Business Analyst

  • The Business Analyst role
    • The business analyst is the individual who has the primary responsibility to elicit, analyze, document, and validate the needs of the project stakeholders
    • The BA plays a central role in collecting and disseminating product information, whereas the project manager takes the lead in communicating project information.
    • Business analyst is a project role, not necessarily a job title. Synonyms for business analyst include requirements analyst, systems analyst, requirements engineer, requirements manager, application analyst, business systems analyst, IT business analyst, and simply analyst.
    • Don’t assume that any talented developer or knowledgeable user can automatically be an effective business analyst without training, resource materials, and coaching.
  • The business analyst’s tasks
    • The analyst must first understand the business objectives for the project and then define user, functional, and quality requirements that allow teams to estimate and plan the project and to design, build, and verify the product.
    • The BA is also a leader and a communicator, turning vague customer notions into clear specifications that guide the software team’s work.
      • Define business requirements Your work as a BA begins when you help the business or funding sponsor, product manager, or marketing manager define the project’s business requirements.
      • Plan the requirements approach The analyst should develop plans to elicit, analyze, document, validate, and manage requirements throughout the project
      • Identify project stakeholders and user classes Work with the business sponsors to select appropriate representatives for each user class, enlist their participation, and negotiate their responsibilities
      • Elicit requirements A proactive analyst helps users articulate the system capabilities they need to meet their business objectives by using a variety of information-gathering techniques
      • Analyze requirements Look for derived requirements that are a logical consequence of what the customers requested and for implicit requirements that the customers seem to expect without saying so. Use requirements models to recognize patterns, identify gaps in the requirements, reveal conflicting requirements, and confirm that all requirements specified are within scope
      • Document requirements The analyst is responsible for documenting requirements in a well-organized and well-written manner that clearly describes the solution that will address the customer’s problem
      • Communicate requirements You must communicate the requirements effectively and efficiently to all parties. The BA should determine when it is helpful to represent requirements by using methods other than text, including various types of visual analysis models, tables, mathematical equations, and prototypes
      • Lead requirements validation Analysts are the central participants in reviews of requirements. You should also review designs and tests that were derived from the requirements to ensure that the requirements were interpreted correctly
      • Facilitate requirements prioritization The analyst brokers collaboration and negotiation among the various stakeholders and the developers to ensure that they make sensible priority decisions in alignment with achieving business objectives.
      • Manage requirements A business analyst is involved throughout the entire software development life cycle, so she should help create, review, and execute the project’s requirements management plan. After establishing a requirements baseline for a given product release or development iteration, the BA’s focus shifts to tracking the status of those requirements, verifying their satisfaction in the product, and managing changes to the requirements baseline

Software Requirements Ch. 5 Establishing the business requirements

  • Defining business requirements
    • “Business requirements” refers to a set of information that, in the aggregate, describes a need that leads to one or more projects to deliver a solution and the desired ultimate business outcomes. Business opportunities, business objectives, success metrics, and a vision statement make up the business requirements.
  • Identifying desired business benefits
    • The business requirements set the context for, and enable the measurement of, the benefits the business hopes to achieve from undertaking a project. Organizations should not initiate any project without a clear understanding of the value it will add to the business. Set measurable targets with business objectives, and then define success metrics that allow you to measure whether you are on track to meet those objectives.
    • The business benefit has to represent a true value for the project’s sponsors and to the product’s customers.
  • Product Vision and project scope
    • The product vision succinctly describes the ultimate product that will achieve the business objectives
    • The project scope identifies what portion of the ultimate product vision the current project or development iteration will address
    • The vision applies to the product as a whole. The vision should change relatively slowly as a product’s strategic positioning or a company’s business objectives evolve over time.
    • The scope pertains to a specific project or iteration that will implement the next increment of the product’s functionality. Scope is more dynamic than vision because the stakeholders adjust the contents of each release within its schedule, budget, resource, and quality constraints.
  • Conflicting business requirements
    • Business requirements collected from multiple sources might conflict
    • The focus should be on delivering the maximum business value to the primary stakeholders. It’s easy to be distracted by superficial product characteristics that don’t really address the business objectives
  • Vision and scope document
    • The vision and scope document collects the business requirements into a single deliverable that sets the stage for the subsequent development work
    • The owner of the vision and scope document is the project’s executive sponsor, funding authority, or someone in a similar role. A business analyst can work with this individual to articulate the business requirements and write the vision and scope document. Input to the business requirements should come from people who have a clear sense of why they are undertaking the project. These individuals might include the customer or development organization’s senior management, a product visionary, a product manager, a subject matter expert, or members of the marketing department.
  1. Business requirements

Projects are launched in the belief that creating or changing a product will provide worthwhile benefits for someone and a suitable return on investment. The business requirements describe the primary benefits that the new system will provide to its sponsors, buyers, and users. Business requirements directly influence which user requirements to implement and in what sequence.

1.1 Background

Summarize the rationale and context for the new product or for changes to be made to an existing one. Describe the history or situation that led to the decision to build this product.

1.2 Business opportunity

For a corporate information system, describe the business problem that is being solved or the process being improved, as well as the environment in which the system will be used. For a commercial product, describe the business opportunity that exists and the market in which the product will be competing

1.3 Business objectives

Summarize the important business benefits the product will provide in a quantitative and measurable way.

1.4 Success metrics

Specify the indicators that stakeholders will use to define and measure success on this project. Identify the factors that have the greatest impact on achieving that success, including factors both within and outside the organization’s control.

1.5 Vision statement

Write a concise vision statement that summarizes the long-term purpose and intent of the product. The vision statement should reflect a balanced view that will satisfy the expectations of diverse stakeholders. It can be somewhat idealistic but should be grounded in the realities of existing or anticipated markets, enterprise architectures, corporate strategic directions, and resource limitations

1.6 Business risks

Summarize the major business risks associated with developing—or not developing—this product. Risk categories include marketplace competition, timing issues, user acceptance, implementation issues, and possible negative impacts on the business. Business risks are not the same as project risks, which often include resource availability concerns and technology factors

1.7 Business assumptions and dependencies

An assumption is a statement that is believed to be true in the absence of proof or definitive knowledge. Business assumptions are specifically related to the business requirements. Incorrect assumptions can potentially keep you from meeting your business objectives.

  1. Scope and limitations

Many projects suffer from scope creep—rampant growth as more and more functionality gets stuffed into the product. The first step to controlling scope creep is to define the project’s scope. The scope describes the concept and range of the proposed solution. The limitations itemize certain capabilities that the product will not include that some people might assume will be there. The scope and limitations help to establish realistic stakeholder expectations because customers sometimes request features that are too expensive or that lie outside the intended project scope. 2.1 Major features

List the product’s major features or user capabilities, emphasizing those that distinguish it from previous or competing products

2.2 Scope of initial release

Summarize the capabilities that are planned for inclusion in the initial product release. Scope is often defined in terms of features, but you can also define scope in terms of user stories, use cases, use case flows, or external events. Also describe the quality characteristics that will let the product provide the intended benefits to its various user classes

2.3 Scope of subsequent releases

If you envision a staged evolution of the product, or if you are following an iterative or incremental life cycle, build a release roadmap that indicates which functionality chunks will be deferred and the desired timing of later releases. Subsequent releases let you implement additional use cases and features, as well as enriching the capabilities of the initial ones. The farther out you look, the fuzzier these future scope statements will be and the more they will change over time. Expect to shift functionality from one planned release to another and to add unanticipated capabilities. Short release cycles provide frequent opportunities for learning based on customer feedback.

2.4 Limitations and exclusions

List any product capabilities or characteristics that a stakeholder might expect but that are not planned for inclusion in the product or in a specific release. List items that were cut from scope, so the scope decision is not forgotten. Maybe a user requested that she be able to access the system from her phone while away from her desk, but this was deemed to be out of scope. State that explicitly in this section: “The new system will not provide mobile platform support.”

  1. Business context

This section presents profiles of major stakeholder categories, management’s priorities for the project, and a summary of some factors to consider when planning deployment of the solution.

3.1 Stakeholder profiles

Stakeholders are the people, groups, or organizations that are actively involved in a project, are affected by its outcome, or are able to influence its outcome

  • The major value or benefit that the stakeholder will receive from the product. Stakeholder value could be defined in terms of:
    • Improved productivity.
    • Reduced rework and waste.
    • Cost savings.
    • Streamlined business processes.
    • Automation of previously manual tasks.
    • Ability to perform entirely new tasks.
    • Compliance with pertinent standards or regulations.
    • Improved usability compared to current products.
  • Their likely attitudes toward the product.
  • Major features and characteristics of interest.
  • Any known constraints that must be accommodated. 3.2 Project priorities

To enable effective decision making, the stakeholders must agree on the project’s priorities. One way to approach this is to consider the five dimensions of features, quality, schedule, cost, and staff. The project manager’s challenge is to adjust the degrees of freedom to achieve the project’s success drivers within the limits imposed by the constraints

3.3 Deployment considerations

Summarize the information and activities that are needed to ensure an effective deployment of the solution into its operating environment. Describe the access that users will require to use the system, such as whether the users are distributed over multiple time zones or located close to each other. State when the users in various locations need to access the system. If infrastructure changes are needed to support the software’s need for capacity, network access, data storage, or data migration, describe those changes. Record any information that will be needed by people who will be preparing training or modifying business processes in conjunction with deployment of the new solution.

My Business Analysis

To complete the BRS I met with the main stakeholder and found pertinent information which I then transcribed to have access to, I also did online research form different sources to found out what a website designed for a locksmith company would entail and took notes from these sites. One of the sites I used for research was a fellow locksmith company in the area to see how they have their website structured and what it contains.