Chapter 2 - The Requirements Process
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 successful project are in place. The principal stakeholders - the sponsor, the key users, the lead requirements analyst, technical and business experts, and other people who are important to the success of the project - gather together to arrive at a consensus on the crucial project issues.
When they have arrive at a reasonable agreement on the scope of the business area to be studied, the group identifies the stakeholders. The stakeholders are those people who have an interest in the product, or who have knowledge regarding to the product - in fact, anyone who has requirements for it. For the Ice Breaker project, the people who have an interest are the road engineers, the truck depot supervisor, the weather forecasting people, road safety experts, ice treatment consultants, and so on. These people must be identified, so that the requirements analysts can work with them to find all the requirements. The context diagram, by establishing the extent of the work, helps to identify many of the stakeholders.
Back - up, if too many unknowns remain at this point, the blastoff group might decide to start the requirements investigation with the intention of reviewing the requirements after a short while and reassessing the value of the project.
TRAWLING FOR REQUIREMENTS
After the blastoff is completed, the business analysts began trawling the work to learn and understand its functionality - “What’s going on with this crumbs of the business, and what do they want it to do?” For convenience and consistency, they partition the work context diagram into business use cases.
The Ice Breaker product must not be a simplistic automation of the work as it is now done; the best of our automated products are not mere replications of an existing condition. To deliver a truly useful product, the analytical team surely work with the stakeholders or customers to innovate - that is, to develop a good way to do the work, and a product that supports this better way of working. They make use of innovation workshops where the team uses creative thinking techniques and innovative triggers to generate new and better ideas for the work and the eventual product.
QUICK AND DIRTY MODELING
Models can be used at any time in the Volere life cycle; in Figure 2.1, depicts this activity as “Prototype the Work.” There are, formal models such as we would find in UML or BPMN, but most of the time business analysts can make productive use of quick sketches and diagrams to model the work being investigated. One quick and dirty modeling technique mentioned here is using Post-it notes to model functionality; each note can be used to represent an activity, and the notes can be rapidly rearranged to show different ways the work is done or could be done. We find that stakeholders or clients relate to this way of modeling their business processes, and have their approval to participate with hands-on manipulation of the Post-its to show what they think the work should be. Their is a detailed analysis of this type of modeling in Chapter 5, Investigating the Work.
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 successful project are in place.Once the blastoff is completed, the requirements analysts start trawling for requirements. They learn the work being done by the business area identified by the blastoff.There are, formal models such as we would find in UML or BPMN, but most of the time business analysts can make productive use of quick sketches and diagrams to model the work being investigated.
ReplyDeleteThis chapter help me to understand how requirement process works. I also learned how requirements analysts start trawling for requirements after blastoff is completed. So, I understand the activity of trawling, how they discover the requirements and the analytical team members sit with the hands on users as they describe the work that they do and the work that they hope to do.The requirements analysts also consult with other interested stakeholders usability people, security, operations, and so on to discover other requirements for the eventual product.
ReplyDeleteThis explains the different processes used to discover the requirements and communicate the requirements more accurately and productively with other stakeholders. The companies adapt these process to their own cultures and organisations. To build a right product, right requirements are necessary to be discovered and to do so we need some kind of orderly process. The Volere Requirements process shows all the activities needed to be done and the connections between them. To build the foundations for requirements, Project Blast-off is used. The principal stakeholders gather together to discuss the project issues. The project blast-off define the scope of business problem and in the blast-off meeting it is confirmed that what is to be included in the project and what needs to be excluded.
ReplyDelete