Skip to main content

Posts

Showing posts from October, 2018

Rabbit, Horse and Elephant approaches

Rabbit —small,  fast , and  brief -lived. Rabbit  tasks  are  generally  smaller  initiatives  with shorter lifetimes,  where   near  stakeholder participation is  possible . Rabbit  projects   typically   encompass  a lesser  number  of stakeholders. Rabbit  projects  do  not  spend an  excellent  deal of time writing the  necessities ,  but  use conversations with the stakeholders as a  manner  to  difficult  the  requirements  written on  tale   playing cards . Rabbit  tasks   nearly constantly  collocate the  business   know-how  stakeholders with the  enterprise  analysts and the  developers . Horse  tasks  are  possibly  the  maximum   not unusual   corporate   projects — they may be  the “ midway   house ”  of formality . Horse  initiatives   need   some  formality— it's miles   probable  that  there's  a  want  for written  necessities   in order that they   can be   surpassed  from one  branch  to  some other . Horse  initiatives  have medium  durability  and  con

Quality Gateway & Negative Stakeholders (Harpreet Singh Brar)

Quality Gateway Requirements are the foundation for all that is to follow in the product development cycle. Quality Gateway ensures that requirements are rigorous by testing each one for completeness, correctness, measurability, absence of ambiguity, and several other attributes, before allowing the requirement to be passed to the developers. Negative Stakeholders Negative stakeholders have opposite opinions which are against the procedure of project. Although they may not be the most cooperative individuals. Negative stakeholders can also be considered the people who threaten your product. For example – hackers, defrauders, and other malevolent people. These people do not provide cooperation in any task unless mistreating your product.

Truth #7 and #8

Truth 7: Requirements do not come about by chance. There needs to be orderly process for developing them. This means that requirements are not to be found just by chance or sitting next to the project layout but for each and every business project you need to follow a certain different process to gather business requirements. This process is different for different business projects because keeping your mindset limited would not help you in every project you are working on. Truth 8: You can be as iterative as you want, but you sell need to understand what the business needs. This refers to a common problem the arises in a company that processes are that go successful for one project are to most likely to be repeated or to be implemented for the upcoming projects. Even if the process is working just fine there will always be a process to make things better than just fine. For making things better you will always need to understand the requirements of the business project. -

The Truth #4 applied at The Northwest Company

The NorthWest Company has expanded its business through the isles in Central America, which is a very huge challenge. Basically, there are cultural differences, several different languages, different currency, so different market, costumes and behaviours. In other words, there are several issues to be understood to have those barriers solved. The Business Analyst in that company is responsible to deep understand all the specific issues and requirements needed in each place in Central America where the company is being expanded. This is essential to understand the requirements to solve business issues. Otherwise, they will propose only pieces of a software that will frustrate the business needs. After reviewing all the specific requirements, the Business Analyst will be able to propose specific solutions such as, exchanging currency, which one is the best way to develop the supply chain system, the specific federal tax system for each country.

Chapter 1 - Truth 11 and the types of requirements

Truth 11 You, the business analyst, will change the way the user thinks about his problem, either now or later.  While solving a problem, it is seen as a duty of a business analyst to describe the problem to the user. When people understand the problem appropriately, they themselves will look into solutions to improve the case of the problem. Types of the requirements: Functional requirements : A functional requirement essentially specifies something the system should do. Non-functional requirements : A non-functional requirement specifies how the system should behave. Constraints:   Constraints are effectively global requirements, such as limited development resources or a decision by senior management that restricts the way you develop a system.   Aziz

Truth 9 and Truth 10

Truth 9 There is no silver bullet. All our methods and tools will not compensate for poor thought and poor workmanship. Business processes are not very easy, and they need a person’s appropriate thinking and perception regarding the project to succeed. There is no straight path with prearranged processes which has all the solutions and will be helpful every time. Truth 10 Requirements, if they are to be implemented successfully, must be measurable and testable. When gathering requirements, anyone can make mistakes. To avoid the case when mistakes in requirements can affect the success of a project, requirements should be measurable and testable.

Fundamental Trusts (1 and 2) - THIAGO LANES

Fundamental Trusts (1 and 2) Trust 1 - Requirements Requirements are what a service ou product intend to do or to be. They are not some information or specs in a document. The business analyst must know what are the real needs of his/her client and define the real needs/requirements. Trust 2 - Benefits / Cost (product) The owner will not pay for the service until the product provides a benefit. This benefit can be a capability that was not possible before, a business process that is better or cheaper nowadays. To be optimally valued, the product must provide a benefit better than the cost.

Focus of Business Requirement Gathering and Truth 5 (Harpreet Singh Brar)

Business requirements gathering is a critical and often overlooked step in a technology selection process. Main focus of Business Requirement gathering is understanding what your systems currently deliver and the key objectives of a new technology acquisition which is essential to realize a successful IT investment. Truth 5 – The requirements do not have to be written, but they have to become known to the builders. Aim of the requirements is to produce as large a specification as possible. Writers of the requirements follows a simple law that is, their work will be appreciated in direct proportion to the thickness of the specification.   Naturally, there is a need to communicate the requirements to the builders of the product. Despite the efficacy of verbal requirements, it is not feasible to communicate all requirements. Sometimes act of writing a requirement helps both the business analyst and the stakeholder to completely understand it. A completely understood requirement h

Module 5 - Some of the business roles in a company

SYSTEM ARCHITECT: A system architecture is an intangible model which defines the structure, behavior and looks over the technical solution or if application architecture meets the requirements of all system. He/she will also supervise day to day activities of developers assigned. SYSTEM ARCHITECT AT THE NORTHWEST COMPANY: System architects must look over the website working and developing new features for the delivery system. He/she looks provides the architectural leadership and ensures best practices for creating and looking over the working to be followed by every developer and worker. BUSINESS ANALYST: A business analyst is someone who analyzes an organization or business domain and accesses the business model. He/she ensures the business requirements are properly obtained and documented by using formal modeling techniques. He/she may engage in other resources as required by customers. BUSINESS ANALYST AT THE NORTHWEST COMPANY: Business Analyst at North West is give

Requirements Life Cycle Management

This area revolves around managing all the tasks which are essential for the requirements such as planning, analyzing, managing etc. These tasks make sure that the business analysis information is up to date with the requirements and the solution or the end result is up to the mark. The area includes the following tasks: Trace Requirements - The goal of tracing is to ensure that requirements are connected to a business objective. In other words, traceability ensures that every requirement has a business purpose and that no requirement is superfluous. Maintain Requirements - As a business analyst, you have to keep requirements up-to-date during and also after your required changes. This task makes sure that the changes are to be done are accurate and even if someone disagrees with the notion of the requirement it is acceptable for the actual change.  Prioritize Requirements  - Not all requirements have the same priority – depending on the stakeholder and the benefits, you have