Chapter 2 - The Requirement Process (Business Requirements Gathering)

          Chapter 2 tells us about the The Requirement Process in which how we present this processes for the discovering requirements and how you might use it in a process. The book Business Requirement Gathering also describes this as, "we describe a requirements process that we have derived from our years of working in the requirements arena, working with clever people who do clever things, and working on projects in wonderfully diverse domains."

          The Volere Requirement Process was also developed from the different activities and deliverables that had been proven to be the most effective in project and consulting  assignment with clients. The results of this can be the discovering of requirements and processes which are specific principles can be applied.


This is an example diagram of the Volere Requirements Process which details the different activities and deliverables. It also used a stylized data flow notation. Each activity (bubbles) and the deliverables (named arrows or documents) are explained in text. And the dotted lines represent how this process is used with iterative projects.

An example for Great West Life in requirements process is how they handle their customer complaints which is shown in their website. As they are an insurance company, they work directly with a specific customer and talk with them on what kind of service would they want. So, Great-West Life developed a process on how the company would they handle customer complaints with a step-by-step process.


You can also view a more detailed illustration of this step with this pdf file.

Sources: Business Requirements Gathering Book
               https://www.greatwestlife.com/common/about-us/consumer-information/ombudsman.html
               https://www.greatwestlife.com/content/dam/gwl/documents/Customer-complaints.pdf

Comments

  1. Mariane29 October 2019 at 18:17

    While searching for open positions at Great West Life I found a position for Business Systems Analyst, that involves business requirements gathering:

    Role Description

    As a Business Systems Analyst, you will work alongside other IS professionals, and with the business sponsors and business representatives, to evaluate the business case, capture and define the business and systems requirements, and design and develop solutions.

    What You’ll Do
    Translate business requirements into system specifications.
    Convey complex technical issues to diverse and senior audiences.
    Collaborate to elicit and validate business requirements.
    Develop and validate solution design, product configuration, or package criteria with business stakeholders and software developers.
    Collaborate to develop data design and data access methods.
    Contribute to the preparation and execution of test strategies and plans in support of the test execution phase.
    Prepare for, and provide, training to users prior to project implementation.
    Participate in the analysis and conceptual design of the solution, working with the systems architect and software developers to achieve the client and corporate objectives through effective deployment of technology.
    Participate in defining the system requirements and contribute to defining the solution by understanding the customer impact while protecting the integrity of the system.
    Create and maintain configuration rationale and RICEFW specification documents (reports, interfaces, conversions, enhancements, forms and workflows) within the disbursement and collection space of SAP.
    Ensure solutions and configurations meet business requirements and enterprise-level guidelines (e.g. architecture, security, risk).
    Who You Are
    Seek to understand business needs, deliver high quality service to the business, and apply different influencing strategies to convince others to change their opinions or plans.
    Have exceptional interviewing, influencing, facilitation, negotiation and presentation skills.
    Have strong written and verbal communication.
    Have intermediate knowledge of and experience gathering, analyzing, and documenting requirements using various techniques.
    Have intermediate experience preparing business process models, traceability matrices, and using quality management techniques.
    Intermediate level knowledge of the various stages of the analysis process (e.g. planning, stakeholder analysis, modeling, specification, communication, etc.).
    Have 2-5 years working knowledge of the software development lifecycle methodologies (waterfall, iterative, agile).
    University or College education in Computer Science, Computer Engineering, Management Information Systems, Commerce, Business Administration or a related field, or equivalent combination of education and experience.

    Source: https://www.linkedin.com/jobs/view/business-systems-analyst-winnipeg-at-the-great-west-life-1507711891/?refId=a307f450-362f-492f-8313-c13950f6b3b7&originalSubdomain=ca
    Accessed on: 2019-10-29

    ReplyDelete
  2. Parminder Singh30 October 2019 at 16:26

    What is Project Blastoff?
    It is known as “project initiation,” “kickoff,” “charter,” “project launch,” and many other things. We use the term “blastoff” to describe what we are trying to achieve—getting the requirements project launched and flying.The blastoff defines the scope of the business problem and seeks concurrence from the stakeholders that yes, this is the area of the owner’s organization that needs to be improved. The blastoff meeting confirms the functionality to be included in the requirements discovery, and the functionality that is to be specifically excluded.
    The blastoff also confirms the goals of the project. The blastoff group comes to an agreement on the business reason for doing the project, and agrees that there is a clear and measurable benefit to be gained by doing the project. The group also agrees that the product is worthwhile for the business to make the investment.
    Sources - Book pages 14 - 16.

    ReplyDelete
  3. Harleen Virk30 October 2019 at 16:45

    Iterative and Incremental Processes: Iterative and steady programming advancement is a technique for programming improvement that is displayed around a slow increment in include augmentations and a repetitive discharge and redesign design.

    Iterative and steady programming advancement starts with arranging and proceeds through iterative improvement cycles including consistent client input and the gradual expansion of highlights finishing up with the sending of finished programming toward the finish of each cycle.
    Iterative and steady improvement is an order for creating frameworks dependent on delivering expectations. In gradual advancement, various pieces of the framework are created at different occasions or rates and are incorporated dependent on their culmination. In iterative advancement, groups intend to return to parts of the framework so as to reconsider and improve them. Client criticism is counseled to alter the objectives for progressive expectations. Iterative and gradual programming improvement came to fruition in light of defects in the cascade model, a successive plan process in which progress streams consistently downwards. It contrasts from the cascade model since it is recurrent instead of unidirectional, offering a more noteworthy capacity to consolidate changes into the application during the advancement cycle.

    Iterative and gradual advancement can be gathered into the accompanying stages:

    Beginning Phase: Deals with the extent of the undertaking, necessities and dangers at more elevated levels

    Elaboration Phase: Delivers working engineering that conservatives dangers recognized in the commencement stage and fulfills nonfunctional necessities

    Development Phase: Fills in engineering segments steadily with generation prepared code, which is delivered through the investigation, execution, structure and testing of practical prerequisites

    Change Phase: Delivers the framework to the creation working condition
    It is one of the systems of Agile programming improvement, levelheaded bound together procedure and outrageous programming.

    ReplyDelete

