Chapter 01 - Some Fundamental Truths

This post will summarize the 11 fundamental truths described in the book "Mastering the Requirements Process - Getting Requirements Right" , which are considered the essential contribution of requirements.

 Truth 1: Requirements are not about requirements

The requirements activity is not mainly about writing a requirements document. It’s about focusing on understanding a business problem and providing a solution for it.

Truth 2: If we must build software, then it must be optimally valuable for its owner.
The owner is the person or organization that pays for the software or hardware. He/she will not pay unless the product provides a benefit. The software/hardware must be optimally valuable, that being that it provides a benefit that is in proportion to the cost of the product.
It’s part of the business analyst’s, or other “requirements discoverer” job to understand what that value is.

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 right software.
The most useful products are those for which the developers correctly understood the purpose of the product and in what way to accomplish that purpose.
To understand these things, you have to understand the owner’s business and determine how that work should be carried out. After this, then the business analyst will negotiate with the owner which product will improve the work. The business analyst then creates the requirements for the product.

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.
Software must solve the owner’s business problem. It doesn’t matter how much time you spend creating the perfect software, if it doesn’t solve the problem, it’s of no use.

Truth 5: The requirements do not have to be written, but they have to become known to the builders.
Requirements documentation can become very large resulting in it being difficult for readers, especially developers to understand much of it. Therefore, sometimes it’s not just about writing down the requirements, but making sure they are understood and will be followed.

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/she just doesn’t know what he needs.
Stakeholders have difficulty describing what they need. It’s not simple to envisage a product that will solve a problem, especially when the problem is not fully understand. Original ideas can also have incremental improvements along the way.
It’s the business analyst’s role involves: record the customer’s request; persuade the customer that what is being for is not what he/she needs; derive the requirements from the customer’s solutions; or even come up with an innovation that was not requested, but results in a better solution.

Truth 7: Requirements do not come about by chance. There needs to be some kind of orderly process for developing them.
“Orderly processes comprise a set of tasks that achieve the intended result, but leave the order, emphasis, and degree of application to the person or team using the process.”

Truth 8: You can be as iterative as you want, but you still need to understand what the business needs.
Business analysts need to discover what is needed without producing unnecessary, premature and wasteful reams of documentation.

Truth 9: There is no silver bullet. All our methods and tools will not compensate for poor thought and poor workmanship
Although orderly processes are important, but they do not substitute thinking. Business analysts will deal with several versions of the requirements and at the same time imagine what will make the best future software product.

Truth 10: Requirements, if they are to be implemented successfully, must be measurable and testable.
If you can measure the requirement using numbers instead of words, you can make the requirement testable.

Truth 11: You, the business analyst, will change the way the user thinks about his problem, either now or later.
Once people have a better understanding of their requirements, they will see ways to improve them. It’s part of the business analyst’s job to understand and question the requirements so that they can help people discover what they really want.

Source: Mastering the Requirements Process - Getting Requirements Right; pages: 01-09


Comments

  1. Parminder Singh30 October 2019 at 16:19

    What are these requirements?
    A requirement is something the product must do to support its owner’s business, or a quality it must have to make it acceptable and attractive to the owner. A requirement exists either because the type of product demands certain functions and qualities, or because the client justifiably asks for that requirement to be part of the delivered product.

    What are the types of requirements?
    There are two types of requirements: -
    1. 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.

    2. Non-Functional Requirements: - Non-functional requirements are qualities the product must have.The product shall provide a pleasing user experience.Non-functional requirements might at first seem vague or incomplete.

    ReplyDelete
  2. Harleen Virk30 October 2019 at 16:30

    Volere Requirements Process: A procedure for effectively finding, confirming, and recording necessities. Every part covers an action of the procedure, or some part of necessities assembling that is expected to finish the movement.
    As you become familiar with the Volere Requirements Process, remember that it is intended to be a guide for creating expectations. What you do with the procedure is driven by the applicable expectations, not by the systems. We might want you to think about the procedure as a lot of undertakings that must be done (to fluctuating degrees of detail) for fruitful prerequisites ventures, instead of as a lockstep system that must be pursued no matter what. As you read about each part, consider how you would play out that piece of the strategy given your very own basic and hierarchical arrangement.

    ReplyDelete
  3. Kent Dela Cruz30 October 2019 at 17:50

    With these fundamental truths that have been introduced at the first post, we can also talk about the topic of constraints of the requirements.

    Constraints is defined in the book, Mastering the Requirements Process as, "Constraints are global requirements. They can be limitations on the project itself or restrictions on the eventual design of the product."

    So basically, constraints are issues that may affect the final design of a product. It can also be defined as something that may change something internally with the process and externally on how the product may look like in the final product.

    Source: Mastering the Requirements Process - Getting Requirements Right (book)

    ReplyDelete

Post a Comment

Popular posts from this blog

Chapter 1 - What is Business Analysis?

Hello! Welcome to our Business Analysis blog.  We are Mariane, Harleen, Kent and Parminder, and we are Business Technology Management students at Red River College.  Throughout our Fall term we will be using this blog to share some important concepts regarding Business Analysis.  For our first post, we will start with the basics, and define exactly what is Business Analysis, and other important concepts related to it. According to BABOK, " Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value. "  Business analysis cannot work without having a representative to intermediate these practices within an enterprise. This professional is called a Business Analyst who is responsible for putting in practice the tasks desc...
Read more

Chapter-12 Fit Criteria and Rationale

Image
FORMALITY GUIDE Horse ventures need to have an exact and effectively shareable comprehension of the significance of necessities. It has been our experience that when the task has numerous partners—which is the standard for horse ventures—various partners relegate various implications to prerequisites. Including a reason and a fit basis to every necessity implies it is for all intents and purposes inconceivable for errors to happen. We prescribe that pony ventures incorporate both of these in their necessities. Elephant ventures must utilize methods of reasoning and fit criteria. These tasks are compelled to deliver a composed determination to be given on to some other gathering, either another piece of the association or an outsourcer. Having a detail containing just unambiguous, testable necessities is pivotal to elephant ventures on the off chance that the other party is to comprehend and, at that point convey the right item Scale of Measurement Any prerequisite can be ...
Read more

Chapter 5 - Investigating the Work

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