Project Requirement Gathering: Recommended "Best" Practices

1. Click to Preview Project Requirement Gathering: Recommended "Best" Practices Edward Kuligowski Bellevue University CIS 665

2. Customer’s Primary Concerns • Projects are failing because of unmeet customer requirements. Therefore a standard of best practice requirement gathering process and policies must be created for the firm to govern its requirement gathering actives. • The primary concern of the executives is overall customer satisfaction. Therefore the policy must be tuned to the needs of the customers and their expectation throughout the project lifecycle.

3. Requirements • Young defines a requirement as a statement of a customers need, a condition of a deliverable, a specified capability, a characteristic, or a specified quality a system must provide in order to meet the need and provide value to the end-user (Young, 2006). • As the cornerstone on which a projects scope, schedule and budget are built upon, requirements must be clearly understood, and agreed upon by all stakeholders of a project (Young, 2006). • Requirements should contain attributes that make them unambiguous, verifiable, traceable, modifiable, usable, consistent, and complete (Lopez, 2011). • Requirement gathering activities or phases for a project include elicitation, analysis and negotiation, and verification and validation. These requirement gathering activities run in tandem throughout the project lifecycle with the management processes where they are track and documented and controlled (Adisa, Schubert, Sudzina, & Johansson, 2102).

4. Requirements Elicitation • Requirement elicitation means to “bring out, evoke, or call forth” requirements from stakeholders, customers, and end-users. The goal behind elicitation is to gather information from stakeholders that can be processed to define the constraints of the project (Abdulah, Abdulrahman, & Anusuyah, 2012). • Types of elicitation techniques to gather and define requirements include, one-on-one interviews with stakeholders, group interviews, facilitated sessions, joint application development (JAD), questionnaires, prototyping, use cases, procedure study (individual observation to determine process requirements), request for proposals (RFPs), and brainstorming (Mochal, 2008).

5. Requirement Analysis and Negotiation • Due to the informal nature of the elicitation process some requirements can be considered incomplete and promote conflict with stakeholders, therefore requiring further analysis and negotiation (Abdulah et al., 2012). Requirement analysis involves the refining and further elaboration of each function and purpose of individual requirements (Lopez, 2011). • During the negotiation process requirements are categorized into subsets and reviewed for cross functionality and compatibility issues expressed by all stakeholders on the project (Lopez, 2011). Through good communication and management practices these requirements can be utilized to provide a high level of product quality, and become a governing factor that defines the constraints of the project itself. The identified conflicts and priorities are deliberated upon, and agreements reach before the requirement can be transferred to the specification stage of the gathering process. • Requirement specifications are derived during the elicitation stage, and refined during the analysis and negotiation stage of the gathering process. A specification is then considered a suitable guideline the project team can then use to complete the deliverables for the customer and meet their expectation (Lopez, 2011). Requirement specifications allow the requirement to have tractability throughout the project lifecycle. Requirement tractability fosters overall project quality, gives understanding and meaning to the product, provides the bases to verify and test against, and allows the ability to make changes to the project during the lifecycle (Lopez, 2011). • Requirement changes can occur during the elicitation and analysis phase, and even after the deliverable have been given to the customer. Therefore proper change management practices must be implemented to handle the new requirements during the project lifecycle. Change requirements should be well documented and thoroughly analyzed to determine the effect the requirement will have on the existing project. The change should be reviewed and compared to the scope of the project, risk determined, and an impact study performed before the change is Okayed and then communicated to the project team (Lopez, 2011).

6. Requirement Analysis and Negotiation • Proper analysis and negotiation is critical during the early stages of the project lifecycle do to the impact of a missed or incomplete requirement in the advanced stages of the project. Schwalbe states “A dollar spent up front in planning is worth one hundred dollars spent after the system is implemented.” (Schwalbe, 2010).

7. Requirements Validation and Verification phase • During the validation and verification phase the requirement specifications are used as a metric in which a technical review of the project can be performed to ensure the requirement is met and the need of the stakeholder is fulfilled (Lopez, 2011). • The verification process ensures that quality levels of the requirements have been accomplished throughout the lifecycle of the project, the requirements meets the stakeholders functionality expectations, and that the product conforms to the agreed upon process and standards of the project sponsors (Lopez, 2011). • The validation process involves a conformation that all the “real” requirements have been met and are implemented into the system as a whole (Young, 2006). • System validation is performed after verification to ensure the quality of the deliverable is meet and that all verified requirements function as one single unit as the stakeholders specified.

8. Conclusion • With the majority of project failures stemming from the lack of meaningful, unambiguous, verifiable, traceable, modifiable, usable, consistent, and complete requirements the importance of a good practice policy is crucial to the success of any organization. In addition, to properly vet and define the real requirements of a project an organization must implement a policy that practices requirement gathering activities that include elicitation, analysis and negotiation, and verification and validation. With implementation of these requirement gathering activities, ran in tandem throughout the project lifecycle with good management processes both the project sponsor and the project team can ensure the success of the project and the overall satisfaction of the end-user.

9. References Abdulah, A. S., Abdulrahman, A. N., & Anusuyah, S. (2012, November, 2012). Requirements Elicitation For Software Projects. International Journal of Computer Science and Information Security, 10(11), 64-71. Adisa, F., Schubert, P., Sudzina, F., & Johansson, B. (2102, April 12, 2010). Living Requirements Space: An open access tool for enterprise resource planning systems requirements gathering. Online Information Review, 34(4), 540-564. Retrieved from www.emeraldinsight.com/1468-4527.htm Ghai, S., & Kaur, J. (2012, November, 2012). Analysis of User Requirements Gathering Practices in Agile and Non-Agile software Development Teams. International Journal of Computer Applications, 58(8), 13-18. Hofmann, H. F., & Lehner, F. (2001, July/August 2001). Requirements Engineering as a Success Factor in Software Projects. IEEE Software, 58-66. Lopez, O. (2011). Requirements Management. Journal of Validation Technology, Spring 2011(), 78-86. Mochal, T. (2008, January 2, 2008). 10 Techniques for gathering requirements. TechRepublic. Retrieved from http://www.techrepublic.com/blog/10things/10-techniques-for-gathering-requirements/287 Reeves, L. (2004, March, 2004). Gathering More Than Requirements. DM Review, 14(3). Schwalbe, K. (2010). Information Technology: Project Management (6th ed.). Boston, MA.: Course Technology, Cengage Learning. The Standish Group . (2001). CHAOS. CHAOS REPORT, 1-8. Verner, J. M., & Evanco, W. M. (2005, January/February 2005). In-House Software Development: What Project Management Practices Lead to Success? IEEE Software, 86-93. Young, R. R. (2006). Project Requirements : A Guide to Best Practices. Vienna, VA: Management Concepts.