Вы находитесь на странице: 1из 31

Requirements Analysis

Analysis of the Information Collected i

the Elicitation
 When we complete elicitation of requirements, we
have information in the raw form.
 When we analyze it, we would have plausible
requirements which after review and approval would
transform into project requirements.
 We carry out the following analysis activities on the
information obtained through elicitation and
Analysis of the Information
Collected in the Elicitation

Enumerate/list all the requirements

Verify each requirement for completeness

Evaluate each requirement for its feasibility

• Technical
• Financial
• Timeline

Group core functionality requirements together into logical groups

Identify requirements that are duplicated

Identify requirements that are contradictory to each other

Identify system interfaces

Analysis of the Information Collected in the
Identify stakeholders for each requirement

• Primary stakeholder
• Secondary stakeholders

Prioritize the requirements by the logical group and within every logical group

• a. By timeline
• b. By technical feasibility
• c. By financial feasibility

Identify gaps, in the case of COTS product implementation

• Between the product and the organizational needs

• The needs that can be met by re-engineering the organizational processes
• The needs that necessitate product customization

Determine the schedule of implementation for the requirements

Resolve the issues/inconsistencies uncovered in the above activities

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
 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
 It is advantageous to use a structured language while
enumerating the requirements.
Enumerate All the Requirements

 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
Requirements Enumeration Table
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.
 To ensure the completeness of a requirement, we ensure that its:
 1. Inputs are defined
 2. The validations that need to be performed on the input data are
 3. The process of converting the inputs to outputs is defined
 4. The outputs expected from the process are defined
 5. All the relevant templates and formats are available
 Once we have all this information for a requirement, it can be
deemed to be complete.
Evaluate each Requirement for Its
 Technical feasibility includes limitations of hardware,
software or algorithmic.
 Sometimes the requirements may not be feasible to be
achieved with the current state of technology or the
technology available within the organization.
 Examples include certain types of analyses that are
easily performed by the individuals but cannot be
performed automatically.
Evaluate each Requirement for Its
 Sometimes, the requirements may be technically
feasible but in our considered opinion, are too costly to
fit into the available budget.
 Such possibilities occur when a specialized hardware
or third party software tools are needed to meet the
 We have to evaluate each requirement for its financial
Evaluate each Requirement for Its Feasibility—

 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.
Evaluate each Requirement for Its
 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) and/or timeline to meet the
 4. Obtain the technology from outside the organization (if it
is available) to meet the 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
which is the focus of our study.
 We can take a bottom-up approach here. First we allocate the
requirements to the workstation at which it is being performed.
 Normally a set of operations would be performed at each
 Then, we can allocate the requirement to the
department/section in which the person operating the
workstation reports to.
Group Core Functionality Requirements Together
into Logical Groups

 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.
Identify Requirements that are Duplicated

 Especially in large projects wherein requirements are collected

from multiple agencies, it is possible that stated requirements
are duplicated.
 We need to eliminate the duplicated requirements so that
design effort is not wasted.
 We can sort the requirements by the ‘‘Requirement
Description’’, second column of enumeration table
 We can examine if any requirements are duplicated and if any
such duplication is uncovered, we can easily eliminate such
 This step is in fact a cleansing step that provides us unique
Requirements Enumeration Table
Contradictory Requirements
 Consistent: no two requirements are in conflict (contradiction).
 The specified characteristics of real-world objects may conflict.
 the format of an output report may be described in one requirement as
tabular but in another as textual.
 There may be logical or temporal conflict between two specified actions. For
 One requirement may specify that the program will add two inputs and
another may specify that the program will multiply them. (logical)
 One requirement may state that A must always follow B, while another may
require that A and B occur simultaneously. (temporal)
 Two or more requirements may describe the same real-world object but use
different terms for that object.
 For example, a program request for a user input may be called a prompt in
one requirement and a cue in another. The use of standard terminology and
definitions promotes consistency.
Identify Requirements that are
Contradictory to each Other

 This step is also a cleansing step but is not as easy as locating

duplicate requirements.
 If we have contradictory requirements and allow them to slip
through design and construction, we would have a software
product that provides unpredictable/unreliable results.
 To identify contradictory requirements, we need to study each of
