Unit 3

Software requirement
analysis and specification

Requirement:-
 In a very simple language, a requirement can be defined as a feature which end user needs in the existing or
the new system

 According to IEEE standard 729: A requirement is defined as (i) a condition or capacity needed by a user to
solve a problem or to achieve an objective;(ii) a condition or capability that must be met or possessed by a
system or system component to satisfy a contract, standard, specification or other formally imposed
document;(iii) a document representation of condition or capacity as in(i) and (ii).

 Requirement may range from a high-level abstract statement of a service or of a system constraint to a
detailed mathematical functional specification.

 Requirement for a software system set out what the system should do and define constraints on its operation
and implementation.

Types of requirement

1. User requirements:- Statements in natural language plus diagramsof the services the system provides and its
operational constraints. Written for customers

2. System requirements:-A structured document setting out detailed descriptions of the system services. Written as a
contract between client and contractor

3. Software specification:-A detailed software description which can serve as a basis for a design or
implementation. Written for developers

Er.Sani khanal Page 1

Functional requirements:-
 The functional requirements for a system describe what the system should do. These
requirements depend on the type of software being developed, the expected users of the software
and the general approach taken by the organization when writing requirements. When expressed as user
requirements, the requirements described in a fairly abstract way. However, functional system
requirements describe the system function in detail, its inputs and outputs, expectations, and so on.

 Functional requirements for the software system may be expressed in a number of ways

 E.g.: Functional requirements for a library system called LIBSYS, used by students and faculty to order
books and documents from other libraries.

 The user shall be able to search either all of the initial set of databases or select a subset
from it.

Er.Sani khanal Page 2

  The system shall provide appropriate viewers for the user to read documents in the document
store.
 Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to
copy to the account’s permanent storage area

Requirements imprecision
 Imprecision in the requirements specification is the cause of many software engineering problems.
 Problems arise when requirements are not precisely stated
 Ambiguous requirements may be interpreted in different ways by developers and users
 Consider the term ‘appropriate viewers’
 User intention -special purpose viewer for each different document type
 Developer interpretation -Provide a text viewer that shows the contents of the document

Requirements completeness and consistency

 In principle requirements should be both complete and consistent

Complete:-They should include descriptions of all facilities required.

Consistent:-There should be no conflicts or contradictions in the descriptions of the system facilities

 In practice, it is impossible to produce a complete and consistent requirements document.

Non-functional requirements
 These functions are not directly concerned with the specific functions delivered by the system.

 Define system properties and constraints e.g. reliability, response time and storage
requirements. Constraints are I/O device capability, system representations, etc

 They may be specifying system performance, security, availability, and other emergent properties.
This means they are often more critical than individual functional requirements.

 Non-functional requirements are not just concerned with the software system to be developed. Some non-
functional requirements may constrain (restrict) the process that should be used to develop the system.

 Process requirements may also be specified mandating a particular CASE system, programming language or
development method

Er.Sani khanal Page 3

  Non-functional requirements may be more critical than functional requirements. If these are not met, the
system is useless.
Non-functional classifications
Product requirements

 These requirements specify or constrain the runtime behavior of the software.

 Example include performance requirements for how fast the system must execute and how much memory it
requires reliability requirements that set out the acceptable failure rate, security requirements, and usability
requirements.

Organizational requirements

 These Requirements are broad system requirements derived from policies and procedures in the customer’s
and developer are organizational.
 Example include operational process requirements that define how the system will be used, development
process requirements that specify the programming language.

External requirements

 This broad heading covers all requirements that are derived from factors external to the system and its
development process.
 These may include regulatory requirements that set out what must be done for the system to be approved for
use of regulator ,such as nuclear safety authority, ethical requirements e.t.c

Er.Sani khanal Page 4

Non-functional Requirements measures specifications:

Property Measure

Speed Processed transactions/second

User/Event response time

Size K Bytes

Number of RAM chips

Ease of use Training time

Number of help frames

Er.Sani khanal Page 5

 Reliability Mean time to failure Probability of unavailability Rate
of failure occurrence

Availability

Robustness Time to restart after failure Percentage of events causing

failure

Probability of data corruption on failure

Portability Percentage of target dependent statements

Number of target systems

Requirements Engineering Processes

 It is the systematic of documenting requirements through an interactive co-operative process of analyzing
the problems, documenting the resulting observations in a variety of representation format, and checking the
accuracy of the understanding gained.

 Requirement Engineering is the systematic use of proven principles, techniques, tools and languages for the
