6.1- Req Analysis Part1.pptx

Analysis of the Information Collected in

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

gathering.

1. Enumerate/list all the requirements

Analysis of the Information Collected in the

Elicitation

3. Evaluate each requirement for its feasibility

1. a. Technical

2. b. Financial

3. c. Timeline

4. Group core functionality requirements together

into logical groups

5. Identify requirements that are duplicated

6. Identify requirements that are contradictory to

each other

Analysis of the Information Collected in the

Elicitation and Gathering

8. Identify stakeholders for each requirement 1. Primary stakeholder

2. Secondary stakeholders

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

1. a. By timeline

2. b. By technical feasibility 3. c. By financial feasibility

10. Identify gaps, in the case of COTS product implementation 1. Between the product and the organizational needs

2. The needs that can be met by re-engineering the organizational processes

3. The needs that necessitate product customization

11. Determine the schedule of implementation for the requirements 12. 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

duplicates.



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}

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 defined



_{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 Feasibility

—Technical



_{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 Feasibility

—Financial



_{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 requirement.



_{We have to evaluate each requirement for its}

Evaluate each Requirement for Its Feasibility—Timeline



_{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}

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}

workstation.



_{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}

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



_{This step is in fact a cleansing step that provides us unique}

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

requirements



_{3. There is also a possibility of contradiction in the}

perceptions of the person performing a function

and

his

supervisor

.



_{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 senior.



_{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

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 Requirement



_{We need to identify the stakeholders for each of the}

requirements.



_{These are the persons who need to be approached during}

the project execution for any clarification about the

requirement.



_{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

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.

 _{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 implementation.



_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

fulfilled).



_{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 project

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 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}