Chapter 1 - Business Requirements Gathering
There are some fundamental truths:
Truth 1
Requirements are not really bout requirements.
Requirements of any product, software, or any action which is to be performed. One cannot develop the requirements because they are generated themselves according to the task which is to be performed. For the completion of the activity some actions are to be performed which are known as requirements for that activity.
Requirements of any product, software, or any action which is to be performed. One cannot develop the requirements because they are generated themselves according to the task which is to be performed. For the completion of the activity some actions are to be performed which are known as requirements for that activity.
T
If we must build software, then it must be optimally valuable
for its owner.
The product which is developed by someone must be valuable for its developer. The developed product will only benefit the owner when it will provide benefit to the organization in terms of changing the usual or daily activities in the positive way like increasing the pace of the work.
The product which is developed by someone must be valuable for its developer. The developed product will only benefit the owner when it will provide benefit to the organization in terms of changing the usual or daily activities in the positive way like increasing the pace of the work.
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
build what that need is to build the right software.
When there is any need and the product developed must accomplish that need. If the product is not satisfying the need then it would not be worthy for the user. For performing this task and fulfilling the need, the developers must understand the work and how it must be carried out.
When there is any need and the product developed must accomplish that need. If the product is not satisfying the need then it would not be worthy for the user. For performing this task and fulfilling the need, the developers must understand the work and how it must be carried out.
Truth 4
There is an important difference between building piece of
software and solving a business problem. The former does not necessarily
accomplish the latter.
For solving the business problem the software must be developed according to that problem. While making the software the developer must focus on the problem solving rather than only on software developing because if the software will not be able to solve problem then it will be worthless for users.
For solving the business problem the software must be developed according to that problem. While making the software the developer must focus on the problem solving rather than only on software developing because if the software will not be able to solve problem then it will be worthless for users.
Truth 5
The requirements do not have to be written, but they have to
become known to the builders.
The understanding of the product requirements is essential for the developer rather than recording those requirements because it might not be useful to its readers. Instead those requirements can be discussed with the team. This way of communicating requirements are far better than writing the requirements.
The understanding of the product requirements is essential for the developer rather than recording those requirements because it might not be useful to its readers. Instead those requirements can be discussed with the team. This way of communicating requirements are far better than writing the requirements.
In this chapter, after all the truths, there are some requirements which product must do in order to support business or in other words to increase the quality of the product so that it attracts the owner. There are functional and non-functional requirements:
ReplyDeleteFunctional Requirements: In the functional requirements, product must do things to become useful for the owner's business.
Non-Functional Requirements: In the non-functional requirements, product must have qualities, so that business owner accept it.
Focus of Business Requirement Gathering
ReplyDelete“To get what you want, you need to accurately define it”.
This is a fundamental point of view for developing a good business requirements analysis and achieving the overall objective. Important to this process are the following elements:
1) Identifying the key stakeholders
2) Capturing stakeholder requirements by simply asking “Why?” in interviews, focus groups or
through designing prototypes
3) Categorizing the requirements – functional, non-functional, technical, operational etc.
4) Interpreting and recording the requirements accurately. Circulate for feedback among key
stakeholders, end-users and development teams
5) Sign Off – getting all key stakeholders to sign off on the final report agreeing that the
requirements as presented accurately define and reflect their business need(s).
One truth that I found meaningful is Truth 11 – “You, the business analyst, will change the way the user thinks about his problem, either now or later.” As the Business Analyst, we must “raise the bar”. Given our extensive training, work history/ experience and past collaborations, we are expected to go above and beyond merely understanding and visualizing the basic requirements we are provided with by our stakeholders. We must rely on comprehensive research, professional networking learning opportunities, bench-marking best practices, conducting competitor analyses among other initiatives, to provide our stakeholders with more than meeting a business objective.
Our aim is to exceed the stakeholder’s expectations by providing a value added process on our end. This will ultimately involve changing the way the stakeholder thinks about the need/ problem.
This comment has been removed by the author.
ReplyDeleteTruth 5 - Requirements are not meant to place an extra burden on your project, so
ReplyDeletenothing should be written unless there is a clear need for it. Nevertheless,
when the need exists, then the effort involved in writing a requirement is
paid back several times over by the precision of the requirement and the
reduction in the maintenance effort that is yet to come.