Truth 1
Requirements are not really about requirements.
Requirements are like a thing which we want and need just like if we need software, we need to build it. If the output product (software) does not fulfill the requirements, it will not be right. One more thing, requirements always exits, whether or not we try to find out those. So, we can say requirements are some kind of natural laws and it is up to us if we want to discover them or no.
Requirements activity focuses on understanding the business problems and providing a solution rather than just writing a document on requirements.
Truth 2
If we must build software, then it must be optimally valuable for its owner.
As the owner is responsible to pay for the development of the software or he is the one who buys the software. If the software is not good enough to meet the requirements, then the owner is the one who pays for the disruption occurring to the business. However, if it works very well, then the owner gets the benefit. So, after considering these things, we can say that the owner buys a benefit.
To be optimally valuable, the product should provide a benefit more than the cost utilized on it. So, the owner must get the benefit as he is spending the money on it to get the benefits.
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 the need is to build the right software.
A useful product is what accomplishes the requirements very well. To understand it clearly, we need to know the work of the owner's business and how the work should be done in the future. After considering these points, then the business analysts find out what product is needed to improve the business. Then business analysts produce requirements that describe the function of the product and the quality of the work.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.
In some cases, software development projects focus on just creating the software. However, this is not always what we need. The software should be valuable to the owner as described earlier, it must solve the business problem as well. Some processes intend to deliver some functions to the users and depicts them that it solves the problems. We build lots of software with the codes of several hundred lines. mostly we get the errors in the output and sometimes the errors are those requirements that we need. So, we need to identify what we need and to build the software which can solve the problem.
Truth 5
The requirements do not have to be written, but they have to become known to the builders.
It is not necessary to write down the requirements. The more effective way is to discuss the requirements verbally.
If we write a bulky informative document, describing the requirements in the hope that everyone will read it and work accordingly, it could go wrong as the document might be completely ignored by the developers as it feels boring to read hundreds of lines to find out specifications. So, requirements should be discussed with others verbally.
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.
Business Analysts can interpret the requirements after listening to the stakeholders' requests that what they need. But, the difficulty can not be understood which is faced by stakeholders while saying trying to describe the needs. So, it is important that Business Analysts record the customer's requests, as well as influence the customers or maybe derive the customer's requirements from the solutions. He should be able to understand that stakeholders can not be trustworthy in case of requirements.
Truth 7
Requirements do not come about by chance. There needs to be some kind of orderly process for developing them.
These processes should follow an orderly process which is defined as the set of tasks to achieve the intended result. But the order of the process and applications are to be defined by the team itself. Every process should be done after defined systematic moves.
Truth 8
You can be as iterative as you want, but you still need to understand what the business needs.
The best approach is to discover the requirements needed in a different direction. The major concern is to discover what is needed without wasting time on producing other documentation. The ways could be different but we need to understand the business problems and the solutions we expect from the product we are developing.
Truth 9
There is no silver bullet. All our methods and tools will not compensate for poor thought and poor workmanship.
Even using the orderly process, we still need to use our own thinking. Here we need to think about several versions of requirements and the best fit of future products, at the same time.
Requirements activity needs thoughts and perceptions. As given in the book, "No amount of blindly
following a prescribed practice will produce the same result as a skilled business analyst using his most important tools—the brain, the eyes, and the ears".
Truth 10
Requirements, if they are to be implemented successfully, must be measurable and testable.
To build a product that meets both the functional and non-functional requirements, we must be precise. To maintain that accuracy level, we need to measure the requirements. If the requirements can be measured by using numbers, then it could be tested as well. If we have no measurement for the requirement, then it is not a requirement indeed.
Truth 11
You, the business analyst, will change the way the user thinks about his problem, either now or later.
When we understand the requirements coming from different stakeholders, then we start to build abstractions and establish a vocabulary. If we have models for theprocesses and all the measurements and we can reflect it back to stakeholders, then it will change their thinking regarding the business problem.
Congratulation Harjeet, excellent summary!
ReplyDeleteThe truth# 9 got my attention. There is no silver bullet, the activities related to the requirement aren’t easy to process. Even with the right tool, we need time to understand, find the best solution and apply it in the project.
The truth# 10 is one of the most important of all the truths, the implemented requirements must be measurable and testable. What is it mean? We need to able to test the requirement before the implementation to minimize any issue before the project go live. We also need to monitor the requirement after the implementation to know if the products or services are following what it was designed to do.
As harjeet and fabianno did a wonderful job in explaining all others truths i am going to carry on with explaining further. so truth 11
ReplyDeleteYou, the business analyst, will change the way the user thinks about his problem, either now or later. so basically when a BA creates a understanding between needs and the stakeholders. e people have a better understanding of the real meaning of their requirements, they are likely to see ways of improving them. Part of your job is to help people, as early as possible, to understand and question their requirements so that they can help you to discover what they really need .
Since my fellow colleagues explained all of the eleven truths above, I will explain what those earlier mentioned requirements are. Simply put, 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.
ReplyDeleteFunctional requirements:
Functional requirement describes an action that the product must take if it is to be useful to its operator—they arise from the work that your stakeholders need to do. Almost any action (calculate, inspect, publish, or most other active verbs) can be a functional requirement.
The product shall produce a schedule of all roads upon which ice is predicted to form within the given time parameter
This requirement is one of the things that the product must do if it is to be useful within the context of its owner’s business. You can deduce that owner in this case is an organization that is responsible for maintaining roads safely, and that does so by dispatching trucks to spread de-icing material on roads where ice is about to form.