Q.

1 Discuss the significance and use of requirement

engineering. What are the problems in the formulation
of requirements?
The significance and use of requirement engineering in software development
process.

 Basically, Requirement describe the “What of a system, not the “How”.

 Requirement Engineering produces one large document, written in a
natural language, contains a description of what the system will do without
describing how it will do.

1. Crucial Process Step

1. The quality of a software product is only as-good as the process
that creates it.
2. Without well written requirement specifications, developers do
not know what to build, customers do not know what to expect, and
there is no way to validate that the built system is satisfied the
requirements.
3. The following activities used in canonical process step.
A. Identification and Documentation of Customer’s and User’s
need.
B. Creation of a document that describes the external behavior
and the associated constraints that will satisfy those needs.
C. Analysis and Validation of the requirements, document
ensures that consistency, completeness and feasibility.
D. The primary output of requirement specification must treat
a system as a Black Box.
2. State of the Practice
Most software development organization agree to the fact that there should be
a set of activities called Requirement Engineering and their success is depends
on the success of entire project.

 There are several reasons of state of the practice is not better than
Crucial Process Steps.
 Requirements are difficult to uncover
It is difficult to identify all the requirements regardless of the techniques we
use.
 Requirement Change
Because no user can come up with a complete list of requirements at the
outset, the requirements get added and changed as the user begins to
understand the sytem.
 Tight Project Schedule
Because of either lack of planning or unreasonable customer demand, many
projects start with insufficient time. Sometimes, this allocated time is
reduced while the project is underway.
 Communication Barriers
Requirements engineering is communication intensive, users and developers
have different vocabularies. Developers usually want more precise
specification while user prefer natural languages.
 Lack of Resources
There may not be enough resources to build software that can do everything
the customer wants. It is essential to rank requirements so that the most
important can be implemented first.

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

want
Possibly the most common problem in the requirements analysis phase is
that customers have only a vague idea of what they need, and it's up to you
to ask the right questions and perform the analysis necessary to turn this
amorphous vision into a formally-documented software requirements
specification that can, in turn, be used as the basis for both a project plan
and an engineering architecture.

To solve this problem, you should:

 Ensure that you spend sufficient time at the start of the project on
understanding the objectives, deliverables and scope of the project.
 Make visible any assumptions that the customer is using, and
critically evaluate both the likely end-user benefits and risks of the
project.
 Attempt to write a concrete vision statement for the project, which
encompasses both the specific functions or user benefits it provides and
the overall business problem it is expected to solve.
 Get your customer to read, think about and sign off on the completed
software requirements specification, to align expectations and ensure
that both parties have a clear understanding of the deliverable.
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 change as the project progresses.
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; it may also occur
because changes in the external environment require reshaping of the
original business problem and hence necessitates a different solution than
the one originally proposed. Good project managers are aware of these
possibilities and typically already have backup plans in place to deal with
these changes.

To solve this problem, you should:

 Have a clearly defined process for receiving, analyzing and

incorporating change requests, and make your customer aware of
his/her entry point into this process.
 Set milestones for each development phase beyond which certain
changes are not permissible -- for example, disallowing major changes
once a module reaches 75 percent completion.
 Ensure that change requests (and approvals) are clearly
communicated to all stakeholders, together with their rationale, and that
the master project plan is updated accordingly.

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, you are, in fact, doing your customer a disservice: it's quite
likely that the project will either get delayed (because it wasn't possible to
execute it in time) or suffer from quality defects (because it was rushed
through without proper inspection).

To solve this problem, you should:

 Convert the software requirements specification into a project plan,

detailing tasks and resources needed at each stage and modeling best-
case, middle-case and worst-case scenarios.
 Ensure that the project plan takes account of available resource
constraints and keeps sufficient time for testing and quality inspection.
 Enter into a conversation about deadlines with your customer, using
