Software requirements gathering is a key focus area in a software development lifecycle. It takes skill to plan and facilitate requirements gathering sessions. In this post, I will review common software requirements gathering best practices to set you up for success with your project.
What is Software Requirements Gathering?
Software requirements gathering is the process of collecting and eliciting the requirements for a project from all stakeholders through meetings and interviews. Requirements include functional, non-functional, and technical functionality. Through a series of meetings, requirements are collected, documented, verified, analyzed, prioritized, validated, and accepted by the stakeholders. It is important that scope and requirements are clear, concise, and unambiguous. The stakeholders required to sign-off the scope and requirements should be documented in the Scope and Requirements Management Plan.
Activities in Requirements Development
– Identifying the products user classes.
– Eliciting the needs from the users who represent each user class.
– Understanding user tasks and goals and the business goals with which those tasks align.
The time spent understanding user needs is a high leverage investment in project success. If the software developers do not have written requirements that fulfill customer needs they satisfy those customers. Writing requirements isn’t the hardest part; discovering the requirements is the hardest part. Never assume requirements.
Benefits from high-quality requirements process:
– Reducing unnecessary re-work during the late development stages and maintenance periods.
– Try to get customer feedback early rather than later.
Requirements Specifications Characteristics:
– Complete: Focus on user tasks
– Consistent: They don’t conflict with other requirements
– Modifiable: Modify for changes
– Traceable: Requirements should be linked backwards to its origin and
forward to the design elements, source code, and test cases.
Requirement Statement Characteristics:
– Complete
– Correct
– Feasible
– Necessary
– Prioritized
– Unambiguous
– Verifiable
Business and Technology Alignment:
All projects begin with a Statement of Work, Business Case, Project Charter, or some form to initiate the project. To begin, you must keep make sure the business requirements identified during project initiation are aligned with the business strategy. Meet with the project sponsor and key stakeholders to ensure you clearly understand the goals and objective for the engagement. In order to ensure business accountability, alignment can only be successful through a well-defined traceability process. Review the Statement of Work or similar initiation forms. Then begin documenting high level business requirements. Using a Requirements Traceability Matrix is a great place to begin.
Understand the three levels of Requirements:
1. Business Requirements: Business Requirements represent the high-level
objectives of the organization. It’s the “WHY” the organization want to
implement a process or system change, addition, or upgrade.
2. User Requirements: User Requirements represent the user goals or tasks that the users must be able to perform with the system once it is implemented. It’s the “WHAT” the users can do.
3. Functional Requirements: Functional Requirements specify the software functionality the developers must build to allow the users to accomplish their tasks with the new system.
Benefits from high-quality requirements process:
Reduces unnecessary re-wok during the late development stages and maintenance
periods.
Characteristics of good requirements:
Complete: Focus on user tasks
Consistent: Requirements do not conflict with other requirements
Modifiable: Requirements should have the ability to be modified for changes.
Traceable: Requirements must be traceable back and forth between business
objectives and user task.