This chapter is from the book
This chapter is from the book
This chapter is from the book
Some Recurrent Themes
Some common themes run through this book. Keep the following themes in mind as you select practices to use on your projects and tailor them to suit each situation.
Requirements development demands an incremental and iterative approach. It’s highly unlikely that anyone will think of all the requirements before development begins and that they will remain unchanged. People get more information, have fresh ideas, remember things they had overlooked, change their minds, and must adapt to changing business and technical realities.
No matter how you choose to represent requirements knowledge, the goal of all specification activities is clear and effective communication. The artifacts the BA produces have multiple audiences. Those audiences may wish to see information presented in different forms and at various levels of detail. Consider those diverse audiences as you create requirements deliverables.
Requirements engineering is a collaborative process. Requirements affect all stakeholders. Many people can supply input to the requirements, many people do work based on them, and many people use the resultant solution. Customer engagement is a powerful contributor to a successful outcome. The BA must work with people who can accurately present the needs of diverse stakeholder communities. Most requirements decisions involve multiple participants with different, and sometimes conflicting, interests and priorities.
Change happens. A solution-development effort is chasing a moving target. Business needs, technologies, markets, regulations, and users change. A BA must keep up with evolving needs and make sure that changes are clearly understood, recorded, and communicated to those they affect.
A powerful way to increase development productivity is to minimize the amount of rework the team must perform. Therefore, try to push quality activities to the front of the development cycle—that is, earlier rather than later. Better requirements pay off with less rework later in development or following delivery.
Use risk thinking to decide which requirements practices to employ, when to perform them, when to stop, and how much detail is necessary. For instance, the risks of miscommunication and wasted effort are greater when development is outsourced or teams are remote than when participants work in proximity. Therefore, requirements for such projects must be written more precisely and in more detail than when developers can quickly get answers from the people around them.