Running head: COMPUTER SCIENCES AND INFORMATION TECHNOLOGY 1

Computer Sciences and Information Technology

Name

Institutional Affiliation
COMPUTER SCIENCES AND INFORMATION TECHNOLOGY 2

Computer Sciences and Information Technology

1. What are the one or two most challenging issues in identifying and documenting IT

acquisition requirements (i.e., the requirements for solving the problem that was

defined)? Explain your reason(s) and how the issue(s) can be successfully addressed.

The identification and documentation of IT acquisition requirements may face some

challenges along an investment. These challenges may directly or indirectly affect fund

expenditure that may address a single acquisition or a group of software, hardware, support

and telecommunication services involving multiple IT acquisitions (Gopal, Jadoo, L.P. &

Devi, 2016). One of the major challenging issues is the quality of the acquisition

requirements. If the IT acquisition requirements identified and documented is of poor quality,

it shows ambiguity, errors, non-cohesiveness, inconsistency, lack of traceability, and

incompleteness, more especially when described with a technical language rather than a

business language that is limited to the system features. According to Gopal et al., 2016,

poor quality IT acquisitions lack the feasibility for implementation and lack critical metadata

such as priority and status. Most stakeholders find poor quality IT acquisitions unverifiable

and in unusable form. A project with poor quality requirements is affected by schedule

delays, cost overruns, staff loss, performance shortages, resources and time.

Poor quality in IT requirements can be addressed through adherence to the quality

standards set considering the quality of project and the timelines. Training is essential to

ensure evaluator and engineers understand the features of proper IT acquisition requirements.

It is also critical to distinctively differentiate between good quality and poor-quality

requirements. Moreover, a suitable control should be established by the developers over the

requirements and the scope of any project undertaken. The software architecture and test

teams play a vital role in requirement specification and ensure the described requirements are
COMPUTER SCIENCES AND INFORMATION TECHNOLOGY 3

feasible and verifiable (Gopal et al., 2016). Lastly, the collaboration of engineers and

stakeholders ensures the requirements have the desirable quality.

2. Should it be permitted to add, delete, and change requirements after they have been

approved up to the time a contract has been signed with a service provider? Should it

even be possible to add, delete, and change requirements during the subsequent

project?

A contract clearly indicates the roles and responsibilities of each party involved.

During the bidding process, participants may consider renegotiations for a contract in the

future. A contract may be modified to increase the length of time or the time restrictions

(Jung, Kosmopoulou, Lamarche & Sicotte, 2018). Other possible reasons of changing the

contract requirements by either party is to increase or decrease the service or item quality and

alteration of the outlined mode of delivery or mode of payment (Jung et al., 2018).

The contract is approved and signed in the subsequent projects, permission should not

be granted to delete, change or add the requirements because of duty execution by the service

providers. In case alteration is done, project delays may be experienced and both parties must

negotiate on any other additional requirements. Adding, deleting and changing the

requirements may lead to proliferation in cost and quality of service (Jung et al., 2018).

After both parties have an agreement on project aspects such as budget, scope,

deliverables, time, resources and components, it should not be permitted to add, change or

delete the requirements on a subsequent project which may result to increase or decrease in

cost and a change of resources to complete the project. It is critical for the contract to be

reviewed before signing to avoid the need to change, delete and add any requirements.

3. The development of a work breakdown structure can be challenging. It requires a

good understanding of the problem and a good understanding of the proposed solution.

The proposed solution must be "broken down" into its major parts, each of which may
COMPUTER SCIENCES AND INFORMATION TECHNOLOGY 4

be further broken down. Comment on your experience in developing a work breakdown

structure for your individual project. What was easy? What was difficult? What

problems did you encounter and how did you solve them?

Work breakdown structure (WBS) is used by project managers in mapping an entire

project from the start to completion which entails breaking down a big project into small core

tasks and deliverables. (Jon & Kenneth, 2016). I have developed many websites over the

years. A WBS is developed for each of the websites I develop to make work easier and work

within a specific timeline and best manage the budget to deliver a full project. Developing the

WBS levels, tasks and subtasks was a walk in the park for me. However, I also encountered

some challenges such as determination of the amount of detail to be used in the WBS. The

determination the detail is purely based on judgement and experience which can be

challenging at times. I contacted one of project engineers to assist in the determination of the

amount of detail every time I encounter such a challenge in order to complete the WBS.
COMPUTER SCIENCES AND INFORMATION TECHNOLOGY 5

References

Gopal, K., Jadoo, S., L.P., J., & Devi, V. (2016). Software Quality Problems in Requirement

Engineering and Proposed Solutions for an Organization in Mauritius. International

Journal of Computer Applications, 137(2), 23-31. doi: 10.5120/ijca2016908698

Jon, F., & Kenneth, P. (2016). Work breakdown structure (WBS) handbook. Washington,

D.C.: National Aeronautics and Space Administration.

Jung, H., Kosmopoulou, G., Lamarche, C., & Sicotte, R. (2018). Strategic Bidding and

Contract Renegotiation. International Economic Review, 60(2), 801-820. doi:

10.1111/iere.12368