BR Chapter 1: Some Fundamental Truths


Requirements are not really about requirements.

Requirements are what the product or service you are building is meant to be and to do. Requirements always exist, and a product can never be right unless it conforms to these requirements. Requirements are not just for the sake of writing them down in a document, they focus on a business problem and solve it. The product or service being created is meant to solve a problem, and requirements are there to tell what how to create the product right. SO, in essence, requirements are not about written requirements as such, but rather an uncovering of the problem to be solved.

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


When a business analyst understands the requirements after consultation with the different stakeholders, he starts to establish a concept of it. He works in synchronization with all the stakeholders to find the essence of work, put together clear and measurable requirements and reflects it back to them after improving these requirements. He constantly questions the requirements and has healthy discussions with all the stakeholders to improve them and have a consensus.


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


Analysts have realized that any development technique needs the requirements as a prerequisite to development. The requirements process is an integral part of bringing about a change. Instead of doing letting go of the requirements, good analysts approach them from a different perspective and try their best to reduce waste in terms of documentation and in turn save time and energy. Irrespective of the way an analyst proceeds with building a process or a software, gathering requirements remains critical.

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


The aim of analysts with regards to requirements should never be to just to write them in as much detail as possible, but to convey them as clear as possible to the builders or the development team. In some cases, verbal communication is considered to be the best way of communicating requirements to the developers, while in some cases it is important to have a paper trail to follow the developments and have a permanent record. Requirements should not be a burden on the development process, so they should be written only if necessary and it should be kept in mind that the effort involved in writing requirements is paid many times over by the precision of the requirements and reduction in maintenance effort that is yet to come.

x

Comments

  1. Yogesh JaglanOctober 30, 2019 at 4:53 PM

    After such truth, what are these prerequisites that we continue discussing? Basically, a prerequisite is something the item should do to help its proprietor's matter of fact, or a quality it must need to make it satisfactory and alluring to the proprietor. A necessity exists either in light of the fact that the kind of item requests certain capacities and characteristics, or on the grounds that the customer legitimately requests that prerequisite to be a piece of the conveyed item.

    Functional Requirements: A useful prerequisite depicts an activity that the item should take in the event that it is to be helpful to its administrator—they emerge from the work that your partners need to do. Practically any activity (figure, review, distribute, or most other dynamic action words) can be a useful prerequisite.

    Non- functional requirements are properties, or characteristics, that the item should have in the event that it is to be adequate to its proprietor and administrator. Now and again, non-utilitarian necessities—these indicate such properties as execution, look and feel, ease of use, security, and legitimate qualities—are basic to the item's prosperity.

    Non-functional requirement may from the outset appear to be ambiguous or deficient. Later in this book we will see how to give them a fit basis to make them quantifiable and along these lines testable.

    ReplyDelete
  2. Amanjot kaur chahalOctober 31, 2019 at 2:50 PM

    In system or software development projects, business requirements usually require authority from stakeholders. This typically leads to the creation or updating of a product, system, or software. The product/system/software requirements usually consist of both functional requirements and non-functional requirements. Although typically defined in conjunction with the product/system/software functionality (features and usage), non-functional requirements often actually reflect a form of business requirements which are sometimes considered constraints. These could include necessary performance, security, or safety aspects that apply at a business level.
    Business requirements are often listed in a Business Requirements Document or BRD. The emphasis in a BRD is on process or activity of accurately accessing planning and development of the requirements, rather than on how to achieve it; this is usually delegated to a Systems Requirements Specification or Document (SRS or SRD), or other variation such as a Functional Specification Document.

    ReplyDelete
  3. Patience NgcoboNovember 14, 2019 at 3:14 PM

    These are the essential contribution of requirements. If a project goes into production after requirements gathering, and no one has taken the time to painstakingly document every decision, exception, specification, and assumption, were the project requirements really gathered?

    The importance of requirements gathering is often underestimated on multiple levels. When budgets are thin, timelines are tight, and scope is creeping, requirements documentation tends to be the first deliverable to go and the last deliverable to be considered. Thus understanding some of the fundamental truths when gathering requirements is very crucial to the success of the project.

    ReplyDelete

Post a Comment

Popular posts from this blog

BR Chapter 12: Fit Criteria and Rationale

A satisfying viewpoint (among a large number) of Kent Beck's eXtreme Programming system is its emphasis on composing experiments before composing the code. The experiment characterizes the measuring stick that the executed code must match. The fit model is pretty much something very similar: It is a measuring stick for the necessity. By adding a fit rule to the necessity, you are, basically, composing its experiment. In the event that you are utilizing client stories, at that point we firmly propose that you give specific consideration to the explanation given for the usefulness. This is pretty much equivalent to the justification, and is a significant supporter of winding up with the right item. Composing experiments on the back of the story card ought to accomplish a similar reason as the fit standard we talk about here.  For each of the non-practical necessities yielded by the blog, we presently propose determining the fitting fit rule, affirming it with the partner, and compo...
Read more

BA Chapter 9: Underlying Competencies

Image
Underlying Competencies are a description of the behaviours, characteristics, knowledge, and personal qualities that support the practice of business analysis. BABOK® defines 6 key groups of competencies that a BA is expected to possess. Each competency group constitutes of multiple sub competencies which are as discussed below: (Source: https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/1287/Developing-a-Competency-Model-for-Business-Analysts.aspx) 1.      Analytical Thinking and Problem Solving : These skills are required for business analysts to analyze problems and opportunities effectively, identify which changes may deliver the most value, and work with stakeholders to understand the impact of those changes. Analytical Thinking and Problem-Solving core competencies include: ·            Creative Thinking ·           Decision Making ·  ...
Read more

BR Chapter 6: Scenarios

Image
At this stage of the requirements process, the business analyst has identified the business events as well as the business use case which we referred to as BUC and these correspond to the business events.   Below are some of the techniques the Business Analyst can use to communicate requirements to the stakeholders: Scenarios The Business Analyst can use Scenarios to model and record the BUCs. A scenario is an outline of a plot, or a postulated sequence of steps - it tells the story of a business use case.   The scenario is a neutral medium, and one that is both simple and understandable to all stakeholders.  A business analyst would use a scenario like this to elicit, and then describe, a business use case to its interested stakeholders. The BUC is a discrete amount of functionality; it happens in its own time frame and can be considered separately from other parts of the work’s functionality. The BA model a scenario and use it to reach a...
Read more