BR Chapter 5: Investigating the Work

Trawling the Business

Once the blastoff is completed, the requirements analysts start trawling for requirements. They learn the work being done by the business area identified by the blastoff. For convenience and consistency, they partition the work context diagram into business use cases. Each business use case is the functionality needed by the work to make the correct response to a business event. A requirements analyst is assigned to each of the business use cases (the analysts can work almost independently of one another) for further detailed study. Once they understand the work, the requirements analysts work with the stakeholders to decide the best product to help with this work. That is, they determine how much of the work to automate or change, and what effect those decisions will have on the work.

The Brown Cow Model

The Brown Cow model is a way of reducing the complexity of systems modelling by dividing the model’s viewpoints. For example, the business analyst needs to separate the current view of the system from the future. Additionally, he or she must be able to demonstrate a technological view of the system, along with the technologically-agnostic essential view. Suzanne Robertson explains how this works.

Apprenticing


Apprenticing is particularly useful for in-house work. The underlying assumption for apprenticing is that users are currently doing work, and you, as the requirements analyst, have to understand their work. This work could be clerical, commercial, graphic arts, engineering, or almost anything short of brain surgery.
If significant parts of the current work and systems are likely to be reimplemented, then apprenticing is appropriate. Please keep in mind, however, that you will not reimplement the work exactly as is. We recommend that all apprentices refer to the section on essence.



Business Use Case Workshop

The use-case workshop is an organized brain storming meeting. A wide range of knowledge needs to be represented:
  • Customer requirements
  • System design
  • Unit design
  • Rational Unified Process
  • Testing
This means that the group will contain people with different backgrounds, knowledge and experience. A regular setting is to compile half of the group from the development team and the other half from user representatives. In the middle of this is the facilitator. The facilitator should play the role of a moderator - a catalyst for all ideas and wishes.



Comments

  1. Patience NgcoboNovember 14, 2019 at 10:14 PM

    For a period, “requirements gathering” was the term commonly used to describe the task of identifying requirements.
    The term trawling comes from. We use it because it evokes the nature of what we are doing here: fishing. Not idly dangling a line while hoping a fish might come by, but rather methodically running a net through the work to catch every possible requirement.

    Trawling is talking with people to understand their requirements in order to determine the solutions to meet the requirements of the end-users. For trawling there are certain responsibilities of the business analyst to know the requirements of the stakeholders. Business Requirements are needed to be understand by the business analyst to provide the desired output to the end-users. It should be done before determining the solution. Business Use Cases can be used in the projects to understand and explain the work to be done in the project at certain points.

    Product Use Cases are part of the Business Use Cases. The product use cases are used to describe the functionality of the product and requires approval from the business analyst/developer/customer.

    1. Variety of Trawling Techniques Includes:
    2. Abstraction
    3. Apprenticing
    4. Business Events
    5. Brainstorming
    6. Family Therapy
    7. Mind Mapping
    8. Interviewing
    9. Reusing Requirements
    10. Simulation Models (scenarios, prototypes)
    12. Systems Archaeology
    13. Use Case Workshops
    14. Video
    15. Viewpoints

    ReplyDelete
  2. Yogesh JaglanNovember 16, 2019 at 9:43 PM

    Family therapists do not set out to make people agree. Instead, they aim to
    make it possible for people to hear and get an understanding of other individuals’ positions, even if they do not agree with them. In other words, you
    should not expect every stakeholder to agree with every other stakeholder,
    but you should help the stakeholders as a group to accept that other people
    may disagree without necessarily being wrong, and that the need for choices
    and compromises will always arise. Early in the project, identify which mechanisms you will use to deal with these situations when they inevitably occur.
    The field of family therapy is a rich source of ideas about how to work
    effectively with a diverse group of people—such as stakeholders in a requirements trawling process. We use ideas from family therapy as a way of helping
    us to listen to stakeholders and of providing a feedback loop to help avoid
    misinterpretations.

    ReplyDelete
  3. Amanjot kaur chahalNovember 25, 2019 at 10:45 PM

    A business requirements document (BRD) can be considered in two phases. In the first phase of a project, it's a document that sets out all the requirements for the project, including costs, details on implementation, projected benefits, milestones, and timeline for implementation.
    • Nonfunctional Requirement – Characteristics of the system other than the activities it must perform
    • Technical requirements – refers to an organization’s environment, hardware and software
    •Performance requirement – refers to workload measure, throughput and response time
    • Usability requirement – operational characteristics related to the user (UI, work procedures, help and documentation)
    • Reliability requirement – describes the dependability of the system
    • Security requirement – describes user access to certain functions

    ReplyDelete

Post a Comment

Popular posts from this blog

BR Chapter 12: Fit Criteria and Rationale

A satisfying viewpoint (among a large number) of Kent Beck's eXtreme Programming system is its emphasis on composing experiments before composing the code. The experiment characterizes the measuring stick that the executed code must match. The fit model is pretty much something very similar: It is a measuring stick for the necessity. By adding a fit rule to the necessity, you are, basically, composing its experiment. In the event that you are utilizing client stories, at that point we firmly propose that you give specific consideration to the explanation given for the usefulness. This is pretty much equivalent to the justification, and is a significant supporter of winding up with the right item. Composing experiments on the back of the story card ought to accomplish a similar reason as the fit standard we talk about here.  For each of the non-practical necessities yielded by the blog, we presently propose determining the fitting fit rule, affirming it with the partner, and compo...
Read more

BA Chapter 9: Underlying Competencies

Image
Underlying Competencies are a description of the behaviours, characteristics, knowledge, and personal qualities that support the practice of business analysis. BABOK® defines 6 key groups of competencies that a BA is expected to possess. Each competency group constitutes of multiple sub competencies which are as discussed below: (Source: https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/1287/Developing-a-Competency-Model-for-Business-Analysts.aspx) 1.      Analytical Thinking and Problem Solving : These skills are required for business analysts to analyze problems and opportunities effectively, identify which changes may deliver the most value, and work with stakeholders to understand the impact of those changes. Analytical Thinking and Problem-Solving core competencies include: ·            Creative Thinking ·           Decision Making ·  ...
Read more

BR Chapter 6: Scenarios

Image
At this stage of the requirements process, the business analyst has identified the business events as well as the business use case which we referred to as BUC and these correspond to the business events.   Below are some of the techniques the Business Analyst can use to communicate requirements to the stakeholders: Scenarios The Business Analyst can use Scenarios to model and record the BUCs. A scenario is an outline of a plot, or a postulated sequence of steps - it tells the story of a business use case.   The scenario is a neutral medium, and one that is both simple and understandable to all stakeholders.  A business analyst would use a scenario like this to elicit, and then describe, a business use case to its interested stakeholders. The BUC is a discrete amount of functionality; it happens in its own time frame and can be considered separately from other parts of the work’s functionality. The BA model a scenario and use it to reach a...
Read more