Requirement Analysis

UNIT-II

Software requirement

•

_The

_{software requirements are}

_{description of}

features and functionalities

of the

target

system

•

_Requirements

_{convey the expectations of users}

from the software product.

•

_{The requirements can be}

_{obvious or hidden}

_,

known or unknown

,

expected or unexpected

Requirement Engineering

• _{The process to gather the software requirements}

from client, analyze and document them is known

as requirement engineering.

• _{The goal of requirement engineering is to develop}

Understanding

Requirement

Engineering

Or

Requirement engineering consists of

seven

1. Inception (Beginning)

2. Elicitation

3. Elaboration (Explanation or Expansion)

4. Negotiation

5. Specification

6. Validation

1. Inception

• _{At project inception, we establish a basic}

understanding of the problem, the people who want a solution, the nature of the solution that is desired and the effectiveness of preliminary communication

2. Elicitation

• _{In requirements engineering,}

requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders.

• _{It asks the customer, the user, and others what the objectives}

•

_{Problem of scope}

The customer gives the

•

_Problem

_of

_{understanding:}

_Poor

understanding between the customer and the

developer regarding various aspect of the

project like capability, limitation of the

•

_{Problem of volatility:}

_{In this problem, the}

requirements change from time to time and it

3. Elaboration (Explanation or Expansion

)

• _{In this task, the information taken from the customer}

during inception and elicitation are expanded and refined during elaboration.

• _{Its main task is developing a refined requirements}

model that identifies various aspects of software functions, feature and constraints.

• _{Elaboration is driven by the creation and refinement}

4. Negotiation(Cooperation)

• _{It is common for different customers or users to propose}

conflicting requirements, arguing that their version is “essential for our special needs”.

• _{We have to resolve these conflicts through a process of} negotiation.

• _{Customers, users and other stakeholders are asked to rank} requirements and then discuss conflicts in priority.

5. Specification

• _{In the context of computer based systems, the term}

specification means different things to different

people.

• _{A specification can be a written document, a set of}

6. Validation

• _{The work product is built as an output of the}

requirement engineering and that is assessed for the quality through a validation step.

• _{Requirement validation examines the specification}

7. Requirement management

• _{It is a set of activities that help the project team to}

identify, control and track the requirements and changes can be made to the requirements at any time of the ongoing project.

• _{These tasks start with the identification and assign a}

unique identifier to each of the requirement.

• _{After finalizing the requirement traceability table is}

FEASIBILITY STUDY

•

_The

_{objective of feasibility study}

_is

_{to establish}

the reasons for developing software that is

acceptable to users, adaptable to change, and

conformable to established standards

.

•

_{Various other objectives of feasibility study are}

1. Analyze whether the

software will meet

organizational requirements or not.

2. Determine whether the software can be

implemented

using current technology and

within the specified budget and schedule or

not.

3. Determine whether the software can be

Types of Feasibility

•

_Various

_{types of feasibility}

_{that are}

commonly considered include

–

_{Technical Feasibility,}

Technical Feasibility

•

_{Technical feasibility performs the tasks listed}

below:

– _{Analyzes the technical skills and capabilities of}

software development team members.

– _{Determines whether the relevant technology is}

stable and established or not.

– _{Determine that the technology chosen for} software development has large number of users

Operational Feasibility

• _{operational feasibility performs the tasks listed}

below:

– _{Determines whether the problems proposed in user}

requirements are of high priority or not.

– _{Determines whether the solution suggested by}

software development team is acceptable or not.

– _{Analyzes whether users will adapt to new software or}

not.

– _{Determines whether the organization is satisfied by}

Economic Feasibility

• _{Economic feasibility determines whether the} required software is capable of generating financial gains for an organization or not.

• _{Software is said to be economically feasible if it} focuses on the issues listed below:

– _{Cost incurred on software development produces}

long-term gains for an organization.

– _{Cost required conducting full software}

investigation (such as requirements elicitation and requirements analysis).

Functional

and

• _{The definition of a functional requirement is:}

_{Any requirement which specifies what the system}

should do.

• _{In other words, a functional requirement will describe}

a particular behavior of function of the system when certain conditions are met.

For example: “Send email when a new customer signs

•

_{A functional requirement for an everyday}

object like a cup would be:

“ability to contain tea or coffee without

The definition of a non-functional requirement is :

“Any requirement which specifies how the system performs a certain function”

In other words, a non-functional requirement

will describe how a system should behave and what limits there are on its functionality.

• _{Non-functional requirements generally specify the}

•

_{for example: “Modified data in a database}

should be updated for all users accessing it

within 2 seconds.”

•

_{A non-functional requirement for the cup}

mentioned previously would be:

“contain hot liquid without heating up to

Typical non-functional requirements include:

• Performance – for example: response time, throughput, utilization • Scalability - the capacity to be changed in size or scale.

• Capacity • Availability • Reliability • Recoverability • Maintainability • Serviceability • Security • Regulatory • Manageability • Environmental • Data Integrity • Usability

Problems of requirements

•

_{Customers don't know what they want}

•

_{Requirements change during the course}

of the project

•

_{Customers have unreasonable timelines.}

•

_{Communication gaps exist between}

Problem 1:

Customers don't know what they

want

•

_The

_most

_common

_problem

_in

_the

Problem 2:

Requirements change during the

course of the project

•

_{The second most common problem with}

software

projects

is

that

the

requirements defined in the first phase

Problem 3: Customers have unreasonable timelines

• _{It's quite common to hear a customer say something} like

"it's an emergency job and we need this project completed in X weeks".

•

_{In accepting an}

_{unreasonable timeline}

without discussion,

it leads

to

– _{Doing your customer a disservice ( damage)}

– _{The project will either get delayed (because it} wasn't possible to execute it in time).

Problem 4:

Communication gaps exist between

customers, engineers and project managers

• _{Often, customers and engineers fail to communicate} clearly with each other.

– _{because they come from different worlds}

– _{do not understand technical terms in the same}

way.

• _{An important task of a project manager, especially} during the requirements analysis phase is,

– _{to ensure that both parties have a precise}

Requirement Analysis

• _{Requirements analysis is a software engineering task}

that bridges the gap between system level software allocation and software design.

• _{Requirement analysis allows the software engineer (i.e.}

analyst)

– _{to refine the software allocation}

• _{Finally, the requirement specification provides the}

developer and the customer with the means to

Requirement analysis

divided into

five

areas:

1) Problem recognition

2) Evaluation and synthesis 3) Modeling

1. Problem Recognition

•

_{Initially the}

_{system analyst}

_{studies the system}

specification of the software and project plan.

•

_{The analyst must establish contact with}

management

,

technical staff,

customer

and

•

_The

_{project manager}

_{can serve as a}

coordinator

for

establishment

of

communications paths.

•

_The

_{goal of the analysis}

_{is to reorganize the}

basic problem elements which perceived by

2. Synthesis and evaluation

•

_{Problem evaluation and solution synthesis is the}

next major area of effort for analysis.

•

_{The analyst}

– _{Must evaluate the flow and content of}

information,

– _{Define and expand all software function,}

– _{Understand software behavior in the context of}

•

_{Throughout evaluation and solution synthesis the}

analyst’s primary focus is on

“What must be

done”

but not on “How it will be done”.

•

_{For example,}

–

_{What data does the}

_{system produce and}

consume

–

_{What functions must the}

_{system perform}

–

_What

_{interfaces are define}

_and

3. Modeling

• _{During the evaluation and solution synthesis}

activities the analyst creates models of the system in an effort to better understand data and control flow, functions processing and behavior operation.

• _{The model serves the foundation for software}

4. Requirement Specification

1.

2. If the major modules are not working properly

then the software might not satisfy the user.

Software Requirement

Requirement Gathering Techniques

Or

Requirements Elicitation for Software

•

_Before

_{requirements can be analyzed,}

modeled, or specified they must be

1.Initiating a Process of Requirement Gathering

•

_{The most commonly used}

_{requirement gathering}

technique

is to

conduct a meeting or interview

.

•

_The

_{analyst start by asking context free questions}

i.e. a set of questions that will lead to a basic

•

_{Analyst and customer arrange one meeting}

_,

in that meeting

customer gives the software

requirement

, based on that requirement

analyst asks some questions

to customer for

better understanding the requirement and

•

_The

_{analyst can ask}

_{following questions.}

–

_{Who is behind the request for this system?}

–

_{Who will use the solution?}

–

_{What will be the economic benefit of a}

successful solution?

–

_{Is there another source for the solution that}

• _{The next set of questions enables the analyst to gain}

better understanding of the problem and the customer to voice about the solution.

• _{The second set of questions can be how can you}

characterize good output that would be generated by a successful solution of software.

• _{What problems will this solution address?}

•

_{The final set of questions focuses on the}

effectiveness of the meeting, it is

called

Meta questions

.

–

_{Can anyone else provide additional}

information?

–

_{Should I ask anything else about the}

problem?

–

_{Are my questions relevant to the problem}

that customer have?

2. Facilitated Application Specification

Techniques

(FAST)

•

_{Customers and software engineers have an}

unconscious

“us and them”

mind-set.

•

_{With these problems in the mind that a}

The basic guidelines for FAST approach are,

1) Meeting is conducted and attempted by both