the figures in your draft plan as supporting evidence for your
statements. Assuming that your plan is reasonable, it's quite likely that
the ensuing negotiation will be both productive and result in a favorable
outcome for both parties.

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, and 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.

To solve this problem, you should:

 Take notes at every meeting and disseminate these throughout the

project team.
 Be consistent in your use of words. Make yourself a glossary of the
terms that you're going to use right at the start, ensure all stakeholders
have a copy, and stick to them consistently.

Problem 5: The development team doesn't

understand the politics of the customer's organization
The scholars Bolman and Deal suggest that an effective manager is one
who views the organization as a "contested arena" and understands the
importance of power, conflict, negotiation and coalitions. Such a manager is
not only skilled at operational and functional tasks, but he or she also
understands the importance of framing agendas for common purposes,
building coalitions that are united in their perspective, and persuading
resistant managers of the validity of a particular position.
These skills are critical when dealing with large projects in large
organizations, as information is often fragmented and requirements
analysis is hence stymied by problems of trust, internal conflicts of interest
and information inefficiencies.

To solve this problem, you should:

 Review your existing network and identify both the information you
need and who is likely to have it.
 Cultivate allies, build relationships and think systematically about
your social capital in the organization.
 Persuade opponents within your customer's organization by framing
issues in a way that is relevant to their own experience.
 Use initial points of access/leverage to move your agenda forward.
Q.2 Draw and Explain the steps of Requirement
Engineering.
Requirement Engineering
Requirements engineering (RE) refers to the process of defining, documenting, and
maintaining requirements in the engineering design process. Requirement engineering
provides the appropriate mechanism to understand what the customer desires, analysing
the need, and assessing feasibility, negotiating a reasonable solution, specifying the
solution clearly, validating the specifications and managing the requirements as they are
transformed into a working system. Thus, requirement engineering is the disciplined
application of proven principles, methods, tools, and notation to describe a proposed
system's intended behaviour and its associated constraints.

Requirement Engineering Process

It is a four-step process, which includes -

1. Feasibility Study

2. Requirement Elicitation and Analysis

3. Software Requirement Specification

4. Software Requirement Validation

5. Software Requirement Management

1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for developing the
software that is acceptable to users, flexible to change and conformable to established
standards.

Types of Feasibility:

1. Technical Feasibility - Technical feasibility evaluates the current technologies,

which are needed to accomplish customer requirements within the time and
budget.

2. Operational Feasibility - Operational feasibility assesses the range in which the

required software performs a series of levels to solve business problems and
customer requirements.

3. Economic Feasibility - Economic feasibility decides whether the necessary

software can generate financial profits for an organization.

2. Requirement Elicitation and Analysis:

This is also known as the gathering of requirements. Here, requirements are
identified with the help of customers and existing systems processes, if available.
Analysis of requirements starts with requirement elicitation. The requirements are
analyzed to identify inconsistencies, defects, omission, etc. We describe requirements in
terms of relationships and also resolve conflicts if any.

Problems of Elicitation and Analysis

o Getting all, and only, the right people involved.

o Stakeholders often don't know what they want

o Stakeholders express requirements in their terms.

o Stakeholders may have conflicting requirements.

o Requirement change during the analysis process.

o Organizational and political factors may influence system requirements.

3. Software Requirement Specification:

Software requirement specification is a kind of document which is created by a software
analyst after the requirements collected from the various sources - the requirement
received by the customer written in ordinary language. It is the job of the analyst to
write the requirement in technical language so that they can be understood and
beneficial by the development team.
The models used at this stage include ER diagrams, data flow diagrams (DFDs), function
decomposition diagrams (FDDs), data dictionaries, etc.

o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling
the requirements. DFD shows the flow of data through a system. The system may
be a company, an organization, a set of procedures, a computer hardware
system, a software system, or any combination of the preceding. The DFD is also
known as a data flow graph or bubble chart.

o Data Dictionaries: Data Dictionaries are simply repositories to store information

