Requirements can be developed and documented for many project and product types. Depending upon your organization and your project, the methodology you use to develop your requirements may range from a “fully dressed,” comprehensive approach to a more agile snapshot of a particular requirement or set of requirements at a particular point in time. I often find that my requirements development efforts need to be scaled or tailored to meet the needs of the organization or a particular project.
In his 2003 Microsoft Press book titled Software Requirements, Second Edition, Karl Wiegers defines four project types that you may find useful as a starting point in deciding just how much requirements development needs doing and how it might be performed. The four types include support and maintenance projects, outsourced projects, packaged solutions and emergent projects.
Support and Maintenance Projects
For maintenance projects, requirements tend to be for modifications made in support of operational systems. These changes occur after the project is complete and the product is being used. Often maintenance projects occur as a response to significant or mission-critical problems or change requests. The challenges you face when developing your requirements as part of support and maintenance include:
Poorly defined and managed requirements between you the customer and your vendor or vendors are a common cause of outsourced project failure. It is important to remember that the developed and documented requirements are the contract basis between you and your suppliers. At a minimum, you as the customer in this equation must provide your potential vendors with a Request for Proposal (RFP) or a Request for Information (RFI) along with a set of detailed product requirements. In addition, it is essential that you have
User requirements are essential when you are purchasing a Commercial Off-The-Shelf (COTS) package. COTS products typically require customization and integration to work in your business and technical environment. Detailed requirements should be used as part of your vendor evaluation and selection process to help you choose the right solution to meet your needs and understand the degree of customization that will be needed.
The focus should be on required capabilities for the COTS package within your current business operation, looking at quality attributes such as performance, usability, flexibility, interoperability, and integrity.
Emergent projects are characterized by uncertain requirements and frequent changes due to rapidly changing market needs or technology drivers. Change is viewed as both inevitable and desirable. These projects demand iterative, incremental, and adaptive approaches to requirements development, running counter to many traditional requirements development processes.
Emergent projects often use agile approaches to put useful functionality into the hands of the users quickly. This means adopting a lean approach to requirements development and documentation and a much more casual approach to requirements management.
It is essential that we tailor and scale out requirements development approach and activities to the project we are working on and the organizational environment we are working within. I find that it really helps me to start with specific project types as the basis for scaling and adapting my requirements development process.
If you are considering sitting the CBAP or CCBA certification exams for business analysts, check out our new study guide that can help you prepare to pass the test, the CBAP / CCBA: Certified Business Analysis Study Guide by Susan Weese and Terri Wagner! It’s a great place to learn more about each of the 6 knowledge areas and everything else you need to know to successfully pass the certification exam