the requirements; understand it in the right perspective and then
see if any other requirement is contradicting the one at hand.
Tips for identifying contradictory requirements

 1. When requirements for the same function are collected from

two or more workstations, we are likely to receive
contradictory requirements.
 When looking for contradictory requirements, we need to look
into the requirements specified for the same function by
different individuals.
 2. It is likely to have contradiction between the perceptions of
the person performing a function and the individuals providing
inputs or receiving outputs from that function.
 So, we need to look closely at the requirements specified
by the individual performing a function and the persons
providing inputs to that function or receiving outputs from
that function.
Tips for identifying contradictory

 3. There is also a possibility of contradiction in the

perceptions of the person performing a function and his
 It is more likely to be so if the length of experience of
these two individuals varies significantly. That is, one of
them is new to the function and the other is much more
 Summarizing, there is a possibility of contradiction in the
requirement if more than one individual provides information
for that requirement. So examine all such information and
eliminate contradictory requirements
Ambiguous Requirements

 Unambiguous: An requirement is unambiguous if, and only if,

requirement stated therein has only one interpretation.
 “A user shall be able to search the appointments lists for all
 “Aircraft that are nonfriendly and have an unknown mission or
the potential to enter restricted airspace within 5 minutes shall
raise an alert”
 Combination of “and” and “or” make this an ambiguous
 In cases where a term used in a particular context could have
multiple meanings, the term should be included in a glossary where
its meaning is made more specific.
Identify System Interfaces
 End users are likely to cross system boundaries and give requirements that form
part of another system.
 Cafeteria Ordering System example
 Whenever end users specify requirements that actually form part of another
system, we need to identify them as requirements for interfaces with other
systems. We need to identify all such requirements and classify them under system
interface requirements.
 When we identify a system interface requirement, we need to ensure that:
 1. The other system with which the interface is needed is identified
 2. The data to be received from the other system is defined
 3. The data that is to be transmitted to the other system is defined
 4. The protocols, if any, for the interface are identified
Identify Stakeholders for each

 We need to identify the stakeholders for each of the

 These are the persons who need to be approached during
the project execution for any clarification about the
 The primary stakeholders of course, are the individuals
performing the function and the secondary stakeholders
are the superiors, providers of inputs to and recipients of
outputs from the person performing the function.
 We need to carry out this task for each of the
Prioritize the Requirements

 Prioritization is the setting of the order of

implementing the requirements when there is a
resource crunch.
 This priority will help the project management to
implement requirements of higher priority first if
they find themselves short of the requisite
Rules for setting priority

Dominant factor first—sometimes, it may be possible that a certain function

needs to be implemented first.
 For example, in most applications there would be master data files and
without these being created/maintained, the application would not run.
 Therefore, they need to be implemented first.
 This type of constraint is referred to as the dominant factor.
Most linked first—in many applications there would be some modules which
would have maximum linkages with the remaining modules.
 For example, the purchase order module in a supply chain project would
impact many other modules. So these would be implemented first.
First come first served—we implement the requirements in the chronological
order they are received/approved.
Rules for setting priority

 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.
 Time is influenced by many other factors such as degree of
parallelism in development, training needs, need to develop
infrastructure, industry standards, etc
 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.
Rules for setting priority

 Lowest cost—the order of implementation would be based

on the increasing cost of implementing the requirement. The
lowest cost one would be implemented first and the rest
would be implemented in the increasing order of the cost.
 The implementation cost is usually estimated by the
developing organization.
 Measures that influence cost include: complexity of the
requirement, the ability to reuse existing code, the
amount of testing and documentation needed, etc.
Rules for setting priority
 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
 Penalty--Failing to conform to a standard could incur a high
penalty even if it is of low importance for the customer (i.e.
the customer does not get excited if the requirement is
 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
Rules for setting priorities
 Volatile requirements--Volatility of requirements is considered
a risk factor and is sometimes handled as part of the risk aspect.
 Volatility of requirements should be taken into account
separately in the prioritization process.
 The reasons for requirements volatility vary, for example: the
market changes, business requirements change, legislative
changes occur, users change, or requirements become clearer
during the software life cycle
 Irrespective of the reason, volatile requirements affect the
stability and planning of a project, and presumably increase the
costs since changes during development increase the cost of a
Combination of rules

 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
Combination of rules

 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.