about all data items defined in DFDs. At the requirements stage, the data
dictionary should at least define customer data items, to ensure that the
customer and developers use the same definition and terminologies.

o Entity-Relationship Diagrams: Another tool for requirement specification is the

entity-relationship diagram, often called an "E-R diagram." It is a detailed logical
representation of the data for the organization and uses three main constructs
i.e. data entities, relationships, and their associated attributes.

4. Software Requirement Validation:

After requirement specifications developed, the requirements discussed in this document
are validated. The user might demand illegal, impossible solution or experts may
misinterpret the needs. Requirements can be the check against the following conditions -

o If they can practically implement

o If they are correct and as per the functionality and specially of software

o If there are any ambiguities

o If they are full

o If they can describe

Requirements Validation Techniques

o Requirements reviews/inspections: systematic manual analysis of the

requirements.

o Prototyping: Using an executable model of the system to check requirements.

o Test-case generation: Developing tests for requirements to check testability.

o Automated consistency analysis: checking for the consistency of structured

requirements descriptions.
5. Software Requirement Management:
Requirement management is the process of managing changing requirements during the
requirements engineering process and system development.

New requirements emerge during the process as business needs a change, and a better
understanding of the system is developed.

The priority of requirements from different viewpoints changes during development

process.

The business and technical environment of the system changes during the development.

Q.3 Explain all the different types of requirements in

requirement engineering.
Types of Requirements
Requirements help to understand the behavior of a system, which is described by
various tasks of the system. For example, some of the tasks of a system are to provide
a response to input values, determine the state of data objects, and so on. Note that
requirements are considered prior to the development of the software. The
requirements, which are commonly considered, are classified into three categories,
namely, functional requirements, non-functional requirements, and domain
requirements.
 IEEE defines functional requirements as 'a function that a system or component
must be able to perform.' These requirements describe the interaction of software
with its environment and specify the inputs, outputs, external interfaces, and
the functions that should be included in the software. Also, the services provided
byfunctional requirements specify the procedure by which the software should
reactto particular inputs or behave in particular situations.
To understand functional requirements properly, let us consider the following
example of an online banking system.
1. The user of the bank should be able to search the desired services from the
available ones.
2. There should be appropriate documents' for users to read. This implies that
when a user wants to open an account in the bank, the forms must be available so
that the user can open an account.
3. After registration, the user should be provided with a unique
acknowledgement number so that he can later be given an account number.
The above mentioned functional requirements describe the specific services provided
by the online banking system. These requirements indicate user requirements and
specify that functional requirements may be described at different levels of detail in
an online banking system. With the help of these functional requirements, users can
easily view, search and download registration forms and other information about the
bank. On the other hand, if requirements are not stated properly, they are
misinterpreted by software engineers and user requirements are not met.
The functional requirements should be complete and consistent. Completeness
implies that all the user requirements are defined. Consistency implies that all
requirements are specified clearly without any contradictory definition. Generally, it
is observed that completeness and consistency cannot be achieved in large software
or in a complex system due to the problems that arise while defining the functional
 requirements of these systems. The different needs of stakeholders also prevent the
