UNIT-2

UNIT II Hours:8
Software Requirement Engineering: Requirements Elicitation Techniques,
Requirements analysis, Models for Requirements analysis, Software requirements
Specification, Requirements Validation.
Software Design Principles: Problem partitioning, abstraction, Top down and bottom
up – design, structured approach, Functional versus object oriented approach of
design, design specification, Cohesiveness and Coupling. Overview of Structured
Analysis and Structured Design (SA/SD) Methodology, structured analysis, data flow
diagrams, extending DFD to structure chart.
Software Requirement Specification
• A software requirements specification (SRS) is a detailed description of a
software system to be developed with its functional and non-functional
requirements.
Requirements describe
Produces one large document written in natural language
contains a description of what the system will do without describing how it will do it.
Crucial Process Steps of Requirement Engineering
Requirement Engineering
Requirement Engineering is the disciplined application of proven
principles, methods, tools, and notations to describe a proposed
system’s intended behaviour and its associated constraints.
SRS may act as a contract between developer and customer.

State of practice:
Requirements are difficult to uncover
• Requirements change
• Tight project Schedule
• Communication barriers
• Market driven software development
• Lack of resources
Types of Requirements
CONT…
1. Known Requirements: Something a stakeholder believes to be
implemented.
2. Unknown Requirements: Forgotten by the stakeholder because they
are not needed right now or needed only by the another
stakeholder.
3. Undreamt Requirement: Stakeholder may not be able to think of
new requirement due to the limited domain knowledge.
Or
CONT…
Functional requirements describe what the software has
to do. They are often called product features. Mainly
Input, output and process
Non Functional requirements are mostly quality
requirements. That stipulate how well the software does,
what it has to do.
User and system requirements
• User requirement are written for the users and include
functional and non functional requirement.
• System requirement are derived from user requirement.
• The user system requirements are the parts of software
requirement and specification (SRS) document
Interface Specification
Important for the customers.
TYPES OF INTERFACES
• Procedural interfaces (also called Application Programming Interfaces
(APIs)).
• Data structures
• Representation of data.
• Technical Feasibility: In Technical Feasibility current resources both hardware software along
with required technology are analyzed/assessed to develop project. This technical feasibility
study gives report whether there exists correct required resources and technologies which will
be used for project development. Along with this, feasibility study also analyzes technical skills
and capabilities of technical team, existing technology can be used or not, maintenance and
up-gradation is easy or not for chosen technology etc.
• Operational Feasibility: In Operational Feasibility degree of providing service to requirements
is analyzed along with how much easy product will be to operate and maintenance after
deployment. Along with this other operational scopes are determining usability of product,
Determining suggested solution by software development team is acceptable or not etc.
• Economic Feasibility: In Economic Feasibility study cost and benefit of the project is analyzed.
Means under this feasibility study a detail analysis is carried out what will be cost of the project
for development which includes all required cost for final development like hardware and
software resource required, design and development cost and operational cost and so on. After
that it is analyzed whether project will be beneficial in terms of finance for organization or
not.
• Legal Feasibility: In Legal Feasibility study project is analyzed in legality point of view. This
includes analyzing barriers of legal implementation of project, data protection acts or social
media laws, project certificate, license, copyright etc. Overall it can be said that Legal Feasibility
Study is study to know if proposed project conform legal and ethical requirements.
• Schedule Feasibility: In Schedule Feasibility Study mainly timelines/deadlines is analyzed for
proposed project which includes how many times teams will take to complete final project
which has a great impact on the organization as purpose of project may fail if it can’t be
completed on time.
• Cultural and Political Feasibility: This section assesses how the software project will affect
the political environment and organizational culture. This analysis takes into account the
organization’s culture and how the suggested changes could be received there, as well as
any potential political obstacles or internal opposition to the project. It is essential that
cultural and political factors be taken into account in order to execute projects successfully.
• Market Feasibility: This refers to evaluating the market’s willingness and ability to accept
the suggested software system. Analyzing the target market, understanding consumer
wants and assessing possible rivals are all part of this study. It assists in identifying whether
the project is in line with market expectations and whether there is a feasible market for the
good or service being offered.
• Resource Feasibility: This method evaluates if the resources needed to complete the
software project successfully are adequate and readily available. Financial,
technological and human resources are all taken into account in this study. It guarantees
that sufficient hardware, software, trained labor and funding are available to complete the
project successfully.
Feasibility Study
Technical feasibility
• Is it technically feasible to provide direct communication connectivity
through space from one location of globe to another location?
• Is it technically feasible to design a programming language using
“Sanskrit”?
Feasibility depends upon non technical Issues like:
• Are the project’s cost and schedule assumption realistic?
• Does the business model realistic?
• Is there any market for the product?

