Chapter 1 – Some Fundamental Truths
Chapter 1 – Some Fundamental Truths
Q – 1 What is meant by “Requirements are not
really about requirements”?
ANS: A requirement is something a product must do or a quality it must have to make it acceptable. The requirements activity is not about writing a requirements document. But it focuses on discovering a business problem and providing a solution to it. The real art of requirements discovery is discovering the real problem. Once it is accomplished, you get the basis for identifying and choosing between alternative solutions.
ANS: A requirement is something a product must do or a quality it must have to make it acceptable. The requirements activity is not about writing a requirements document. But it focuses on discovering a business problem and providing a solution to it. The real art of requirements discovery is discovering the real problem. Once it is accomplished, you get the basis for identifying and choosing between alternative solutions.
Q – 2 What are functional requirements?
ANS: A functional requirement is one of the things a product must perform to be useful. For example, let’s take the example of house under construction, in which it is already clear how the house would look (colors, sizes of bedrooms) and would perform (have an air-conditioning unit in each bedroom). This is something that owner wants the house to be able to do, a function he/she wants the house to be able to perform.
ANS: A functional requirement is one of the things a product must perform to be useful. For example, let’s take the example of house under construction, in which it is already clear how the house would look (colors, sizes of bedrooms) and would perform (have an air-conditioning unit in each bedroom). This is something that owner wants the house to be able to do, a function he/she wants the house to be able to perform.
Q – 3 What are non-functional requirements?
ANS: Non-functional requirements describe the characteristics that a product must have. In the case of a technical system, the example of non-functional requirement would be the need to have a backup-system installed which could be used in the event of disaster to prevent unnecessary data loss. The non-functional requirement therefore describes the attributes a product must possess and not a function that the system must perform.
ANS: Non-functional requirements describe the characteristics that a product must have. In the case of a technical system, the example of non-functional requirement would be the need to have a backup-system installed which could be used in the event of disaster to prevent unnecessary data loss. The non-functional requirement therefore describes the attributes a product must possess and not a function that the system must perform.
Q – 4 What are constraints?
ANS: Constraints can be business or technical in nature and are defined as restrictions or limitations on possible solutions. The project budget, time restrictions, and technical architecture decisions are all examples of constraints. The effect is that the requirements analysts must constrain the requirements to those that can deliver the optimal benefit within the deadline. Whatever they are constraining, constraints can be seen as another type of requirement.
ANS: Constraints can be business or technical in nature and are defined as restrictions or limitations on possible solutions. The project budget, time restrictions, and technical architecture decisions are all examples of constraints. The effect is that the requirements analysts must constrain the requirements to those that can deliver the optimal benefit within the deadline. Whatever they are constraining, constraints can be seen as another type of requirement.
Q - 5 What is the Volere Requirements Process?
ANS: It is the process for successfully discovering, verifying, and documenting requirements. The Volere Requirements Process is meant to be a guide for producing deliverables. What you do with the process is driven by the relevant deliverables, not by the procedures. We would like you to think of the process as a set of tasks that have to be done (to varying degrees of detail) for successful requirements projects, rather than as a lockstep procedure that must be followed at all costs.
ANS: It is the process for successfully discovering, verifying, and documenting requirements. The Volere Requirements Process is meant to be a guide for producing deliverables. What you do with the process is driven by the relevant deliverables, not by the procedures. We would like you to think of the process as a set of tasks that have to be done (to varying degrees of detail) for successful requirements projects, rather than as a lockstep procedure that must be followed at all costs.
Posted By: Navdeep Kaur Sran
Requirements activity is not principally about writing a requirements document. Instead, it focuses on understanding a business problem and providing a solution for it. Software is there to solve some kind of problem, as are hardware and services. The real art of requirements discovery is discovering the real problem. Once you do that, you have the basis for identifying and choosing between alternative solutions.
ReplyDeleteIt is very helpful to use a Volere requirement process for a project as this process gives a opportunity to test the requirements as you writing them. In this process project team makes a requirement test table by adding a fit criterion to that requirement along where the requirements have been written. The criterion given along the requirement measures the requirement and identify whether the given criteria is suitable for a requirement or not. There are mainly three components for volere process:- Requirement knowledge structure, Requirement process, Requirement stakeholder.
ReplyDeleteThose principal truths are extremely necessary for whom wants to be a business analyst because I think those truths provide the must-do and considered things in a project. The truth that most interests me is truth 11 "You, the business analyst, will change the way the user thinks about his problem, either now or later." The responsibilities of a business analyst are not receiving and analyzing the requirements but also have the stakeholders clearly understand their requirements whether it is meaningful and worthwhile to implement. This mean a business analyst must show his or her deep understanding and proofs to persuade the stakeholders. We can say the requirements gathering is one of the most important phases in a project which can determine the success or failure of a project.
ReplyDelete