Sunday, October 12, 2014

Requirements Gathering

Requirements gathering, and requirements analysis are the most important parts of any software development project and IS projects in general. IS facilitates and helps all industries to be more productive and automate manual work for departments within organizations. Business people explain their requirements to project manager or system analysts, and then developers start to develop and build applications to satisfy those requirements. All stakeholders should be committed to the requirements gathering process because it’s the foundation for any software development project.

Requirements gathering process should be documented and communicated with all stakeholders, as this will form the basic design document that the software development will be based on. It is important to understand the differences in perception between business users and developers with regards to requirements, business users care most about the user requirements, which are the tasks and features the system should offer to the end user to allow him to perform his job. While for developers, requirements could be the technical requirements for them to be able to satisfy users requirements; developer’s technical requirements are referred to as functional requirements. On the other hand, system requirements refer to the top-level requirements for a product that contains multiple systems; this could be software, hardware, human resources and more (Wiegers, 2009). User requirements should be defined, maintained and under the responsibility of the business managers, while functional requirements should be defined, maintained, and under the responsibility of Information system managers, each functional manager should define and take ownership of the responsibility that fit under their area of expertise to develop the best set of details required to satisfy the project requirements. And both being IS management, and business management are responsible for the system wide requirements, its definition, maintenance, analysis, and communication. IS software is built to facilitate and help business managers perform tasks for their departments; they have to insure that their requirements are properly defined, documented and satisfied.

Defining requirements is under the responsibility of both parties being IS management and business management, each should define his requirements, as well both are responsible for defining, maintaining and satisfying system wide requirements, else the project won’t deliver the required functionality and won’t satisfy its objective.

Reference:

Paetsch, F., Eberlein, A. & Maurer, F., (2003), ‘Requirements Engineering and Agile Software Development’, IEEE, [Online]. Available from: http://www2.enel.ucalgary.ca/People/eberlein/publications/WETICE_03.pdf

(Accessed 2 June 2012)

Wiegers, K., (2009), ‘Software Requirements, Second Edition’, O’Reilly, [Online]. Available from:

http://books.google.com.qa/books?hl=en&lr=&id=WcO3Ca9NuvQC&oi=fnd&pg=PT1&dq=system+requirements+responsibility&ots=d94hFeG6Ag&sig=0r0hrJ6sMwhAG4PbCx9X5Q3huWo&redir_esc=y#v=onepage&q=system%20requirements%20responsibility&f=false

(Accessed 2 June 2012)

Zisman, A., Spanoudakis, G., Pérez-Miñana, E. & Krause, P., (2003), ‘Tracing Software Requirements Artefacts’, [Online]. Available from:

http://www.soi.city.ac.uk/~gespan/serp03.pdf

(Accessed 2 June 2012)

No comments:

Post a Comment