BELL MTS

Scoping the Business Problem This chapter concludes the importance of knowing and determining the scope, stakeholders, and goals.   The Volere process model, describes the first activity as Project Blastoff where key factors that, taken together, determine the viability of the requirements project.  Project Blastoff The blastoff identifies the boundary of the work area and determines the purpose the product is to fulfill. It also identifies the stakeholders—those people who have an interest in the success of the product. The main purpose of a blastoff is to lay the groundwork so the requirements discovery for a project is efficient and effective. The blastoff produces a number of deliverables. The main Project Blastoff deliverables that are needed to be determined are: Purpose of the project : This explains what the product is ought to do and what kind if benefits it is required to bring to the business.  This justifies the project and serves as a f...

ABOUT CHAPTER This book is the distillation of the experiences and in this they describe the experience that have been derived in years of working in the requirements arena (field). This chapter also discuss about development of the Volere Requirements Process and its associated specification template from the activities and deliverable that had proved themselves to be most effective in project and consulting assignments with the stakeholders or clients. Most stress since the very beginning that while presenting process, we are using it as a vehicle for discovering requirements. The Volere Requirements Process is shown in Figure 2.1. Each of the activities included in the figure, along with the connections between them, is described in detail in subsequent chapters of this book. PROJECT BLAST-OFF The main reason of the project blastoff is to build the foundation for the requirements findings that is to follow, and to make sure that all the required components for a success...

Requirements exist whether you discover them or not, and whether you write them down or not. Obviously, your product will never be right unless it conforms to the requirements, so in this way you can think of the requirements as natural law, and it is up to you to discover them. The owner is the person or organization that pays for the software. On the other side of the ledger, the owner gets a benefit from the software. To describe that relationship very simply, the owner is buying a benefit. On the other side of the ledger, the owner gets a benefit from the software. To describe that relationship very simply, the owner is buying a benefit. The software becomes more capable and the cost of construction increases, so the benefit that the software brings. At some point, however, the cost of construction starts to outstrip the benefit and the project is no longer beneficial. If software does not have to satisfy a need, then you can build anything. In any case, on the off chance that...