cost effective analysis, documentation and ongoing evolution of user needs and the specification of the
external behavior of the system in order to satisfy these needs.

 An input to this activity of requirements engineering are requirements which are informal and fuzzy
(unclear) and output is clear, well defined, complete and consistent.

 The requirements engineering activity is the most crucial and most important in the software development
life cycle because the errors introduced at this stage are the most expensive errors requiring lot of rework if
detected late in software life cycle.
Er.Sani khanal Page 6
  The processes used for Requirement Engineering vary widely depending on the application domain, the
people involved and the organisation developing the requirements

 However, there are a number of generic activities common to all processes

1. Feasibility study
2. Requirements elicitation
3. Requirements analysis
4. Requirements validation
5. Requirements management

1. Feasibility study:
 Feasibility study is a set of preliminary business requirements, an outline description of the
system and how the system is intended to support business process.
 The results of the feasibility study should be are part that recommends whether or not it
is worth carrying on with the requirements engineering and system development process.
 Feasibility study involves information assessment (what is required), information collection and
report writing

Types of Feasibility:

Technical Feasibility - Technical feasibility evaluates the current technologies, which are needed to accomplish
customer requirements within the time and budget.

Operational Feasibility - Operational feasibility assesses the range in which the required software performs a
series of levels to solve business problems and customer requirements.

Economic Feasibility - Economic feasibility decides whether the necessary software can generate financial profits
for an organization.
Er.Sani khanal Page 7
 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.

[Fig: requirement elicitation and analysis process]

Er.Sani khanal Page 8

 I. Requirement discovery and understanding: This is the process of interacting with stakeholders of the
system to discover their requirements. Domain requirements from stakeholders and documentation are also
discovered during this activity.
II. Requirement classification and organization: this activity takes the unstructured collection of
requirements, groups related requirements and organizes them into coherent cluster.
III. Requirements prioritization: When multiple stakeholders are involved, requirements will conflict. This
activity concerned with prioritizing requirements and finding and resolving requirements conflicts through
negotiation.
IV. Requirement documentation: The requirements are documented and input into the next round of the spiral.
An early draft of the software requirements may be produced at this stage, or the requirements may simple
be maintained of on whiteboards or other shared spaces.

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

Er.Sani khanal Page 9

  .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.

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.
Er.Sani khanal Page 10
Elicitation and Analysis of requirement overview of techniques:

1. View point:
 Stakeholders represent different ways of looking at a problem or problem viewpoints
 This multi-perspective analysis is important as there is no single correct way to analyze system
requirements

Banking ATM system

 The example used here is an auto-teller system which provides some automated banking services
 I use a very simplified system which offers some services to customers of the bank who own the
system and a narrower range of services to other customers
 Services include cash withdrawal, message passing (send a message to request a service),
ordering a statement and transferring funds

Auto teller viewpoints

 Bank customers
 Representatives of other banks
 Hardware and software maintenance engineers
 Marketing department
 Bank managers and counter staff
 Database administrators and security staff
 Communications engineers
 Personnel department

Types of viewpoint

Data sources or sinks

• Viewpoints are responsible for producing or consuming data. Analysis involves checking that data is
produced and consumed and that assumptions about the source and sink of data are valid

Er.Sani khanal Page 11

Representation frameworks

• Viewpoints represent particular types of system model. These may be compared to discover requirements
that would be missed using a single representation. Particularly suitable for real-time systems

Receivers of services

• Viewpoints are external to the system and receive services from it. Most suited to interactive systems

VIEW POINT SERVICE INFORMATION

Viewpoint data/control

ACCOUNT
HOLDER

Er.Sani khanal Page 12

View point hierarchy

Customer/cash withdrawal templates

2. 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.

Er. Sanni Khanal Page 13

Interviews maybe be open ended or structured.

 In open ended interviews there is no pre-set agenda. Context free questions may be asked
to understand the problem.
 In structured interview, agenda of fairly open questions is prepared. Sometimes a proper
questionnaire is designed for the interview.

Basic Rules:

 The overall purpose of performing the interviews should be clear.

 Identify the interviewees in advance.
 Interview goals should be communicated to the interviewee.
 Interview questions should be prepared before the interview.
 The location of the interview should be predefined.
 The time limit should be described.
 The interviewer should organize the information and confirm the results with the
interviewees as soon as possible after the interview.

3. 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.

Er. Sanni Khanal Page 14

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.

Er. Sanni Khanal Page 15