Unit-II Requirement Analysis

(1)

1

B Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICE UNIT II

REQUIREMENTS ANALYSIS: Requirement Engineering Processes – Feasibility Study – Problem of Requirements – Software Requirement Analysis – Analysis Concepts and Principles – Analysis Process – Analysis Model.

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 from client’s point of view.

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 and maintain sophisticated and descriptive ‘System Requirements Specification’ document.

• Requirement engineering constructs a bridge for design and construction.

******************************************************************************

Understanding Requirement Engineering OR Requirement Engineering Process (Essay Question)

(2)

2

B Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICE 1. Inception

• Inception is a task where the requirement engineering asks a set of questions to establish a software process.

• In this task, it understands the problem and evaluates with the proper solution.

• It collaborates with the relationship between the customer and the developer.

• The developer and customer decide the overall scope and the nature of the question.

2. Elicitation

Elicitation means to find the requirements from anybody. The requirements are difficult because the following problems occur in elicitation.

Problem of scope: The customer gives the unnecessary technical detail rather than clarity of the overall system objective.

Problem of understanding: Poor understanding between the customer and the developer regarding various aspect of the project like capability, limitation of the computing environment.

Problem of volatility: In this problem, the requirements change from time to time and it is difficult while developing the project.

3. Elaboration

• In this task, the information taken from user during inception and elaboration and are expanded and refined in elaboration.

• Its main task is developing pure model of software using functions, feature and constraints of a software.

4. Negotiation

• In negotiation task, a software engineer decides the how will the project be achieved with limited business resources.

• To create rough guesses of development and access the impact of the requirement on the project cost and delivery time.

5. Specification

• In this task, the requirement engineer constructs a final work product.

• The work product is in the form of software requirement specification.

(3)

3

B Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICE

• The requirements are formalize in both graphical and textual formats.

6. Validation

• The work product is built as an output of the requirement engineering and that is accessed for the quality through a validation step.

• The formal technical reviews from the software engineer, customer and other stakeholders helps for the primary requirements validation mechanism.

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

• The examples of traceability table are the features, sources, dependencies, subsystems and interface of the requirement.

******************************************************************************

(4)

4

B Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICE Functional requirements

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 up” or “Open a new account”.

(5)

5

B Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICE 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 system’s quality attributes or characteristics, 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 more than 45 °C”.

Typical non-functional requirements include:

• Performance – for example: response time, throughput, utilization, static volumetric

• Scalability

• Capacity

• Availability

• Reliability

• Recoverability

• Maintainability

• Serviceability

• Security

• Regulatory

• Manageability

• Environmental

• Data Integrity

• Usability

• Interoperability

(6)

6

B Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICE Requirements Engineering Process (Short Answer Question):

The requirements engineering (RE) process is a series of activities that are performed in requirements phase in order to express requirements in software requirements specification (SRS) document.

This process focuses on understanding the requirement and its type so that an appropriate technique is determined to carry out the requirements engineering process.

The new software developed after collecting requirements either replaces the existing software or enhances its features and functionality.

For example, the payment mode of existing software can be changed from payment through hand-written cheques to electronic payment of bills.

In the above figure, a requirements engineering process is shown, which comprises of various steps. These steps include feasibility study, requirements elicitation, requirements analysis, requirements specification, requirements validation, and requirements management.

Requirements engineering process begins with feasibility study of the requirements. Then, requirements elicitation is performed, which focuses on gathering user requirements. After the requirements are gathered, analysis is performed, which further leads to requirements specification. The output of this is stored in the form of software requirements specification document. Next, the requirements are checked for their completeness and correctness in requirements validation. Lastly, to understand and control changes to system requirements, requirements management is performed.

(7)

7

B Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICE 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 listed below:

• Analyze whether the software will meet organizational requirements or not.

• Determine whether the software can be implemented using current technology and within the specified budget and schedule or not.

• Determine whether the software can be integrated with other existing software or not.

Types of Feasibility:

Various types of feasibility that are commonly considered include technical feasibility, operational feasibility, and economic feasibility.

(a) 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.

(8)

8

B Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICE (b) Operational Feasibility:

Operational feasibility assesses the extent to which the required software performs series of steps to solve business problems and user requirements.

In addition, 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 the alternative solutions proposed by software development team or not.

(c) Economic Feasibility:

