Software Requirements

Unit-II
Contents

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,
• Data models,
• Object models,
• Structured methods.
Introduction

• 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.
What is a Requirement?
A requirement can range from a high level abstract statement of a service or of a system constraint to a detailed
mathematical functional specification.
What is a 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.
Types of Requirements
• There are three types of requirements: They are
1. User Requirement
It is a collection of Statements in natural language description of the services the system provides and its operational
constraints. It is written for customers.
2. System Requirement
It is structured document that gives the detailed description of the system services. It is written as a contract between client and
contractor.
3. Software Specification
It is defined software description that can serve as a basis for design or implementation Typically it is written for software
developers.
Functional and Non Functional Requirements
• Software System requirement can be classified as functional and non-functional requirements.
Functional Requirements:
1. Functional requirements should describe all the required functionality or system services.
2. The customer should provide statement of service.
3. Functional requirements are heavily dependent upon the type of the software, expected users and the type of system where the software is
used.
4. Functional user requirements mat be high-level statements of what the system should do but functional system requirements should
describe the system services in detail.
Example for functional requirements is Library system.
• Non Functional Requirements
1. The non functional requirements define system properties and constraints.
Various properties of a system can be: Realiability,response time, storage requirements.
And constraints of the system can be: Input and Output device capability, system representations etc.
2. Process requirements may also specify programming language or development method.
3. Non functional requirements are more critical than functional requirements. If the non functional requirements do not meet
than functional requirements do not meet then the complete system is of no use.
• Types of Non Functional Requirements
Classification of non functional requirements is as given below.
• Product Requirement
These requirement specify how a delivered product should behave in a particular way. For instance: execution speed, reliability.
• Organizational requirements
The requirements which are consequences of organizational policies and procedures come under this category. For instance: Process
standards used implementation requirements.
• External Requirements
These requirements arise due to the factors that are external to the system and its development process, For instance: interoperability
requirements, legislative requirements.
In short, non functional requirements arise through
a. User needs
b. Because of budget constraints
c. Organizational policies
d. The need for interoperability with other software or hardware systems
e. Because of external factors such as safety regulations. Metrics used for specifying the non functional requirements.
• User Requirements
1. The user requirements should describe functional and non functional requirements in such a way that they are understandable by system
users who don’t have detailed technical knowledge.
2. User requirements are defined using natural language ,tables and diagrams because these are the representations that can be understood by
all users.
3. Various problems that can arise in the requirement specifications when requirements are given natural language.
Lack of Clarity
Sometimes requirements are given in ambiguous manner. It is excepted that text should help in clear and precise understanding of the
requirements.
Requirements Confusion
There may be a confusion in functional requirements and non functional requirements ,system goals and design information.
Requirements Mixture
There may be a chance of specifying several requirements together as a single requirement.
 Requirement Engineering Process
• The requirement engineering processes are the processes used to discover,analyse and validate the system
requirements.
• The goal of the requirement engineering process is to create and maintin system requirement document.
• Before beginning these processes it is necessary to check whether the system that will get generated is useful for
the business or not.
• This kind of study is called Feasibility Study.
• Once the system is feasible then only the requirement engineering process begins.
• Various activities that are conducted under requirement engineering process are discovering
requirements,converting these requirements into some other form and then checking whether the requirements
are as per the customer need or not.
• Let us understand the requirement engineering process in detail.
It is a four-step process, which includes -
• Feasibility Study
• Requirement Elicitation and Analysis
• Software Requirement Specification
• Software Requirement Validation
• 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
• Getting all, and only, the right people involved.
• Stakeholders often don't know what they want
• Stakeholders express requirements in their terms.
• Stakeholders may have conflicting requirements.
• Requirement change during the analysis process.
• 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.
• 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.
• 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.
• 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 -
• If they can practically implement
• If they are correct and as per the functionality and specially of software
• If there are any ambiguities
• If they are full
• If they can describe
Requirements Validation Techniques
• Requirements reviews/inspections: systematic manual analysis of the requirements.
• Prototyping: Using an executable model of the system to check requirements.
• Test-case generation: Developing tests for requirements to check testability.
• Automated consistency analysis: checking for the consistency of structured requirements
descriptions.
 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.