Fundamental Truths
Requirements are not really about requirements.
Requirements exist whether we know them, discover and write them down or not, and are what the software, hardware or service is intended to do. Requirement activity in the business is understanding the problem at hand and finding a solution.
TRUTH 2
If we must build software, then it must be optimally valuable for its owner.
If we must build software, then it must be optimally valuable for its owner.
The owner is the one that pays for the software and any disruption to the business once the software is deployed. The owner will not buy the software unless the product provides a benefit. The benefits in the business is usually making some business processes faster, cheaper or more convenient.
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.
You must understand what the product you are building is intended to accomplish by understanding the work of the owner's business. Negotiation must be done with the owner to see which product will improve the work. The kind of work, the kind of product or the methods of the product does not matter to understand the requirements.
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.
You must understand what the product you are building is intended to accomplish by understanding the work of the owner's business. Negotiation must be done with the owner to see which product will improve the work. The kind of work, the kind of product or the methods of the product does not matter to understand the requirements.
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.
The software development projects should not solely depend on software's . It is a long process which involves long codes and many errors. Then because of the errors the work is done again and again but still after that we don't know if the user is going to like the result or no. So, providing users with satisfaction and appropriate end product cannot be done by a piece of software.
There is an important difference between building a piece of software and solving a business problem. The former does not necessarily accomplish the latter.
The software development projects should not solely depend on software's . It is a long process which involves long codes and many errors. Then because of the errors the work is done again and again but still after that we don't know if the user is going to like the result or no. So, providing users with satisfaction and appropriate end product cannot be done by a piece of software.
TRUTH 5
The requirements do not have to be written, but they have to become known to the builders.
The requirements do not have to be written, but they have to become known to the builders.
The way of conveying the information does not matter whether it is written or verbal. In some cases verbal communication is more efficient. However, to improve the understanding about an activities providing requirements is important, written communication should be clear and easy to understand. Additionally, when someone know what they need efforts are made more often.
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.
Sometimes for the customers it is difficult to decide what they need. Same is with the stakeholders sometimes they find it difficult to explain what are they looking for, its the business analyst responsibility to take note of what they say or what they need. So, either its customers or stakeholders the business analyst is the one who has to provide solutions to any kind of problems and introduce innovative thoughts.
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.
Sometimes for the customers it is difficult to decide what they need. Same is with the stakeholders sometimes they find it difficult to explain what are they looking for, its the business analyst responsibility to take note of what they say or what they need. So, either its customers or stakeholders the business analyst is the one who has to provide solutions to any kind of problems and introduce innovative thoughts.
TRUTH 7
Requirements do not come about by chance. There needs to be some kind of orderly process for developing them.
Requirements do not come by chance. There needs to be some kind of orderly process for developing them.
Requirements do not come about by chance. There needs to be some kind of orderly process for developing them.
Requirements do not come 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.
You can be iterative as iterative you want. but there is still need to understand what the business needs.
You can be as iterative as you want, but you still need to understand what the business needs.
You can be iterative as iterative you want. but there is 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.
When Creating a new product or service. There is no one way of creating it. Even though we follow the same standards. That doesn't 100% mean that we're following the correct path. Problems will always occur and gathering and testing requirements are the best way. To see if the constraint can be fixed. All in all, there is no one way of doing things. It's a matter of trial and error.
When Creating a new product or service. There is no one way of creating it. Even though we follow the same standards. That doesn't 100% mean that we're following the correct path. Problems will always occur and gathering and testing requirements are the best way. To see if the constraint can be fixed. All in all, there is no one way of doing things. It's a matter of trial and error.
TRUTH 10
Requirements, if they are to be implemented successfully, must be measurable and testable.
When creating a product there are aspects that you must consider. For example is it profitable? Furthermore, after you create the product is there any potential increase in revenue? When gathering requirements there are multiple perspectives on getting them. Normally from feedback, getting information from the user if there is a need for change. A precision of information can help see if the product is attractive to the user. Therefore, if the information can be useful and testable. Then the gathered requirements useful.
Requirements, if they are to be implemented successfully, must be measurable and testable.
When creating a product there are aspects that you must consider. For example is it profitable? Furthermore, after you create the product is there any potential increase in revenue? When gathering requirements there are multiple perspectives on getting them. Normally from feedback, getting information from the user if there is a need for change. A precision of information can help see if the product is attractive to the user. Therefore, if the information can be useful and testable. Then the gathered requirements useful.
TRUTH 11
You, the business analyst, will change the way the user thinks about his problem, either now or later.
Identifying and solving the problem is part of being a Business Analyst. Presenting a business process to help stakeholders understand. If the requirements that they want to have is either attainable or not. A lot of stakeholders out there. Doesn't really know what they want. So, as a business analyst, it's apart of your job to guide them or help them understand the real meaning of requirements.
You, the business analyst, will change the way the user thinks about his problem, either now or later.
Identifying and solving the problem is part of being a Business Analyst. Presenting a business process to help stakeholders understand. If the requirements that they want to have is either attainable or not. A lot of stakeholders out there. Doesn't really know what they want. So, as a business analyst, it's apart of your job to guide them or help them understand the real meaning of requirements.
Once people have a better understanding of the real meaning of their requirements, they are likely to see ways of improving them. Part of BA's 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.
ReplyDelete