Economic feasibility determines whether the required software is capable of generating financial gains for an organization or not. It involves the cost incurred on software development team, estimated cost of hardware and software, cost of performing feasibility study, and so on.

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

Cost of hardware, software, development team, and training.

******************************************************************************

Problems of requirements:

1. Customers don't (really) know what they want

2. Requirements change during the course of the project

3. Customers have unreasonable timelines.

4. Communication gaps exist between customers, engineers and project managers.

Problem 1: Customers don't (really) know what they want

The most common problem in the requirements analysis phase is that customers have

only a vague (unclear) idea of what they need.

Problem 2: Requirements change during the course of the project

The second most common problem with software projects is that the requirements

(9)

9

This may occur because as development progresses and prototypes are developed,

customers are able to more clearly see problems with the original plan and make necessary

course corrections.

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

A common mistake is to agree to such timelines before actually performing a detailed

analysis and understanding both of the scope of the project and the resources necessary to

execute it.

In accepting an unreasonable timeline without discussion, it leads to

1. Doing your customer a disservice ( damage)

2. The project will either get delayed (because it wasn't possible to execute it in time).

3. Suffer from quality defects (because it was rushed through without proper

inspection).

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 and do not understand technical terms in the same way. This can lead to confusion and severe miscommunication.

An important task of a project manager, especially during the requirements analysis

phase, is to ensure that both parties have a precise understanding of the deliverable and the

tasks needed to achieve it.

******************************************************************************

Requirement Analysis

(10)

10

Figure 1 Analysis as a bridge between system engineering and software design

Requirements engineering activities result in:

1. The specification of software’s operational characteristics (function, data, and behavior). 2. Indicate software's interface with other system elements

3. Establish constraints that software must meet.

Requirements analysis allows the software engineer (analyst) to refine the software allocation and build models of the data, functional, and behavioral domains that will be treated by software.

Requirements analysis provides the software designer with are presentation of information, function, and behavior that can be translated to data, architectural, interface, and component-level designs.

Finally, the requirements specification provides the developer and the customer with the means to assess quality once software is built.

Software requirements analysis may be divided into five areas of effort:

1. Problem recognition, 2. Evaluation and synthesis 3. Modeling,

4. Specification 5. Review.

******************************************************************************

Software Requirement Analysis Concepts

(11)

11

To perform the job properly you should follow a set of underlying concepts and principles.

Requirement Gathering Techniques (Elicitation) OR

Requirements Elicitation for Software

Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process.

1. Initiating a Process of Requirement Gathering: –

• The most commonly used requirement gathering technique is to conduct a meeting or interview.

• We can say to get the requirements of our customer communication must be initiated.

• The analyst start by asking context free questions i.e. a set of questions that will lead to a basic understanding of the problem.

• Analyst and customer arrange one meeting, in that meeting customer gives the software requirement, based on that requirement analyst asks some question to customer for better understanding the requirement and overall goals and the benefits e.g. the analyst can ask following questions.

1. Who is behind the request for this system?

2. Who will use the solution?

3. What will be the economic benefit of a successful solution?

4. Is there another source for the solution that customer require.

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?

• Can you describe the environment in which the solution will be used?

• Will special performance issues or constraints affect to way the solution approach?

The final set of questions focuses on the effectiveness of the meeting, it is called Meta questions.

• Can anyone else provide additional information?

(12)

12

• Are my questions relevant to the problem that customer have?

• Am I asking too many questions?

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 number of independent investigators have developed a team-oriented approach to requirements gathering that is applied during early stages of analysis and specification. Called facilitated application technique (FAST).

• 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) Facilitate controls the meeting.

5) Definition mechanism is used it when it can be a worksheet or an electronic bulletin board.

6) The goal is to identify the problem, proposed elements of the solution, negotiate different approaches and specify a preliminary set of solution requirements.

• Initial meetings between the developer and customer occur and basic questions and answers help to establish the scope of the problem and the overall perception of the solution

• Out of these initial meetings the developer and customer write one or two page product request. Meeting place, time and date for FAST are selected and a facilitator is chosen.

• Attendees from both the development and customer organization are invited to attempt.

• The product request is distributed to all attendees before the meeting date.

• While reviewing the request in the days before the meeting each FAST attendees is use to make the list of objects that are part of the environment surrounds the system, other objects that are to be produced by the systems and objects that are used by the system.

• Each person on the FAST team develops the list which is described about objects.