achievement of completeness and consistency. Due to these reasons, requirements
may not be obvious when they are,'first specified and may further lead to
inconsistencies in the requirements specification.
The non-functional requirements (also known as quality requirements) are
related to system attributes such as reliability and response time. Non-functional
requirements arise due to user requirements, budget constraints, organizational
policies, and so on. These requirements are not related directly to any particular
function provided by the system.
Non-functional requirements should be accomplished in software to make it perform
efficiently. For example, if an aeroplane is unable to fulfill reliability requirements, it
is not approved for safe operation. Similarly, if a real time control system is
ineffective in accomplishing non-functional requirements, the control functions
cannot operate correctly.
The description of different types of non-functional requirements is listed below.
1. Product requirements: These requirements specify how software product
performs. Product requirements comprise the following.
2. Efficiency requirements: Describe the extent to which the software makes
optimal use of resources, the speed with which the system executes, and the memory
it consumes for its operation. For example, the system should be able to operate at
least three times faster than the existing system.
3. Reliability requirements: Describe the acceptable failure rate of the
software. For example, the software should be able to operate even if a hazard occurs.
4. Portability requirements: Describe the ease with which the software can
be transferred from one platform to another. For example, it should be easy to port
the software to a different operating system without the need to redesign the entire
software.
5. Usability requirements: Describe the ease with which users are able to
operate the software. For example, the software should be able to provide access to
functionality with fewer keystrokes and mouse clicks.
6. Organizational requirements: These requirements are derived from the
policies and procedures of an organization. Organizational requirements comprise
the following.
7. Delivery requirements: Specify when the software and its documentation
are to be delivered to the user.
8. Implementation requirements: Describe requirements such as
programming language and design method.
9. Standards requirements: Describe the process standards to be used
during software development. For example, the software should be developed using
standards specified by the ISO and IEEE standards.
10. External requirements: These requirements include all the requirements
that affect the software or its development process externally. External requirements
comprise the following.
11. Interoperability requirements: Define the way in which
different computer based systems will interact with each other in one or more
organizations.
12. Ethical requirements: Specify the rules and regulations of the software so
that they are acceptable to users.
13. Legislative requirements: Ensure that the software operates within the
legal jurisdiction. For example, pirated software should not be sold.

Q.4 Write short note on all the 5 types of requirements

elicitation.
Requirements elicitation is perhaps the most difficult, most error-prone and most
communication intensive software development. It can be successful only through an
effective customer-developer partnership. It is needed to know what the users really
need.
There are a number of requirements elicitation methods. Few of them are listed
below –
1. Interviews
2. Brainstorming Sessions
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment (QFD)
5. Use Case Approach
The success of an elicitation technique used depends on the maturity of the analyst,
developers, users and the customer involved.

1. Interviews:
Objective of conducting an interview is to understand the customer’s expectations
from the software.
It is impossible to interview every stakeholder hence representatives from groups are
selected based on their expertise and credibility.
Interviews maybe be open ended or structured.
1. In open ended interviews there is no pre-set agenda. Context free questions
may be asked to understand the problem.
2. In structured interview, agenda of fairly open questions is prepared.
Sometimes a proper questionnaire is designed for the interview.
2. Brainstorming Sessions:
 It is a group technique
 It is intended to generate lots of new ideas hence providing a platform to
share views
 A highly trained facilitator is required to handle group bias and group conflicts.
 Every idea is documented so that everyone can see it.
 Finally a document is prepared which consists of the list of requirements and
their priority if possible.
3. Facilitated Application Specification Technique:
It’s objective is to bridge the expectation gap – difference between what the
developers think they are supposed to build and what customers think they are going
to get.
A team oriented approach is developed for requirements gathering.
Each attendee is asked to make a list of objects that are-
1. Part of the environment that surrounds the system
2. Produced by the system
3. Used by the system
Each participant prepares his/her list, different lists are then combined, redundant
entries are eliminated, team is divided into smaller sub-teams to develop mini-
specifications and finally a draft of specifications is written down using all the inputs
from the meeting.
4. Quality Function Deployment:
In this technique customer satisfaction is of prime concern, hence it emphasizes on
the requirements which are valuable to the customer.
3 types of requirements are identified –
 Normal requirements – In this the objective and goals of the proposed
software are discussed with the customer. Example – normal requirements for a
result management system may be entry of marks, calculation of results etc
 Expected requirements – These requirements are so obvious that the
customer need not explicitly state them. Example – protection from
unauthorised access.
  Exciting requirements – It includes features that are beyond customer’s
