Requirements Analysis - Requirements Engineering and Management for Software Development Projects - page 62

purchase order module in a supply chain project or customer relationship
management project or account heads in a financial accounting project are
modules which would impact many other modules. So these would be imple-
mented first.
3. First come first served—we implement the requirements in the chronological
order they are received/approved.
4. Quickest (or the smallest) first—we implement the requirement that takes the
least amount of effort first and the order will be in the amount of effort needed
to implement it. The reverse (maximum effort or the largest requirement first) is
also possible and is followed in some cases.
5. Most urgent first—the order of implementation would be based on the urgency
of need specified by the organization where the software would be implemented
6. Highest benefit—the order of implementation would be based on the benefit
yield by implementing the requirement. The first one to be implemented is the
one which would yield the highest benefit and the order of implementation
would be based on the decreasing amount of benefit expected from the
requirement.
7. Lowest cost—the order of implementation would be based on the increasing
cost of implementing the requirement. The lowest cost one would be imple-
mented first and the rest would be implemented in the increasing order of the
cost. The reverse (highest cost first) is also possible and is followed in some
cases.
8. Tardiest first—the requirement that is waiting for the longest period is first
implemented. This is resorted to when there are many requirements of equal
priority and are awaiting implementation.
It is also possible to use a combination of these rules to set priorities for the
implementation of the requirements. We need to select the set of rules for setting
the priority and then set the priorities for all the requirements.
Normally we set two-level priorities although three level priorities are also
used. The first level priority indicates the general priority of implementation. If
there is a need to prioritize implementation even within the requirements having
identical priority, the second-level priorities are used. For example the first level of
priority is based on the urgency. If there are multiple requirements of equal
urgency, then we prioritize such requirements based on the amount of benefit they
yield to the organization. Third level, if used, would set the priority if the resource
crunch is such that even the requirements with second level priority need to be
further prioritized.
The resource crunch could be in terms of finances, timelines or technical
limitations.
Identify Gaps, in the Case of COTS Product Implementation—Gaps in this
context should be understood as the mismatch between the features of the product
and the practices/process requirements of the organization. This action is at the
core of requirements analysis in the projects that implement a COTS product for
applications such as ERP, SCM, CRM etc. During elicitation/gathering phases, we