Project Requirement Gathering:

offbeatnothingSoftware and s/w Development

Dec 2, 2013 (3 years and 10 months ago)

80 views

Project Requirement Gathering:
Recommended "Best" Practices


Edward
Kuligowski

Bellevue
University

CIS 665


Click to Preview

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.


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).

Requirements

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).

Requirement Analysis
and
Negotiation


Due to the informal nature of the elicitation process some requirements can be considered incomplete and promote conflict wit
h
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 compatibili
ty
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

th
e
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

th
e
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 h
ave

tractability throughout the project lifecycle. Requirement tractability fosters overall project quality, gives understanding

an
d
meaning to the product, provides the bases to verify and test against, and allows the ability to make changes to the project
dur
ing
the lifecycle (Lopez, 2011).



Requirement changes can occur during the elicitation and analysis phase, and even after the deliverable have been given to th
e
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).



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).

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.

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.

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.