(13)

13

• In a similar fashion each FAST team member develop list of constraints about the objects of the system.

• After the mini specifications are computed each FAST attendees makes a list of validation criteria for the product or system.

• Finally one or more participants is assigned the task of writing the complete specification using all inputs from the FAST meeting and later on all requirement point of view from all members and refinement is prepared for development of a design.

3 Quality Function Deployments (QFD)

Quality function deployment (QFD) is a quality management technique that translates the needs of the customer into technical requirements for software. QFD concentrates on maximizing the customer satisfaction from the software engineering process.

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 customer is satisfied.

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:

These features go beyond the customer’s expectations and prove to be very satisfying when present. For example software for a new mobile phone comes with standard features, but is coupled with a set of unexpected capabilities (e.g., multi-touch screen, visual voice mail).

4. Use-Cases

As requirements are gathered as part of informal meetings, a software engineer can create a set of scenarios that identify a thread of usage for the system to be constructed.

(14)

14

B Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICE 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 about unexpected changes?

In general, use-case is simply a written narrative that describes the role of an actor as interaction with the system occurs.

****************************************************************************** ANALYSIS PRINCIPLES

Over the past two decades, a large number of analysis modeling methods have been developed. Investigators have identified analysis problems and their causes and have developed a variety of modeling notations to overcome them. Each analysis method has a unique point of view.

• All analysis methods are related by a set of operational principles

o The information domain of a problem must be represented and understood.

o The functions that the software is to perform must be defined.

o The behavior of the software must be represented.

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

o The analysis process should move from essential information toward implementation detail

• In addition to these operational analysis principles, a set of guiding principles for requirements engineering are suggested as

o Understand the problem before you begin to create the analysis model

o Develop prototypes that enable a user to understand how human/machine interaction will occurs

(15)

15

B Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICE o Use multiple view of requirements

o Rank requirements

o Work to eliminate ambiguity

******************************************************************************

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.

Typically requirements analysis involves capturing both functional and non-functional

requirements and requires both technical and business expertise. To ensure effective capturing

of requirement we follow a holistic process involving these broad steps

1. Requirements Scope

The scope and boundary of the proposed software solution is drawn based on business

requirements and goals.

2. Stakeholder Identification

Identifying stakeholders such as customers, end-users, system administrators etc. is the

next step in requirements analysis. This is one of the most important steps in the whole process

as proper identification of stakeholders enables the business analyst to draw a road map for

gathering requirements.

3. Requirements Elicitation / Requirements Gathering

Post identification of stakeholders used for the process of eliciting requirements. Based

on the scope and nature of a particular software solution there can be multiple stakeholders.

Interaction happens with stakeholder groups using various communication methodologies

including in-person interviews, focus groups, market study, surveys and secondary research.

4. Requirement Analysis

Once user data is gathered, structured analysis is carried out on this data to determine

models. Usually use-cases are developed to analyze the data on various parameters depending

on the larger goals of the software solution. We use requirements animation, automated

(16)

16

B Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICEB Naresh, Lecturer in Computer Science BVRICE 5. 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 development teams to start

building the solution on. It serves as a technical compendium of all the stakeholders' needs

including user requirements, system requirements, user interface and operational

requirements.

6. 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 changes to requirements of the proposed software solution.

******************************************************************************

Analysis Model

• Analysis model operates as a link between the 'system description' and the 'design

model'.

• In the analysis model, information, functions and the behavior of the system is defined

and these are translated into the architecture, interface and component level design in

the 'design modeling'.

Elements of the analysis model

1. Scenario based element

• This type of element represents the system user point of view.

• Scenario based elements are use case diagram, user stories.

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

3. Behavioral elements

• Behavioral elements represent state of the system and how it is changed by the external

(17)

17

• 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 diagram.

Analysis Rules of Thumb

The rules of thumb are must be followed while creating the analysis model.

The rules are as follows:

• The model focuses on the requirements in the business domain. The level of abstraction

must be high i.e. there is no need to give details.

• Every element in the model helps in understanding the software requirement and focus

on the information, function and behavior of the system.

• The consideration of infrastructure and nonfunctional model delayed in the design.

For example, the database is required for a system, but the classes, functions and behavior of the database are not initially required. If these are initially considered then

there is a delay in the designing.

• Throughout the system minimum coupling is required. The inter connections between

the modules is known as 'coupling'.

• 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