Solution

Functional Requirements

• Requirements should be collected and defined by the procurement requester, business owner, or their assigned teams. They should seek help from the procurement personnel and other SCRM team members. One major output of this team effort is to identify the requirements for the procurement and how these requirements will apply to the supply items.

• Functional requirements are domain-specific related to the services that requested system or service will provide. It is important to select, from supply options, those that best fit the requested system or service with best budget, time, quality, etc. As we can see, there are many goals or desired attributes that ideally should exist in selected supply item.

• However, in practical limitations may exist that will force companies to settle with less than ideal choices. First one is related to the availability of different options from different vendors or suppliers. The popular Porter value chain model indicates in one of the five supply forces that the bargaining power of buyers is limited if supply options are limited.

• How can we judge that the acquired system is the best fit for the request? In project or system analysis, it is important to distinguish between two stages:

• Existing system analysis: This analysis focuses on the “problem domain”; what are the existing problems in the current system that triggers this IT procurement project.

• Acquired system specifications: What are the requested/desired features that should exist in the acquired system?

• IT procurement systems should ideally include both parts (Existing system anal- ysis and Acquired system specifications; indicating that system in the two terms refers to completely different systems). In some projects, contents from those two parts will be mixed without clearly differentiating between requirements related to what the current system has from requirements from what the solution should have or should impact on the current system.

Quality Requirements

• Quality requirements or also called non-functional requirements complement func- tional requirements. Those are general desired characteristics (e.g., quality, perfor- mance, reliability, usability, maintainability, security) that the solution system should have.

• Requirement of project requesters should be different between “must have” quality requirements and “desired to have” quality requirements. Making all requirements in one category whether “must have” or “desired to have” is not a wise selection.

• Those differences in the classification of the requirements can be the main criteria to decide which supplying option to select. While it is desired to have all kinds of high-quality requirements, selection team should be able to make decision related to:

• What functional or non-functional requirements that cannot be compromised and that they should exist in acquired system exactly as described. Alternatively, team should also be able to distinguish what are the requirements that can be compromised to a lower level and what is the accepted level.

• In most cases, different suppliers will offer different detail services. Team should be able to evaluate and judge those different quality attributes and compare them with each other or compare them with offered costs.

Security Requirements

• Security requirements can be seen as one major category of quality requirements described earlier. However, in most cases, those security requirements cannot be compromised especially with government contracts or systems required to meet certain standards or regulations.

• It is important for selection team to be aware of necessary or “must have” security requirements in the subject system in accordance with accepted standards or regulations. We described in other sections examples of some of those standards and regulations.