expectations and prove to be very satisfying when present. Example – when an
unauthorised access is detected, it should backup and shutdown all processes.
The major steps involved in this procedure are –
1. Identify all the stakeholders, eg. Users, developers, customers etc
2. List out all requirements from customer.
3. A value indicating degree of importance is assigned to each requirement.
4. In the end the final list of requirements is categorised as –
 It is possible to achieve
 It should be deferred and the reason for it
 It is impossible to achieve and should be dropped off
5. Use Case Approach:
This technique combines text and pictures to provide a better understanding of the
requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence they only give a
functional view of the system.
The components of the use case deign includes three major things – Actor, Use
cases, use case diagram.
1. Actor – It is the external agent that lies outside the system but interacts with it
in some way. An actor maybe a person, machine etc. It is represented as a stick
figure. Actors can be primary actors or secondary actors.
 Primary actors – It requires assistance from the system to achieve a
goal.
 Secondary actor – It is an actor from which the system needs
assistance.
2. Use cases – They describe the sequence of interactions between actors and
the system. They capture who(actors) do what(interaction) with the system. A
complete set of use cases specifies all possible ways to use the system.
3. Use case diagram – A use case diiagram graphically represents what
happens when an actor interacts with a system. It captures the functional
aspect of the system.
 A stick figure is used to represent an actor.
 An oval is used to represent a use case.
 A line is used to represent a relationship between an actor and a use
case.

Q.5 Discuss DFD and ER diagram along with one

example
What is a data flow diagram (DFD)?

A picture is worth a thousand words. A Data Flow Diagram (DFD) is a

traditional way to visualize the information flows within a system. A neat and
clear DFD can depict a good amount of the system requirements graphically. It
can be manual, automated, or a combination of both.

It shows how information enters and leaves the system, what changes the
information and where information is stored. The purpose of a DFD is to show
the scope and boundaries of a system as a whole. It may be used as a
communications tool between a systems analyst and any person who plays a
part in the system that acts as the starting point for redesigning a system.

It is usually beginning with a context diagram as level 0 of the DFD diagram, a

simple representation of the whole system. To elaborate further from that, we
drill down to a level 1 diagram with lower-level functions decomposed from
the major functions of the system. This could continue to evolve to become a
level 2 diagram when further analysis is required. Progression to levels 3, 4
and so on is possible but anything beyond level 3 is not very common. Please
bear in mind that the level of detail for decomposing a particular function
depending on the complexity that function.

DFD Diagram Notations

Now we'd like to briefly introduce to you a few diagram notations which you'll
see in the tutorial below.

External Entity

An external entity can represent a human, system or subsystem. It is where

certain data comes from or goes to. It is external to the system we study, in
terms of the business process. For this reason, people used to draw external
entities on the edge of a diagram.
Process

A process is a business activity or function where the manipulation and

transformation of data take place. A process can be decomposed to a finer
level of details, for representing how data is being processed within the
process.

Data Store

A data store represents the storage of persistent data required and/or

produced by the process. Here are some examples of data stores:
membership forms, database tables, etc.

Data Flow

A data flow represents the flow of information, with its direction represented
by an arrowhead that shows at the end(s) of flow connector.

DFD represents the Data Flow Diagram, which shows the flow of a series of data
based on a certain information system model. DFD is generally used for outlining the
pattern and framework of a data system without showing processing time options in
sequence, for example, the Yes or No choices in typical flowcharts. In reality, DFD can
be used for information management or data visualization. Here you can see an
example of the DFD, which shows the overall data flow for making a reservation in a
restaurant.
Q.6 Describe software prototyping and also describe its
types
Prototyping is defined as the process of developing a working replication of a product
or system that has to be engineered. It offers a small scale facsimile of the end
product and is used for obtaining customer feedback as described below:

