UNIT - II

Software Requirements:
• Functional and non-functional requirements
• User requirements
• System requirements
• Interface specification
• The software requirements document.
Requirements engineering process:
• Feasibility studies
• Requirements elicitation and analysis
• Requirements validation
• Requirements management.
System models:
• Context models
• behavioral models
• structured methods.
• data models
• object models
 Software Requirements
• Requirements analysis is very critical process that enables the success of a
system
• Gathering software requirements are the foundation of the entire software
development process.Hence,they must be clear, correct and well-defined.
• The requirement for a system are the description of what the system should
do, the services that it provides and the constraints on its operation. (OR)
• A requirement is simply a high-level, abstract statement of a service that
the system should provide or a constraint on the system
• 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.
• The process of finding out, analysing, documenting and
checking these services and constraints is called requirements
engineering (RE).
• The goal of requirement engineering is to develop and
maintain sophisticated and descriptive ‘System Requirements
Specification’ document.
 Functional requirements
• These requirements focus on user requirements.
• These requirements are mandatory.
• Functional requirements define what a software system
should do. [features]
• It defines a function of a software system or its module.
• These are represented or stated in the form of input to
be given to the system, the operation performed and the
output expected.
• They are basically the requirements stated by the user
which one can see directly in the final product
• Ex: When a customer register on our website,
send an email.
Functional requirement in this online banking
system could be, “When user provide the date
range in transaction query, this input is used
by Server and the webpage is provided with
the necessary cash transaction data”
• 1) Authentication of user whenever he/she
logs into the system.
2) System shutdown in case of a cyber attack.
3) A Verification email is sent to user
whenever he/she registers for the first time on
some software system.
• Functional requirement of bank management
system Project (FYP)
• Login
• Validation
• Get balance information
• Withdrawal of money
• Transfer Money
• Customer info
• Beneficiary
• Administrative Control
• FUNCTIONAL REQUIREMENTS OF LIBRARY MANAGEMENT SYSTEM Project (FYP)
• Only authentic user must have the access to the system.
• Only the user must be able to provide the information related to the library.
• User must be able to:
– Provide the information regarding books.
– Search for the required books from database.
– Add new book to the database.
– Update the number of books in database.
– Enter data of issued book in Database.
– Information of returned books.
• User must have the knowledge about the no of copies of a book.
• Same Id’s for 2 or more books shall not be allowed.
• User must check if the book is available or not before issuing.
• User must enter issue and return date in database.
• The user must know the number of shelves in the library.
 Non-Functional requirements

• Constraints on how the system software should

do it.[quality]

• Ex: Email must be sent 2sec after registration.

• “How should the software system fulfill the
functional requirements?” [quality]
• Non-functional requirement is specified by
technical peoples e.g. Architect, Technical
leaders and software developers.
 Non-functional requirements include -
• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Disaster recovery
• Accessibility
 System requirements
• System requirement simply means needs of system to run
smoothly and efficiently.
• It is written for developers.
• It is a structured document that gives a detailed description of
system functions, services, and operational constraints.
• It requires many hardware and software resources. If these
hardware and software resources are not or less available, then it
may result in system failure or causes problems during
performance.
• Between client and contractor, it is written as a contract to define
all requirements that are needed to be implemented to increases
productivity.
• Persons involved like System end users, Client engineers, System
architects, Software developers.
 System requirement specification using a standard form:
1. Function
2. Description
3. Inputs
4. Source
5. Outputs
6. Destination
7. Action
8. Requires
9. Pre-condition
10. Post-condition
11. Side-effects
User Interface requirements

• UI is an important part of any software or

