Team 4 - Great West Life Assurance - Business Analysis - Red River College

What are the types of non-functional requirements? Following are the non-functional requirement types we use and recommend. Each number is the identifier allocated to that type of requirement in the requirements specification template. 1. Look and Feel : the spirit of the product’s appearance 2. Usability and Humanity : the product’s ease of use, and any special considerations needed for a better user experience 3 . Performance: how fast, how safe, how many, how available, and how accurate the functionality must be 4. Operational: the operating environment of the product, and any considerations that must be taken into account for this environment 5. Maintainability and Support : expected changes, and the time needed to make them; also specification of the support to be given to the product 6. Security: access, confidentiality, recoverability, and auditability of the product 7. Cultural and Political : special requirements that come about because of the culture and customs...

In this chapter we move away from the utopian world that lies above the "brown cow" model and go down to the reality of the "Future How" analysis. In the past chapters we learned how to understand the essence of the business and what is possible to improve and automate. Looking at the "Future How" the Business Analyst's task is to achieve the desired outcome for the BUC (Business Use Case). The Business Analyst also needs to keep the users in mind. The documented functionalities need to fit seamlessly into the user's expectations or perceptions. Some tools that can assist this process are: Ethnography, Personas and Interviews. Your solution needs to be innovative. Business Analysts should always think differently about the problem to find a new and better way to do the work. Solution also needs to be convenient. How can it make the user's life easier? Also what type of information are you giving? Is it useful? Will it make user cont...

External Strategy: The picture given abridges the External task system, so named in light of the fact that you are utilizing an outside arrangement supplier. In the chart, note that exercises progress from left to right, the bolts show the advances between exercises (which can be hopped over), and are keyed with the breakout condition for the movement. The principal action is called Conception, which happens when somebody has a thought for a venture. The thought may be that the association needs to go into another business zone, or to add to or improve its present abilities, or consent to some legitimate commitment, or nearly whatever else. The individuals engaged with the Conception talk about the potential outcomes, make exceptionally primer evaluations of cost and hazard, and determine enough necessities information to empower the undertaking to effectively proceed onward to the following movement. Be that as it may, what amount is "sufficient"? The "enough" is...

Persona A persona is an invented personality; an imaginary but nevertheless archetypical user or customer for whom you are gathering requirements for your product. Why an imaginary character when there are potentially thousands of real users out there? Because, for a mass- market product, or one that is to be used by more than a dozen different people, you don’t know, and can’t get to know, all of the real users. But you can know one really well, and that imaginary user’s attributes guide your requirements: This is your persona. You don’t invent your persona, but rather derive it from market research or other surveys into your likely user population. The degree of precision needed varies in proportion to both the size of the user base and the criticality of the product to be built. In any event, most teams write a one- or two-page description that identifies the persona’s behavior patterns, goals, skills, attitudes, and environment. It is also usual, and indeed desirable, t...

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 ...

A scenario is “an outline of a plot, or a postulated sequence of steps.” When discussing requirements work, this term is to uses to symbolize the plot of a section of the work being studied. The idea to use “plot” is to imply that the work is broken down into a series of steps, and by explaining these steps, the work is explained. The scenario should be neutral, and both simple and understandable to all stakeholders. A modeled scenario to be used to read an agreement on what the work must do. The authors suggest that a scenario is written by breaking the functionality of the business use case down into a series of steps; each step being an activity that form part of the BUC. The parts involved in formalizing a scenario are:   Identify the scenario and give it a meaningful name. Add the trigger for the business case. Add any preconditions that must exist when the business use case is triggered. Add the interested stakeholders. Identify the active stakeholders...

Understanding the Work:- The item you expect to assemble must improve its proprietor's work; it will be introduced in the proprietor's zone of business and will do some portion of (some of the time the entirety of) the work. It doesn't make a difference which sort of work it is—business, logical, inserted ongoing, manual, or mechanized—you generally need to comprehend it before you can choose which sort of item will best help with it. At the point when we state "work," we mean the framework for working together. This framework incorporates the human assignments, the product frameworks, the machines, and the low-tech gadgets, for example, phones, scanners, manual records, and note pads—truth be told, whatever is utilized to deliver the proprietor's merchandise, administrations, or data. Until you comprehend this work and its ideal results, you can't know which item will be ideally important to the proprietor. In the event that we have some efficient and ...

Chapter- 3 Scoping the Business Problem What is Project Blastoff ? The blastoff identifies the boundary of the work area the product is to become a part of, and determines the purpose the product is to fulfill. It also identifies the stakeholders—those people who have an interest in the success of the product. Other deliverables  from the blastoff qualify the project, and are used as inputs to subsequent requirements discovery activities.The blastoff produces a number of deliverables.  • Purpose of the project: a short, quantified statement of what the product is intended to do, and what benefit it brings to the business. This statement of purpose is an explanation of why the business is investing in the project, along with the business benefit it wants to achieve. This justifies the project and serves as a focus for the requirements discovery process. • The scope of the work: The business area affected by the installation of the product. You ...