Monday, March 16, 2020

Business Requirement Gathering - Chapter 3: Scoping the Business Problem

Project Blastoff: It identifies the limit of the work area that the product is to become a part of and determines the purpose the product is to fulfill and 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 following are the Project Blastoff deliveries:

  • Purpose of the project: A short statement that tells for what the project is intended to and how it will be beneficial for the business.
  • The scope of the work: The business area affected by the installation of the product. You need to understand this work to specify the most appropriate product. 
  • Stakeholder: The people who are interested in the project and can affect the project.
  • Constraints: These are the restrictions on the scope and style of the project.
  • Names: Any terminology to be used in this project. 
  • Relevant facts and assumptions: Is there any fact that people need to know and are there any assumptions that can affect the result of the project.
  • The estimated cost: It tells what is the estimated cost for the project and what are the other resources that are involved in the project.
  • The risks: It tells what are the risks involved in the project.
  • Go/ no go decisions:  Is the project viable, and does the cost of producing the product make it worthwhile? should we further proceed with the project?
Formality Guide: The blastoff deliverables like scope, stakeholders, and goals are needed by any project, regardless of its size for the informality. Guidelines to start up the project depends on the size of the project. The degree of formality you apply to the blastoff deliverables varies, but that does not stretch to ignoring them. 

Setting the scope: If the owner is an organization, you have to understand the business processes and aims of that organization, or, as is the case for most projects, the part of the organization your project will affect. The scope you are interested in at the beginning of the requirements project is the scope of the owner’s work, specifically, the piece of work that the owner would like to change and improve.
Scope, Stakeholders, and Goals: Scope is not the only thing to get the requirements off the ground to make the product successful. The people who are involved in the project and the goals they are trying to achieve plays a vital role in it.
The scope is the extent of the business area affected by the product and it defines a part of a real-life organization, the scope points to the stakeholder, the people who have an interest in, have an effect on, the success of the work. The stakeholders then decide the goals which are needed to be done by the time of the installation of the project.
Stakeholders: Stakeholders are the people who are interested in the project, have an effect on the project and involved in the success of the project. The owner is one of the most obvious stakeholder.  Potentially dozens of stakeholders exist for any project.
The image follows is the stakeholder map represents the various classes of the stakeholders according to their roles in a project.
Sponsors: Sponsors are the people who pay for the development of the product. The sponsor is concerned with project issues and will be instrumental in setting some of the constraint requirements. You cannot proceed without a sponsor. If no one is representing the interest of the organization at large, then there is little point in proceeding with the project. The sponsor is most likely to be present at the blastoff meeting and is most likely one of these people:
  • User Management
  • Marketing Department
  • Product Development. 
The customers: The customer is the one who buys the product ones its development and then becomes the new owner of the product. To persuade the customer one has to find an idea that the customer finds that the product is valuable and useful for him/her. It is clear that the customer must always be represented on the project. Where many potential customers exist, you must find a way of representing them in your project. 

Users: Understand Them: This term means that the people who will ultimately be the hands-on operators of your product. The purpose of identifying the users is to understand what they are doing and which improvements they consider to be valuable.

Other Stakeholders: There are also other stakeholders that you have to talk with to collect the requirements. The problem that you often face in requirements projects is that you fail to discover all the stakeholders, and thus fail to discover their needs. The following are some of the other stakeholders:
Consultants, Management, Subject-Matter experts, Core team, Inspectors, Market Forces, Legal Experts, Negative Stakeholders, Industry Standard setters, Government, Special-Internet groups, Technical experts, Cultural Interests and Adjacent Systems. 

Goals: What do you want to achieve? Your sponsor is making an investment in a project to build a product; to understand the reason behind this investment, you need to determine the precise benefits the project is to deliver. You also need a guide to help you steer your efforts toward those requirements that will make the greatest contributions to the expected business advantage. One needs to understand the goals of a certain project. for this, you have to understand the highest-level requirements.
Purpose: The purpose of the project is not only to find the solution to a problem but also to provide an advantage to the business. If there is an advantage, you would be able to measure it.
Advantage: The business advantage is the reduction or elimination like the reduction of errors while working on software.
Measurement: It means that is the advantage measurable. The success of the product is measured by the number of errors it made as compared to the previous one.

Constraints:  These are the global requirements and these restrictions help by determining which requirement should be added and which one should not be. Constraints affect decisions about the scope of the product by limiting the amount of time or money that may be spent on the project.
Solution Constraint: The specifications which describe the mandated designs and solutions. 
Project Constraint: Project constraints describe the time and financial budgets for the project.

Risks:  Your blastoff process should include a short risk assessment. Such an assessment is probably outside the remit of the business analyst and should be done by a competent risk-assessment person. The job is to assess both those risks that are most likely to happen and those risks that will have the greatest impact if they do, in fact, become problems. 

Sunday, March 15, 2020