Post a Comment

Popular posts from this blog

Chapter 1 - What is Business Analysis?

Hello! Welcome to our Business Analysis blog.  We are Mariane, Harleen, Kent and Parminder, and we are Business Technology Management students at Red River College.  Throughout our Fall term we will be using this blog to share some important concepts regarding Business Analysis.  For our first post, we will start with the basics, and define exactly what is Business Analysis, and other important concepts related to it. According to BABOK, " Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value. "  Business analysis cannot work without having a representative to intermediate these practices within an enterprise. This professional is called a Business Analyst who is responsible for putting in practice the tasks desc...
Read more

Chapter-12 Fit Criteria and Rationale

Image
FORMALITY GUIDE Horse ventures need to have an exact and effectively shareable comprehension of the significance of necessities. It has been our experience that when the task has numerous partners—which is the standard for horse ventures—various partners relegate various implications to prerequisites. Including a reason and a fit basis to every necessity implies it is for all intents and purposes inconceivable for errors to happen. We prescribe that pony ventures incorporate both of these in their necessities. Elephant ventures must utilize methods of reasoning and fit criteria. These tasks are compelled to deliver a composed determination to be given on to some other gathering, either another piece of the association or an outsourcer. Having a detail containing just unambiguous, testable necessities is pivotal to elephant ventures on the off chance that the other party is to comprehend and, at that point convey the right item Scale of Measurement Any prerequisite can be ...
Read more

Chapter 5 - Investigating the Work

The starting point for any product that will be built is the owner's work.  The book mentions that business analysts go "trawling" after business requirements.  The first task in the business requirements gathering process is to understand and investigate the work that is being done. Once that's understood, then the "essence needs to be understood, that is the clean picture of the business, without technology.  In this chapter the "Brown Cow Model" is also introduced. Which is divided into 4 parts:  How-Now: shows the implementation of the work as it currently exists, including physical artifacts, people and processors to do the work.   What-Now: shows the real business policy (essence). No machines, people, or organizational departments. Future-What: shows the business as your owner wants to have it, but still with no technology applies to it. Future-How: shows the idealized future business policy, augmented with the technology and people ...
Read more