Purpose of feasibility study

“evaluation or analysis of the potential impactof
a proposed project or program.”
Focus of feasibility studies
• Is the product concept viable?
• Will it be possible to develop a product that matches the project’s vision
statement?
• What are the current estimated cost and schedule for the project?

Focus of feasibility studies

• How big is the gap between the original cost & schedule targets & current
estimates?
• Is the business model for software justified when the current cost &
schedule estimate are considered?
• Have the major risks to the project been identified & can they be
surmounted?
• Is the specifications complete & stable enough to support remaining
development work?
Requirements Elicitation
In requirements engineering, requirements elicitation is the practice of researching
and discovering the requirements of a system from users, customers, and other
stakeholders. The practice is also sometimes referred to as "requirement gathering".

Requirements
elicitation is the
process of
gathering and
defining the
requirements for
a software
system.
 What is Requirement Elicitation?
Requirements elicitation is perhaps the most difficult, and most communication-intensive software
development.
1.It can be successful only through an effective customer-developer partnership. It is needed to know
what the users require.
2.Requirements elicitation involves the identification, collection, analysis, and refinement of the
requirements for a software system.
3.It is a critical part of the software development life cycle and is typically performed at the
beginning of the project.
4.Requirements elicitation involves stakeholders from different areas of the organization, including
business owners, end-users, and technical experts.
5.The output of the requirements elicitation process is a set of clear, concise, and well-defined
requirements that serve as the basis for the design and development of the software system.
Requirements Elicitation
Methods/Techniques
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 a structured interview, an agenda of fairly open
questions is prepared. Sometimes a proper
questionnaire is designed for the interview.
2. Workshops
Workshops by a business analyst to elicit information in a collaborative
and facilitated set-up where stakeholders.
It teams up for a set period of time to achieve a pre-determined goal.
workshops in a focused manner in accordance with ground rules like
respecting each other’s opinions, limiting discussion on an off-topic,
and reaching a shared agreement on decision making.
A workshop includes a neutral third-party facilitator who establishes
the purpose, desired outcomes, session agenda and put the ground
rules in force;
a scribe who documents the decisions and track deferred items;
participants who discuss the agenda items and share views.
3. 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.
4. Facilitated Application Specification Technique
• Its objective is to bridge the expectation gap – the 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:
• Part of the environment that surrounds the system.
• Produced by the system.
• 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.
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 design include three major things – Actor, use cases, use case
diagram.
• 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.
• 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.
• Use case diagram: A use case diagram 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.
• The success of an elicitation technique used depends on the maturity of the analyst, developers,
users, and the customer involved.
6. Observation
Observation is an elicitation technique that helps in collecting information
by observing process flows and work environments of stakeholders.
It helps business analysts in situations where users are unable to explain
requirements clearly.
It is in an ACTIVE manner where the observer asks any questions to extract
information.
In leading to a quick understanding of rationale & hidden processes or the
PASSIVE manner where the observer doesn’t intervene in activities by
stakeholders & raise any queries once the observation is over.
7. Document Analysis
Document Analysis is an elicitation technique to extract information by
examining existing documentation. however It is beneficial in a scenario
where the Subject Matter Experts are not available to participate in
elicitation activities.
Key activities carried out as a part of document analysis include
evaluating whether the source document is relevant, current &
credible, in other words, conducting a detailed document review &
recording notes;
performing review with subject matter experts to validate findings.
Commonly used document types used for analysis are process
documents, system specifications, contracts.
It also involves statements of work, business cases, business plans,
training manuals, meeting minutes.
Requirement Engineering Activities
Requirement Analysis
We analyze, refine and scrutinize requirements to make
consistent & unambiguous requirements.
1. Draw the Context Diagram
This diagram is a simple model that defines the boundaries and interfaces of the
proposed system with the external world.
Identify the entities outside the proposed system that interact with the system
2. Development of a Prototype (optional)
One effective way to find out what the customer really wants is to
construct a prototype.
Act like a part of system they say they want.
• We can use their feedback to modify the prototype until the customer
is satisfied continuously.
• Hence, the prototype helps the client to visualize the proposed
system and increase the understanding of the requirements.
• When developers and users are not sure about some of the elements,
a prototype may help both the parties to take a final decision.
• The prototype should be built quickly and at a relatively low cost.
Hence it will always have limitations and would not be acceptable in
the final system. This is an optional activity.
3. Model the Requirements
• This process usually consist of various graphical representations of
the functions, data entities, external entities, and the requirement
between them
• The graphical view may help to find incorrect, inconsistent, missing
and superfluous requirements.
• Model like DFD, ER, State transition diagrams etc.
4. Finalize the Requirements
• After modelling the requirements- understanding of system behavior
• The inconsistency and ambiguities have been identified and
corrected
• Elicitation and analysis activities have provided better insight to the
system.
• We finalize the analyzed requirements and next step is to document
these requirements in the prescribed format.
Requirement Documents
Software Design Principles
• Software design principles are concerned with providing means to
handle the complexity of the design process effectively.
• Effectively managing the complexity will not only reduce the effort
needed for design but can also reduce the scope of introducing errors
during design.
Problem Partitioning
• For small problem, we can handle the entire problem at once but for the significant problem,
divide the problems and conquer the problem it means to divide the problem into smaller pieces
so that each piece can be captured separately.
• For software design, the goal is to divide the problem into manageable pieces.
• Benefits of Problem Partitioning
• Software is easy to understand
• Software becomes simple
• Software is easy to test
• Software is easy to modify
• Software is easy to maintain
• Software is easy to expand
• These pieces cannot be entirely independent of each other as they together form the system.
They have to cooperate and communicate to solve the problem. This communication adds
complexity.
Abstraction
• An abstraction is a tool that enables a designer to consider a component at an
abstract level without bothering about the internal details of the
implementation. Abstraction can be used for existing element as well as the
component being designed.
Here, there are two common abstraction mechanisms
• Functional Abstraction
• Data Abstraction
• Functional Abstraction
• A module is specified by the method it performs.
• The details of the algorithm to accomplish the functions are not visible to the
user of the function.
• Functional abstraction forms the basis for Function oriented design
approaches.
• Data Abstraction
• Details of the data elements are not visible to the users of data. Data
• Modularity
• Modularity specifies to the division of software into separate modules
which are differently named and addressed and are integrated later
on in to obtain the completely functional software. It is the only
property that allows a program to be intellectually manageable. Single
large programs are difficult to understand and read due to a large
number of reference variables, control paths, global variables, etc.
• The desirable properties of a modular system are:
• Each module is a well-defined system that can be used with other
applications.
• Each module has single specified objectives.
• Modules can be separately compiled and saved in the library.
• Modules should be easier to use than to build.
• Modules are simpler from outside than inside.
• Advantages of Modularity
• There are several advantages of Modularity
• It allows large programs to be written by several or different people
• It encourages the creation of commonly used routines to be placed in the library and
used by other programs.
• It simplifies the overlay procedure of loading a large program into main storage.
• It provides more checkpoints to measure progress.
• It provides a framework for complete testing, more accessible to test
• It produced the well designed and more readable program
• Disadvantages of Modularity
• There are several disadvantages of Modularity
• Execution time maybe, but not certainly, longer
• Storage size perhaps, but is not certainly, increased
• Compilation and loading time may be longer
• Inter-module communication problems may be increased
• More linkage required, run-time may be longer, more source lines must be written, and
• Modular Design
• Modular design reduces the design complexity and results in easier
and faster implementation by allowing parallel development of
various parts of a system. We discuss a different section of modular
design in detail in this section:
• 1. Functional Independence: Functional independence is achieved by
developing functions that perform only one kind of task and do not
excessively interact with other modules. Independence is important
because it makes implementation more accessible and faster. The
independent modules are easier to maintain, test, and reduce error
propagation and can be reused in other programs as well. Thus,
functional independence is a good design feature which ensures
software quality.
• It is measured using two criteria:
• Cohesion: It measures the relative function strength of a module.
• Coupling: It measures the relative interdependence among modules.
• 2. Information hiding: The fundamental of Information hiding
suggests that modules can be characterized by the design decisions
that protect from the others, i.e., In other words, modules should be
specified that data include within a module is inaccessible to other
modules that do not need for such information.
• The use of information hiding as design criteria for modular system
provides the most significant benefits when modifications are
required during testing's and later during software maintenance. This
is because as most data and procedures are hidden from other parts
of the software, inadvertent errors introduced during modifications
are less likely to propagate to different locations within the software.
• Strategy of Design
• A good system design strategy is to organize the program modules in
such a method that are easy to develop and latter too, change.
Structured design methods help developers to deal with the size and
complexity of programs. Analysts generate instructions for the
developers about how code should be composed and how pieces of
code should fit together to form a program.
• To design a system, there are two possible approaches:
• Top-down Approach
• Bottom-up Approach
• 1. Top-down Approach: This approach starts with the identification of
the main components and then decomposing them into their more
detailed sub-components.
• 2. Bottom-up Approach: A bottom-up approach begins with the lower
details and moves towards up the hierarchy, as shown in fig. This
approach is suitable in case of an existing system.