Information Technology Reference
In-Depth Information
b. Secondary stakeholders
11. Prioritize the requirements by the logical group and within every logical group
a. By timeline
b. By technical feasibility
c. By financial feasibility
12. Identify gaps, in the case of COTS product implementation
a. Between the product and the organizational needs
b. The needs that can be met by re-engineering the organizational processes
c. The needs that necessitate product customization
13. Determine the schedule of implementation for the requirements
14. Resolve the issues/inconsistencies uncovered in the above activities
Before we embark on the analysis of requirements, it is essential that we have
collected as many requirements as possible from all possible sources. When we
analyze the requirements, we may find gaps and may have to go back to sources of
requirements once again to fill the gaps. But we need to have almost all the
requirements to enable us to analyze the collected information. The tendency is to
commence analysis as soon as we collect the information from the end users. Then
we would be having only the core functionality requirements. We need to obtain
the ancillary functionality requirements too before the analysis can begin.
Otherwise, there is every possibility that ancillary requirements are forgotten
altogether or added during software design as an afterthought.
Now let us discuss each of these analysis actions in detail.
Enumerate All the Requirements—It is possible that the requirements are
elicited or gathered over a period of time either by a single individual or multiple
individuals. The requirements are in the form of notes either on paper or on a
laptop. The first step in analyzing the requirements is to transcribe them at one
place from the raw requirements. This will enable us to perform all the analysis
actions enumerated above. It is better to use a requirements analysis tool or a
spreadsheet as these will allow us to carry out data manipulation actions such as
grouping, and uncovering duplicates. The suggested format is shown in Table 4.1 .
It is advantageous to use a structured language while enumerating the require-
ments. That way, we can easily discover duplicates just by sorting the list. We
normally begin recording a requirement with a verb followed by two or three more
(or a limited number) words. Examples are:
1. Capture login information
2. Raise Purchase Order
3. Raise Invoice
Verify each Requirement for Completeness—We need to verify that every
captured requirement is complete. Otherwise, we may not be able to properly
classify the requirement or prioritize it. It is also not possible to carry out software
Search WWH ::




Custom Search