Chapter -1 from book Mastering The Requirements Process
Some Fundamental Truths
post by Paramjeet Kaur Toor
Some Fundamental Truths are:
1. Requirements are not really about requirementsRequirements are what you are going to build that can be software, hardware or any service so these are developed to be confirm about our specific output. Therefore, requirements activity is not just write them on paper but focus on problem and finding its solution is most important.
2. If we must build software, then it must be optimally valuable for its owner.
It our primary job to meet the product/service' s qualities to owner's expectation who is paying for it. Therefore, people must know owner's needs deeply so that final output will be beneficial for owner. Optimally valuable means that owner must earn more profits from that product' s costs. Therefore, it become concern to make more and more profitable product such as that is not existing before for satisfying owner and user.
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.
Those products become most useful that satisfy owner and its users as those products generate more profits that make owner happy. In order to make satisfy product/service people need to understand product deeply like what are requirements for that product, how it will accomplish and find the best product. It does not matter which may we choose to make product and what is product, the focus should be on quality and satisfaction.
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 development projects mainly focus on software as their main job is to produce software in most of cases. we should focus owner' s problem and then try to fix it. In software making process, output contains errors tat relate to requirements and then have to rework on that software. As a result, developers can't reach to problem's solution that lead to rework if it does not satisfy user.
5.The requirements do not have to be written, but they have to become known to the builders.
we often see that requirements are just written on document ty.ake more importance than understand them but fact is that understanding is much important to build a satisfy product. so written document is not useful as some of people do not have patience to read it and some do not understand. Therefore, communication is best way to make others understand requirements deeply.
Very good points!!! And as a fundamental truth we can also mention:
ReplyDeleteTruth 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.
The business analysts are in charge of listening to the stakeholders, recording whatever it is they say, and translating their requests into requirements for the product. However, given the complexity of today’s businesses, sometimes it is difficult for the stakeholders to understand all parts of the business.
As a result, the business analyst must go beyond and have some of the approaches below:
- he must record the customer’s request;
- he must convince the user that what is being asked for is not what is needed;
- he has to derive the requirements from the customer’s solution;
- he must suggest an innovation that is not what the customer asked for, but results in a better solution.
Truth 1: When thinking about the requirements gathering activity, it is common to imagine the writing activity of a document; however, while its documentation is essential, the main reason is in understanding the real business problem and proposing a solution.
ReplyDeleteTruth 2: Once you have identified the real problem, the best payback with the best investment cost must be taken into account, as it will do no good a solution that costs more than the problem itself. In this case, it would not make sense to invest in the proposed solution.
Truth 3: It clarifies us that we should understand that which product we should make which can satisfy the needs of the customers and which can help the business in future. To make that product, several things are used by the business, for example: To make a product in the technology sector, several software are using to achieve that goal
Truth 4: The product, on the off chance that it is to be significant to the proprietor, must take care of the proprietor's business issue. Some improvement procedures depend on conveying some usefulness to its proposed clients, and welcoming them to state whether it tackles their concern.
Software requirements specifications (SRS) are the foundation of the pillars of software. They drive design, development, user experience, support documentation, and more. Testers must make assumptions and spend time defining or looking for hidden requirements themselves. This essentially adds to the overall time and cost of the testing process.Taking the time up front to document requirements will save you and your team time further down the line. Requirements don’t always need to be extremely detailed documents but they should exist in some form. They are the document of record to make sure every one is on the same page.
ReplyDeleteI found the 11 truths to be an eye opener seeing as i have not heard of these before reading this. I found that the first truth can be confusing based off its title but upon further reading you start to understand how it makes exact sense, its more about focusing on the problem and looking to the solution than just writing out a long list of meaningless requirements. Also i found the fifth truth interesting because before this we assume that all requirements are required to be written down on a long list and given to developers, but reading this truth we see that sometimes sitting and getting the developers to understand the requirements is more important.
ReplyDelete