Unit 2 - Software Requirement
Analysis and Specifications
Dr. Antima Jain
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,
analyzing 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 behavior and its associated
constraints.
Requirement Elicitation
Techniques
Requirements elicitation is the process of gathering and defining the
requirements for a software system. The goal of requirements elicitation
is to ensure that the software development process is based on a clear
and comprehensive understanding of the customer needs and
requirements. Requirements elicitation involves the identification,
collection, analysis, and refinement of the requirements for a software
system. It is a critical part of the software development life cycle and is
typically performed at the beginning of the project. Requirements
elicitation involves stakeholders from different areas of the organization,
including business owners, end-users, and technical experts. 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
Requirements
development of the software elicitation
system. 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.
Requirements elicitation
Methods:
There are a number of requirements elicitation
methods. Few of them are listed below –
[Link]
[Link] Sessions
[Link] Application Specification Technique
(FAST)
[Link] Function Deployment (QFD)
[Link] Case Approach
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-
[Link] of the environment that surrounds the system
[Link] by the system
[Link] 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-
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 unauthorized access.
•Exciting requirements –
It includes features that are beyond customer’s expectations and prove to be very
satisfying when present. Example – when unauthorized access is detected, it should
backup and shutdown
The major all processes.
steps involved in this procedure are –
[Link] all the stakeholders, eg. Users, developers, customers etc
[Link] out all requirements from customer.
3.A value indicating degree of importance is assigned to each requirement.
[Link] the end the final list of requirements is categorized as –
1. It is possible to achieve
2. It should be deferred and the reason for it
3. 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 design 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.
1. Primary actors – It requires assistance from the system to achieve a
goal.
2. 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 diagram graphically represents what happens when
an actor interacts with a system. It captures the functional
aspect of the system.
1. A stick figure is used to represent an actor.
2. An oval is used to represent a use case.
3. A line is used to represent a relationship between an
actor and a use case.
Requirements Analysis:
Requirement analysis is significant and essential activity after
elicitation. We analyze, refine, and scrutinize the gathered
requirements to make consistent and unambiguous requirements. This
activity reviews all requirements and may provide a graphical view of
the entire system. After the completion of the analysis, it is expected
that the understandability of the project may improve significantly.
Here, we may also use the interaction with the customer to clarify
points of confusion and to understand which requirements are more
important than others.
Data flow diagram:
Data flow diagrams show how data is processed by a
system in terms of inputs and outputs. Components
of data flow diagram includes
• Process
• Flow
• Store
• Terminator
A logical data flow diagram shows system’s activities
while a physical data flow diagram shows a system’s
infrastructure. A data flow diagram can be designed
early in the requirement elicitation process of the
analysis phase within the SDLC (System
Development Life Cycle) to define the project scope.
For easy analyzing a data flow diagram can be drilled
down into its sub-processes known as “levelled
DFD”.
Data Dictionaries:
A data dictionary is a file or a set of files that
includes a database's metadata. The data
dictionary hold records about other objects in the
database, such as data ownership, data
relationships to other objects, and other data. The
data dictionary is an essential component of any
relational database. Ironically, because of its
importance, it is invisible to most database users.
Typically, only database administrators interact
with the data dictionary.
The data dictionary, in general, includes
information about the following:
•Name of the data item
•Aliases
•Description/purpose
•Related data items
•Range of values
•Data structure definition/Forms
The name of the data item is self-explanatory.
Aliases include other names by which this data item is called DEO for
Data Entry Operator and DR for Deputy Registrar.
Description/purpose is a textual description of what the data item is
used for or why it exists.
Related data items capture relationships between data items e.g.,
total_marks must always equal to internal_marks plus external_marks.
Range of values records all possible values, e.g. total marks must be
positive and between 0 to 100.
Data structure Forms: Data flows capture the name of processes
that generate or receive the data items. If the data item is primitive,
then data structure form captures the physical structures of the data
item. If the data is itself a data aggregate, then data structure form
capture the composition of the data items in terms of other data items.
Notations Meaning
x=a+b x includes of data elements a and b.
x=[a/b] x includes of either data elements a or b.
x=a x includes of optimal data elements a.
x=y[a] x includes of y or more occurrences of data
element a
x=[a]z x includes of z or fewer occurrences of data
element a
x=y[a]z x includes of some occurrences of data
element a which are between y and z.
Entity-Relationship Diagrams
ER-modeling is a data modeling method used in software engineering to
produce a conceptual data model of an information system. Diagrams
created using this ER-modeling method are called Entity-Relationship
Diagrams or ER diagrams or ERDs.
Purpose of ERD
•The database analyst gains a better understanding of the data to be
contained in the database through the step of constructing the ERD.
•The ERD serves as a documentation tool.
•Finally, the ERD is used to connect the logical structure of the database to
users. In particular, the ERD effectively communicates the logic of the
database to users.
UML (Unified Modeling Language)
UML is a modelling standard primarily used for specification,
development, visualization and documenting of software system. To
capture important business process and artifacts UML provides
objects like
• State
• Object
• Activity
• Class diagram
There are 14 UML diagrams that help with modelling like the use
case diagram, interaction diagram, class diagram, component
diagram, sequence diagram, etc. UML models are important in the IT
segment as it becomes the medium of communication between all
stakeholders. A UML-based business model can be a direct input to a
requirements tool. A UML diagram can be of two type’s Behavioral
model and Structural model. A behavioral model tries to give
information about what the system do while a structural model will
give what is the system consist of.
Sequence Diagram, Class Diagram
Software Requirement
Specification (SRS)
The production of the requirements stage of the software
development process is Software Requirements
Specifications (SRS) (also called a requirements
document). This report lays a foundation for software
engineering activities and is constructing when entire
requirements are elicited and analyzed. SRS is a formal
report, which acts as a representation of software that
enables the customers to review whether it (SRS) is
according to their requirements. Also, it comprises user
requirements for a system as well as detailed
specifications of the system requirements.
The SRS is a specification for a specific software product,
program, or set of applications that perform particular
functions in a specific environment. It serves several goals
depending on who is writing it. First, the SRS could be
written by the client of a system. Second, the SRS could
be written by a developer of the system. The two methods
create entirely various situations and establish different
purposes for the document altogether. The first case, SRS,
is used to define the needs and expectation of the users.
The second case, SRS, is written for various purposes and
SRS is needed:
[Link]: The SRS serves as a communication tool between the
stakeholders, such as the developers, clients, and end-users. It helps in
establishing a common understanding of the requirements.
[Link]: The SRS provides a clear and concise description of the software
system's requirements. This ensures that all stakeholders have a clear
understanding of what the software is supposed to do.
[Link]: The SRS serves as a formal agreement between the stakeholders.
It defines the scope of the software development project and helps to avoid
misunderstandings or conflicts later on.
[Link]: The SRS is a key input for project planning. It helps in estimating the
time and resources required for software development.
[Link]: The SRS provides a basis for testing the software system. It helps in
developing test cases and ensures that the software meets the specified
requirements.
[Link]: The SRS also serves as a reference document for future
maintenance of the software system. It helps in understanding the original
requirements and the scope of the software system.
In summary, the SRS is essential for ensuring the success of software
development projects. It provides a clear and concise description of the software
system's requirements, helps in planning and testing, and serves as a formal
Characteristics of SRS:
[Link]: The SRS should be comprehensive and provide a complete
description of the software requirements.
[Link] and Concise: The SRS should be written in clear and concise
language, using a consistent terminology, and avoiding ambiguity.
[Link]: The SRS should be verifiable, which means that each
requirement should be testable and verifiable.
[Link]: The SRS should be consistent, which means that the
requirements should not contradict each other.
[Link]: The SRS should be traceable, which means that each
requirement should be linked to its source, and its implementation and
testing status should be tracked.
[Link]: The SRS should be prioritized, which means that the most
important requirements should be identified and given priority over less
important ones.
Requirements documentation is the process of capturing, analyzing,
and documenting the requirements for a software system. It is a critical
component of the software development process, as it ensures that all
stakeholders have a common understanding of the system's requirements.
The following are the key steps involved in requirements documentation:
[Link] Elicitation: This is the process of gathering requirements
from various stakeholders, such as customers, end-users, and subject
matter experts. This can be done through interviews, surveys, focus groups,
or other methods.
[Link] Analysis: Once the requirements have been gathered,
they need to be analyzed to identify any conflicts or inconsistencies. This
step involves prioritizing the requirements, identifying dependencies, and
defining the acceptance criteria.
[Link] Specification: This step involves documenting the
requirements in a formal document, such as a Software Requirements
Specification (SRS) document. The SRS should include a clear description of
the functional and non-functional requirements of the system.
[Link] Verification and Validation: Once the requirements
have been documented, they need to be verified and validated to ensure
that they are complete, accurate, and feasible. This involves reviewing the
requirements with stakeholders, performing simulations or prototypes, and
conducting tests to ensure that the requirements are met.