software engineers and customers.

2) Rules for preparation and participation are established.

3) An agenda is suggested that is formal enough to cover all important points.

4) The goal is

– _{to identify the problem,}

– _{proposed elements of the solution,}

3. Quality Function Deployment (QFD)

•

_{Quality function deployment (}

_{QFD) is a}

quality management technique that

translates

the needs of the customer

QFD identifies

three types

of

requirements:

Normal requirements:

•

_{These represent the}

_{objectives and goals}

_that

are stated for a product or system during

meeting with customer.

•

_{If these requirements are present, the}

Expected requirements

•

_{These requirements are implicit to the product or}

system and may be so fundamental that the

customer does not explicitly state them.

•

_{Their absence will be a cause for significant}

dissatisfaction.

Exciting requirements

4. Use-Cases

• _{As requirements are gathered as part of informal} meetings, a software engineer can create a set of scenarios.

• _{An actor represents a class of external entities that} play just one role. Once actors have been identified, use-case can be developed. The use-case describes the manner in which an actor interacts with the

• _{The use-case should be answer below}

questions:

– _{What main tasks or functions are}

performed by an actor?

– _{What system information will the actor}

acquire, produce, or change?

– _{Will the actor have to inform the system}

about changes in the external

environment?

– _{What information does the actor desire}

from the system?

– _{Does the actor wish to be informed}

ANALYSIS PRINCIPLES

• _{Investigators have identified analysis problems.}

• _{Each analysis method has a unique point of view.}

All analysis methods are related by a set of

operational principles

– The information domain of a problem must be represented and understood

– The functions that the software is to perform must be defined

– The behavior of the software must be represented

– The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered fashion

A set of

guiding principles

•

_{Understand the problem before you begin to}

create the analysis model

•

_{Develop prototypes that enable a user to}

understand how human/machine interaction

will occurs

•

_{Record the origin of an the reason for every}

requirement

•

_{Use multiple view of requirements}

•

_{Rank requirements}

Analysis process:

• Based on the scope and nature of a particular software project,

requirement analysis is carried out by an independent business analyst or a team of analysts to capture requirements.

• _{Requirements Scope}

• Stakeholder Identification

• _{Requirements Elicitation / Requirements Gathering} • Requirement Analysis

• Software Requirement Specification (SRS)

Requirements Scope

• _{The scope and boundary of the proposed software solution is}

Stakeholder Identification

•

_{Identifying stakeholders such as customers,}

Requirements Elicitation / Requirements Gathering

• _{Post identification of stakeholders, the tedious (boring)}

process of eliciting requirements follows.

• _{Based on the scope and nature of a particular software}

solution there can be multiple stakeholders.

• _{Interaction happens with stakeholder groups using various}

Requirement Analysis

• _{Once user data is gathered, structured analysis is carried out}

Software Requirement Specification (SRS)

• _{Once the captured data is analyzed these are put together in}

the form of a software requirement specification document (SRS) or a system requirement specification (SYRS) document.

• _{This document serves as a blueprint for the design or}

Software Requirements Management

• _{The final step of the requirements analysis process involves}

validating all elements of the requirements specifications document.

• _{Errors are corrected here and it can also accommodate minor}

Analysis Model

• _{Analysis model operates as a link between the 'system}

description' and the 'design model'.

• _{In the analysis model, information, functions and the}

behaviour of the system is defined and these are translated into the architecture, interface and component level design in the 'design modeling'.

1. Scenario based element

• _{This type of element represents the system user point of}

view.

2. Class based elements

• _{The object of this type of element manipulated by the system.} • _{It defines the object, attributes and relationship.}

• _{The collaboration is occurring between the classes.}

• _{Class based elements are the class diagram, collaboration}

3. Behavioral elements

• _{Behavioral elements represent state of the system and how it}

is changed by the external events.

• _{The behavioral elements are sequenced diagram, state}

diagram.

4. Flow oriented elements

• _{An information flows through a computer-based system it}

gets transformed.

• _{It shows how the data objects are transformed while they}

flow between the various system functions.

• _{The flow elements are data flow diagram, control flow}

Analysis Rules of Thumb

• _{The rules of thumb are must be followed while creating the}

The rules are as follows:

• _{The model focuses on the requirements in the business}

domain. The level of abstraction (idea) must be high i.e. there is no need to give details.

• _{Every element in the model helps in understanding the}

• _{The consideration of infrastructure and nonfunctional}

• _{For example, the database is required for a system, but the}

classes, functions and behavior of the database are not

• _{Throughout the system minimum coupling is required. The}

• _{The analysis model gives value to all the people related to}

model.

• _{The model should be simple as possible.}

• _{Because simple model always helps in easy understanding of}