hardware or hybrid system.
• A software is widely accepted if it is -
➢Easy to operate
➢Quick in response
➢Effectively handling operational errors
➢Providing simple yet consistent user interface
User interface requirements are briefly mentioned below -
➢ Content presentation
➢ Easy Navigation
➢ Simple interface
➢ Responsive
➢ Consistent UI elements
➢ Feedback mechanism
➢ Default settings
➢ Purposeful layout
➢ Strategical use of color and texture.
➢ Provide help information
➢ User centric approach
➢ Group based view settings.
SOFTWARE REQUIREMENTS
DOCUMENT (SRS)
• The requirements document is the official
statement of what is required of the system
developers.
• Should include both a definition of user
requirements and a specification of the system
requirements.
• It is NOT a design document. As far as
possible, it should set of WHAT the system
should do rather than HOW it should do it
IEEE requirements standard defines a generic structure for a requirements
document that must be instantiated for each specific system.
1. Introduction.
i) Purpose of the requirements document
ii) Scope of the project
iii) Definitions, acronyms and abbreviations
iv) References
v) Overview of the remainder of the document
2. General description.
i) Product perspective
ii) Product functions
iii) User characteristics
iv) General constraints
v) Assumptions and dependencies
3.Specific requirements cover functional, non-functional and
interface requirements. The requirements may document
external interfaces, describe system functionality and
performance, specify logical database requirements, design
constraints, emergent system properties and quality
characteristics.
4. Appendices.
5. Index
 Requirements engineering
process
• Requirements engineering (RE) refers to the process of
gathering,analyzing,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, specifying the solution clearly, validating the
specifications and managing the requirements as they are
transformed into a working system.
• RE produces one large document written in natural language,
containing a description of what system will do without describing
how it will do.
• 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 Engineering
Process steps
It is a four-step process, which includes -
1. Feasibility studies
2. Requirements elicitation and analysis
3. Requirements specification
4. Requirements validation
1.Feasibility studies
• Find out the customer needs and budget.
(rough idea)
• Usually done by analysts.
• This is made before committing to a project.
• Like a Proposal
• 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.
• The output for this one is Feasibility report.
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.Requirements 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.
• It is needed to know what the users really need.
• The techniques used for requirements elicitation
include interviews, brainstorming(Group
discussions), task analysis, Delphi
technique(panel of experts), use cases, etc.
The requirements analysis process
3.Requirements 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.
 4.Requirement Validation

• After requirement specifications developed, the

requirements discussed in this document are validated
• Requirements can be the check against the following
conditions -
a) If they can practically implement
b) If they are correct and as per the functionality and
specially of software
c) If there are any ambiguities
d) If they are full
e) If they can describe
• Reviews, buddy checks, making test cases, etc.
are some of the methods used for this.
 System models
• The aim of this chapter is to introduce some
types of system model that may be developed
as part of the requirements engineering and
system design processes.
• When you have read the chapter, you will: ■
understand how graphical models can be used
to represent software systems; ■
• understand why different types of model are
required and the fundamental system modeling
perspectives of context, interaction, structure,
and behavior;
• have been introduced to some of the diagram
types in the Unified Modeling Language
(UML) and how these diagrams may be used
in system modeling;
• be aware of the ideas underlying model-driven
engineering, where a system is automatically
generated from structural and behavioral
models.
 Sample Projects
1. Passport automation System
2. Book Bank
3. Online Exam Registration
4. Stock Maintenance System
5. Online course reservation system
6. E-ticketing
7. Software Personnel Management System
8. Credit Card Processing
9. E-book management System.
10. Recruitment system
 System modeling
• System modeling is the process of developing abstract
models of a system, with each model presenting a different
view or perspective of that system.
• System modeling helps the analyst to understand the
functionality of the system and models are used to
communicate with customers.
• System modeling has generally representing the system using
some kind of graphical notation, which is known as Unified
Modeling Language (UML).
• The development of graphical system models as part of the
requirements specification or the software design
• Models can explain the system from different
perspectives:
1.An external perspective, shows the context
or environment of the system.
2.An interaction perspective , shows the
interactions between a system and its
environment. or between the components of a
system.
3. A structural perspective, shows the data
architecture.
4. A behavioral perspective, shows dynamic
behavior of the system and how it responds to
events.
Diagrams' used in Modelling
1.Activity diagrams, which show the activities
involved in a process.
Activity diagrams are mainly used as a flowchart that
consists of activities performed by the system
2.Use case diagrams, which show the interactions
between a system and its environment.
3.Sequence diagrams, which show interactions
between actors and the system (or) between system
components.
.
4. State chart diagrams, which show how the
system reacts to internal and external
events.
5. Class diagrams, Class diagrams are one of
static structure of a particular system by
modeling its classes, attributes, operations,
and relationships between objects