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

hardware or third party software tools are needed to meet the requirement. We
have to evaluate each requirement for its financial feasibility.
Evaluate each Requirement for Its Feasibility—Timeline—This limitation is
encountered frequently in the industry especially in project scenarios. The
requirement is feasible both on a technology basis as well as a financial basis but
the timeline cannot be met. It happens because sometimes, the amount of work to
fulfill the requirement takes longer than the required timeline.
If there are any requirements that are not feasible due to technical, financial or
timeline, we need to resolve them with the end user department. The possible
resolutions are:
1. Drop the requirement altogether
2. Postpone the requirement to a future date
3. Increase the budget (financial as well as timeline) to meet the requirement
4. Obtain the technology from outside the organization (if it is available) to meet
the requirement
Bifurcate Requirements into Core and Ancillary Functionality—This
bifurcation allows us to achieve better grouping of the requirements. This grouping
would help in setting priorities as well as during software design. We assess each
of the requirements and fit them either as a core functionality requirement or an
ancillary functionality requirement.
Group Core Functionality Requirements Together into Logical Groups—
We need to group core functionality requirements by the logical group to which
they belong. This would help in software design. This can be achieved by taking
help from the organization of the function which is the focus of our study. We can
take a bottom-up approach here. First we allocate the requirements to the work-
station at which it is being performed. Normally a set of operations would be
performed at each workstation. Then, we can allocate the requirement to the
department/section in which the person operating the workstation reports to.
Normally the hierarchical levels from the lowest to top level for a major function
would be three or four although exceptions can be found in the industry. The
person holding the workstation would report to a section supervisor who would be
supervising a set of similar workstations and reporting to a manager. The manager
would be managing a few supervisors and reporting to the head of that department.
As an example, if we take a warehouse in a supply chain/material management
application, there would be a few workstations for material issue and a few
workstations for material receipt. Normally all material issue persons would report
to a supervisor and all material receipt persons would be reporting to another
supervisor. Both of these supervisors would be reporting to the person holding
charge of the warehouse. Thus, when we group requirements, we group them into:
1. Warehouse—material issues
2. Warehouse—material receipts
So, we group requirements based on the workstations and departments. This
grouping would facilitate grouping of related functions into modules during the