Posts

Showing posts from April, 2020

Chapter 12 - FIT CRITERIA AND RATIONALE

SCALE OF MEASUREMENT - The scale of measurement is the unit you use to test the conformance of the product to its requirement. For a usability requirement, you can measure the time needed to learn product, or the time taken before achieving a particular level of competence, or perhaps even the error rate of the work done using the product. FORMS OF FIT CRITERIA  -  Defining the Data - D efining the data is to define each term as part of the fit criterion of each individual requirement. Graphic Fit Criteria -  When writing fit criteria, the aim is to be as implementation neutral as possible, thereby giving the designers and developers the maximum amount of freedom in choosing how to meet each requirement. Decision Tables - fit criterion defines the rate of discount that a customer should have depending on how long he has been a customer, what his cumulative spending is, and whether he is a member of the customer loyalty program. USE CASES AND FIT CRITERIA  - A...

Chapter 10, Functional Requirements

FUNCTIONAL REQUIREMENTS This chapter provides an information about the requirements that cause the product to do something i.e functional requirements. Functional requirements are the features of product that developer must implement so that users can accomplish their tasks. In functional requirements, product must do the actions. The Business Analysts understands the functional requirements for the product and then use that to describe about the product to developers. PUC (Product Use Case) scenario enables the stakeholders, developers to have an overview of the functionality, to write  atomic requirements.  Requirements are written as a single sentence with a single verb sch as in a form "The product shall....." Example of functional requirements: 1. Engineer provides a scheduling date and district identifier: For this functional requirements are -  The product shall accept a scheduling date. The product shall accept a valid district identifier. ...

Chapter 11 – Business Requirements Gathering

Chapter 11 –  Non Functional Requirements Having discussed the functional requirements in Chapter 10, we will now review the eight non-functional requirement types within Chapter 11. The non-functional requirements usually do not affect the functional requirements of the product. The non-functional requirements encompass the characteristics or properties of the product.   I will explain a few non-functional requirements below: Look and Feel – This non-functional requirement captures the style, the visuals, the texture and the overall appearance of the product and the feeling/ emotion the developer wants to evoke from the user Usability and Humanity Requirements – This non-functional requirement ensures that the design and development of the product takes into consideration the expectations and capabilities of the target market. The intention is to eliminate any possible issues the user may experience in using the product and ensures that the user experience i...

Chapter - 9

Strategies for today’s business analyst: - For today’s changing surroundings strategies are given to the business analyst to guide requirements discovery. 1.       Balancing knowledge, activities, and people : - In this, to produce optical value of business you should have full detail of your work like – when to have reviews, when to involve stakeholders, so on. This includes requirements knowledge, activities and people. Requirements knowledge includes the product which are useful for work. In activities to discover and communicate knowledge tasks and checkpoints are performed for project. People are they who are there to help you to develop this business. 2.       Knowledge is needed before each breakout : - It include the information or detail, requirements you need to have for your project so that the desire project produce best results without any restrictions. We should have enough knowledge for the project because of its bre...

Chapter 8 - Starting the solution

ITERATIVE DEVELOPMENT Iterative development techniques don't always appear to do much in the way of upfront design, relying instead on frequent releases of software to gauge the design’s suitability. ESSENTIAL BUSINESS The functional needs can be presented to you in the form of a business use case scenario, a collection of atomic functional requirements, or properly crafted user stories.   The non-functional needs are largely responsible for specifying the kind of user experience appropriate for the intended audience. DESIGNING THE USER EXPERIENCE Designing the whole of the user experience is the best way to come up with a product that makes people want to buy it and/or use it. Experience design aims to produce a usage experience that is pleasing and exciting, as well as relevant to the culture and aspirations of the user. Such design focuses much more on how the product makes the user feel than on adding functionality to the product. INNOVATION Innovation means thinking ...

Chapter 7 – Business Requirements Gathering

Chapter 7 –  Understanding the Real Problem This chapter focuses on the Business Analyst “thinking above the line” and focusing on the true essence of the business. This requires reviewing the Brown Cow Model – that is looking at the area above the line – the “ What Now ”. This section examines the undiluted and core reason for the business’ existence. The next step would be to look at the future of the business, called the “Future What”. Examining these two areas helps the Business Analyst get to the heart of the business problem, rather than focus on possible solutions. With the right focus the Business Analyst is not distracted by what others may think the solution could be, but the BA delves and trawls through as much information as possible to accurately understand the business and how it functions, minus technology or automation. This determination to channel all efforts towards the core purpose of the business allows the BA to be more open to all possible solutions...

Chapter - 5 - Investigating the work

Investigating the work- In this chapter we come to know about how business runs systematically and how it work. Under this we have: - Trawling the business - Trawling is a business of how fishing is done. It means catching a fish by a fishing net through the water orderly. This chapter describes some trawling process and direct us to get best. In order to discover the business, it is important to spend less time. As it is starting of analysis process, we would come through it as soon as possible. This chapter discuss the method of uncovering the business and its procedure. Trawl for knowledge – In this we make different product which help us to do work and it doesn’t matter whether it contain processing insurance, controlling a telephone network, handling, photographs and many other human actions. The volere process show how to build best article or substance and get best result. Trawling act uses product from project blastoff because of inquiring into work and collecting knowl...

Chapter-6, Scenarios

Chapter - 6 Scenarios This chapter discussed about the scenarios which are used by the Business analyst to communicate with the stakeholders. Scenarios: A scenario is a natural language tool for telling a story, also it is an outline of a plot of a requirements work or a predicted sequence of steps. The scenario is a simple, easier and understandable medium for all the stakeholders. So, in this you can divide the work in the series of steps and by using this technique, you can explain the work. With the help of scenarios, a Business Analyst describe the business use case to its interested stakeholders. Formality Guide: Scenarios help the projects to fit into every development style. Trawling technique is a scenario used by the rabbit projects to overlook non-functional requirements and capture them in written story cards. Horse projects use scenarios as an alternative to writing atomic functional requirements which helps in discovering the requirements. Elephant projects u...

Chapter 4 - BUSINESS USE CASES

Business use cases  -Business events are useful to partition the work, but it is the work’s response to the  event that now captures the interest of the requirements analyst. For every business event, there is a preplanned response to it, known as a business use case (BUC). Rabbit Projects - it is important to have a rock-solid grasp of the business problem to be solved. Rabbits make use of business use cases to explore their problem domain before starting to formulate a solution. This approach does not add to the documentation load, and it lessens the time spent delivering inappropriate solutions. Horse Projects - Horse projects are more strategic than rabbits. they need more time to complete. There is also the possibility of using Business use case scenarios as the documentation to pass along to the developers. Elephant Projects - elephant projects have a large number of stakeholders, clear communication is both important and difficult. Business ...