Project Requirement Gathering: Recommended 'Best' Practices



Project Requirement Gathering: Recommended "Best" PracticesEdward KuligowskiBellevue UniversityCIS 665AbstractA projects success is dependent upon the ability of managers, project managers, organizations, and individuals to gather and process accurate requirements in order to meet the needs of the stakeholders. Therefore many organizations are seeking a “best” practice model to implement into their industry to ensure requirements are gathered and analyzed properly resulting in an overall increase in end-user satisfaction and project success.The purpose of this paper is the development of a “best” practice model that can be implemented into the organization project policies to ensure requirements are gathered and analyzed properly and foster continuous improvement practices within the organization. This paper will discuss the development of a requirements gathering model in which an organization can perform “best” practices while gathering requirements to ensure that the stakeholders, customers, and end-users are satisfied with the final deliverables of the project. This formulation was based on the customer’s primary concerns as stated below:1.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.2.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. Project Requirement Gathering: Recommended "Best" PracticesIntroduction:The Data and Analysis Center for Software (DACS), a division of the U. S. Department of Defense, released a report stating that 75% of large software projects suffer from large budget overruns or fail completely (Young, 2006). In addition, the 2001 Standish Groups CHAOS report reiterates the DACS claims stating that 31.1% of projects in the U.S. will be canceled, and 52.7% of projects will have budget overruns of an average 189% of the original estimate (The Standish Group, 2001). The failure rate and cost overruns of most projects can be traced back to improper requirement gathering techniques, poor requirement engineering practices and lack of end-user involvement (Ghai & Kaur, 2012). The DACS states that over 50% of the issues related to project failures and cost overruns are related to missed, ambiguous, or miss managed requirements (Young, 2006). Furthermore, the CHAOS report participants, when surveyed, attributed these project problems to lack of user input (12.8% project failure rate), incomplete requirements and specifications (12.3%), and changing of requirements and specifications (11.8%) to the cause of project failure and cost overrun (The Standish Group, 2001).Young refers to communication as the backbone of any project (Young, 2006). A study performed by Verner and Evanco outlines the value individual project management practices and reinforces Young’s claims with data that directly correlates the measured project success rate with good communication practices, user involvement throughout the requirement gathering process, a clear focused vision and scope, and general good project managerial practices with project success (Verner & Evanco, 2005). Quality of service was rated the highest in Hofmann’s and Lehner’s study which 76% of stakeholder’s attributed to the success of the project (Hofmann & Lehner, 2001). Stakeholder’s frequent involvement in requirements gathering, good communication practices, and consistent group interactions lead to the importance and high success rating for this dimension of the project (Hofmann & Lehner, 2001). Research continually supports the need for organizations in today’s global economy to formulate “good practice” policies in order to ensure project success and customer satisfaction. The common thread in all the supporting research leads to proper requirement definition and communication skills to deliver a quality product that fulfills the needs of the customer.Requirement Gathering Best Practices: 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).Requirement elicitation means to “bring out, evoke, or call forth” requirements from stakeholders, customers, and end-users (Abdulah, Abdulrahman, & Anusuyah, 2012). The goal behind elicitation is to gather information from stakeholders that can be processed to define the constraints of the project (Abdulah et al., 2012). An organization should utilize established elicitation techniques to gather and define requirements such as 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). When properly executed research has linked the utilization of these tools or a combination of these tools to overall project success and end-user satisfaction (Adisa et al., 2102). The stakeholder requirements gathered during the elicitation phase are considered the initial requirements that provide a statement that defines a need or problem for the end-user. These statements should be well documented and state no more than what is required to define the problem and avoid providing a solution (Adisa et al., 2102). In addition, throughout the elicitation process relationships and partnerships begin to develop that will continually promote an environment of continuous improvement and a critical factor in project success (Reeves, 2004). This partnership that begins to foster is forged through group involvement on every level of the project in conjunction with good management practices. These events help increase the quality of service the sponsors receive which is directly correlated with a successful project by most project sponsors (Hofmann & Lehner, 2001). 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). After refinement and the “real” requirements are established the requirements then enter a negotiation process. 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 specification 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 specification allows 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).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).Schwalbe’s statement can explained further by examining figure 1 which indicated the exponential effect of fixing a requirement during the project lifecycle. As a project progresses, and a plan is established changes often occur to the requirements. 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). Lastly, the requirements need to pass through a 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. 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. ReferencesAbdulah, 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 1468-4527.htmGhai, 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 , 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. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download