Business Requirement Gathering - Chapter 2: The Requirements Process



Project Blastoff:
·       The key purpose of the project blastoff is to build the foundation for the requirements discovery that is to follow, and to ensure that all the needed components for a successful project are in place
·       Defines the scope of the business problem
·       Confirms the goals of the project
Trawling for Requirements:
·       Means discovering the requirements
·       Uncovering the essence of the system
·       Decide the best product to improve this work
Writing the requirements:
·       Major problem in system development are misunderstood requirements
·       Ensure that parties at either end of the development spectrum
·       Ensure that the essence of the requirement has been captured and communicated and that the delivered product can be tested
Quality Gateway:
·       To ensure correctness, the quality gateway tests the requirements
·       Check each requirement for completeness, relevance, testability, coherency, traceability, and several other qualities
Reusing Requirements:
·       Can reuse dozens of requirements without alternation
·       Can start with a specification from one of the previous projects and use it as a checklist
Reviewing Requirements:
·       This final review checks that there are no missing requirements
·       Confirms that the specification is really complete and suitable
·       Offers an opportunity to reassess the costs and risks of the project
·       Have a much more precise knowledge of the scope and functionality of the product
·       Estimate the cost to construct the product
Iterative and Incremental Processes:


Requirements Retrospective:
·       Can be very formal
·       Publishes a retrospective report
Evolution of Requirements:
·       Deploy models of varying degrees of a formality to help them
·       Learn what the work is, and what it is to be
·       Helps enormously when coming to an understanding of the work
·       Specify what the product has to do for the work
The Template:
·       Is designed to serve as a sophisticated checklist
·       Here is the content:
o   Project Drivers: reasons and motivators for the project
o   Project Constraints: the restrictions on the project and the product
o   Functional Requirements: the functionality of the product
o   Non-functional Requirements: the product’s qualities
o   Project issues: issues relevant to the project that builds the product
The Snow Card:


Formality Guide:
·       Rabbit: small, fast and short-lived
o   Rabbit projects are usually iterative
o   Do not spend a great deal of time writing the requirements
o   Always co-locate the business knowledge stakeholders with the business analysts and the developers
·       Horse: fast, strong and dependable
o   Most common corporate projects
o   Need some formality
o   Have medium longevity and involve more than a dozen stakeholders
·       Elephant: solid, strong, long life and a long memory
o   Need for a complete requirements specification
o   Have a long duration

o   A large numbers of developers, necessitating more formal ways of communicating

Monday, March 9, 2020

Business Requirement Gathering- Chapter 1


Chapter 1 Some Fundamental Truths
 

Truth 1 Requirements are not really about requirements

Requirements are what the software product, or hardware product, or service, or whatever you intend to build, is meant to do and to be. Requirements exist whether you discover them or not, and whether you write them down or not. In essence, then, requirements are not about the written requirements as such, but rather an uncovering of the problem to be solved.

Truth 2 If we must build software, then it must be optimally valuable for its owner.

As the software becomes more capable and the cost of construction increases, so does the benefit that the software brings. At some point, however, the cost of construction starts to outstrip the benefit and the project is no longer beneficial.

Truth 3 If your software does not have to satisfy a need, then you can build anything. However, if it is meant to satisfy a need, then you have to know what that need is to build the right software

It is worthwhile considering that the most useful products are those for which the developers correctly understood what the product was intended to accomplish for its users, and in what manner it was to accomplish that purpose. 

Truth 4 There is an important difference between building a piece of software and solving a business problem. The former does not necessarily accomplish the latter.



Truth 5 The requirements do not have to be written, but they have to become known to the builders.

Naturally, there is a need to communicate the requirements to the builders of the product.


Truth 6 Your customer won’t always give you the right answer. Sometimes it is impossible for the customer to know what is right, and sometimes he just doesn’t know what he needs.


Truth 7 Requirements do not come about by chance. There needs to be some kind of orderly process for developing them.

Truth 8 You can be as iterative as you want, but you still need to understand what the business needs.

Truth 9 There is no silver bullet. All our methods and tools will not compensate for poor thought and poor workmanship.

Truth 10 Requirements, if they are to be implemented successfully, must be measurable and testable.

Truth 11 You, the business analyst, will change the way the user thinks about his problem, either now or later.

What are these Requirements?


  • Functional Requirements: Functional requirements are things the product must do.

              The product shall produce a schedule of all roads upon which ice is predicted to form within the given time parameter.
  • Non- Functional Requirements: Non-functional requirements are qualities the product must have.
           The product should able to determine “friend or foe” in less than 0.25 second.
           The product shall provide a pleasing user experience.
          The product shall be able to be used by travelers in the arrivals hall who do not speak the          home language.

  • Constraints: Constraints are global issues that shape the requirements. Constraints are simply another type of requirement.
The product must be available at the beginning of the new tax year.
The product shall operate as an iPad, iPhone, Android, and Blackberry app.