The Prototyping Model is one of the most popularly used Software Development Life
Cycle Models (SDLC models).This model is used when the customers do not know
the exact project requirements beforehand. In this model, a prototype of the end
product is first developed, tested and refined as per customer feedback repeatedly
till a final acceptable prototype is achieved which forms the basis for developing the
final product.
In this process model, the system is partially implemented before or during the
analysis phase thereby giving the customers an opportunity to see the product early
in the life cycle. The process starts by interviewing the customers and developing the
incomplete high-level paper model. This document is used to build the initial
prototype supporting only the basic functionality as desired by the customer. Once
the customer figures out the problems, the prototype is further refined to eliminate
them. The process continues till the user approves the prototype and finds the
working model to be satisfactory.

Software Prototyping - Types

There are different types of software prototypes used in the industry. Following are
the major software prototyping types used widely −

Throwaway/Rapid Prototyping
Throwaway prototyping is also called as rapid or close ended prototyping. This type
of prototyping uses very little efforts with minimum requirement analysis to build a
prototype. Once the actual requirements are understood, the prototype is discarded
and the actual system is developed with a much clear understanding of user
requirements.

Evolutionary Prototyping

Evolutionary prototyping also called as breadboard prototyping is based on building

actual functional prototypes with minimal functionality in the beginning. The
prototype developed forms the heart of the future prototypes on top of which the
entire system is built. By using evolutionary prototyping, the well-understood
requirements are included in the prototype and the requirements are added as and
when they are understood.

Incremental Prototyping

Incremental prototyping refers to building multiple functional prototypes of the

various sub-systems and then integrating all the available prototypes to form a
complete system.

Extreme Prototyping

Extreme prototyping is used in the web development domain. It consists of three

sequential phases. First, a basic prototype with all the existing pages is presented in
the HTML format. Then the data processing is simulated using a prototype services
layer. Finally, the services are implemented and integrated to the final prototype.
This process is called Extreme Prototyping used to draw attention to the second
phase of the process, where a fully functional UI is developed with very little regard
to the actual services.
Q.7 Describe SRS along with its characteristics.

Software requirement specification (SRS) is a document that completely describes

what the proposed software should do without describing how software will do it. The
basic goal of the requirement phase is to produce the SRS, Which describes the
complete behavior of the proposed software. SRS is also helping the clients to
understand their own needs.

Advantages
Software SRS establishes the basic for agreement between the client and the
supplier on what the software product will do.
• A SRS provides a reference for validation of the final product.
• A high-quality SRS is a prerequisite to high-quality software.
• A high-quality SRS reduces the development cost.

Characteristics of an SRS
• Correct
• Complete
• Unambiguous
• Verifiable
• Consistent
• Ranked for importance and/or stability
• Modifiable
• Traceable

An SRS is correct if every requirement included in the SRS represents something

required in the final system. An SRS is complete, if everything the software is
supposed to do and the responses of the software to all classes of input data are
specified in the SRS. Correctness ensures that what is specified is done correctly,
completeness ensures that everything is indeed specified.
An SRS is unambiguous if and only if every requirement stated has one and only
one interpretation. Requirements are often written in natural language, which are
inherently ambiguous.
An SRS is verifiable if and only if every stated requirement is verifiable. A
requirement is verifiable if there exists some cost-effective process that can check
whether the final software meets that requirement. An SRS is consistent if there is no
requirement that conflicts with another.
Terminology can cause inconsistencies; for example, different requirements may use
different terms to refer to the same object. All the requirements for software are not
of equal importance. Some are critical, others are important but not critical, and there
are some, which are desirable, but not very important. An SRS is ranked for
importance and the stability of the requirement are indicated. Stability of requirement
reflects the chances of it changing in future. An SRS is traceable if the origin of each
of its requirements is clear and if it facilitates the referencing of each requirement in
future development. Forward traceability means that each requirement should be
traceable to some design and code elements. Backward traceability requires that it
be possible to trace design and code elements to the requirements they support.
Traceability aids verification and validation.
Q.8 Organise SRS for airline reservation system.