20APC0503T-Requirements analysis and specification (Unit-2)

THE NATURE OF SOFTWARE

Nature of Software:

For understanding of the nature of software, it is important to examine the characteristics of software
that make it different from other things that human beings build.
1. Software is developed or engineered: Since software is purely logical rather than a physical
system element. It is not manufactured in the classical sense. Software projects cannot be
managed as if they were manufacturing projects (You may have a factory where each person
has a specific set of tasks they follow. A worker may tighten a screw all day long).
2. Software doesn’t “wear out: Stated simply, the hardware begins to wear out. Software is not
susceptible to the environmental maladies that cause hardware to wear out. However,
Software deteriorates due to changes.
Figure depicts failure rate as a function of time for hardware. The relationship, often called the
“bathtub curve,” indicates that hardware exhibits relatively high failure rates early in its life;
defects are corrected and the failure rate drops to a steady-state level (hopefully, quite low)
for some period of time.

3. Software is custom built: A software component should be designed and implemented so

that it can be reused in many different programs. Although the industry is moving toward
component-based construction, most software continues to be custom built:
Changing Nature of Software (Software Application Domains):
Nowadays, seven broad categories of computer software present continuing challenges for software
engineers .which is given below:
1. System Software: System software is a collection of programs which are written to service other
programs.
2. Application Software: Application software is defined as programs that solve a specific business
need.
3. Engineering and Scientific Software: This software is used to facilitate the engineering function
and task..
4. Embedded Software: Embedded software resides within the system or product and is used to
implement and control feature and function for the end-user and for the system itself.
5. Product-line Software: Designed to provide a specific capability for use by many different
customers
6. Web Application: It is a client-server computer program which the client runs on the web browser
7. Artificial Intelligence Software: Application within this area includes robotics, expert system,
pattern recognition, artificial neural network, theorem proving etc.

Dept of CSE , RUCE

 20APC0503T-Requirements analysis and specification (Unit-2)

THE UNIQUE NATURE OF WEBAPPS

The following attributes are encountered in the vast majority of WebApps.

1. Network intensiveness. A WebApps resides on a network and must serve the needs of a diverse
community of clients. The network may enable worldwide access and communication.
2. Concurrency. A large number of users may access the WebApp at one time.
3. Unpredictable load. The number of users of the WebApp may vary by orders of magnitude from
day to day.
4. Performance. WebApp should have good performance.
5. Availability. WebApps often demand access on a 24/7/365 basis.
6. Data driven. The primary function of many WebApps is to use hypermedia to present text,
graphics, audio, and video content to the end user.
7. Content sensitive. The quality and aesthetic (beauty) nature of content remains an important
determinant of the quality of a WebApp .
8. Continuous evolution: Unlike conventional application software that evolves over a series of
planned, chronologically spaced releases, Web applications evolve continuously.
9. Immediacy: WebApps often exhibit a timeto-market that can be a matter of a few days or weeks.
10. Security: Because WebApps are available via network access, , In order to protect sensitive content
and provide secure modes of data transmission, strong security measures must be implemented. .
11. Aesthetics. When a WebApp has been designed to market or sell products or ideas, aesthetics may
have as much to do with success as technical design.

SOFTWARE MYTHS

Software Myth: Software engineering professionals recognize myths as “misleading attitudes that
have caused serious problems for managers and practitioners alike”. Software myths propagate false
beliefs and confusion in the minds of management, users and developers.
1. Management Myths
2. User Myths
3. Developer Myths
1. Management Myths
Managers, who own software development responsibility, are often under strain and pressure to
maintain a software budget, time constraints, improved quality, and many other considerations.
Common management myths are listed in Table.
#  Myth  Reality
1.  The members of an organization Standards are often incomplete, inadaptable, and
can acquire all-the information, outdated.
they require from a manual, which  Developers are often unaware of all the established
contains standards, procedures, standards.
and principl  Developers rarely follow all the known standards
because not all the standards tend to decrease the
delivery time of software while maintaining its
quality
2.  If the project is behind schedule, Adding more manpower to the project, which is already
increasing the number of behind schedule, further delays the project.
programmers can reduce the time  New workers take longer to learn about the project
gap as compared to those already working on the project

Dept of CSE , RUCE

 20APC0503T-Requirements analysis and specification (Unit-2)

3.  If the project is outsourced to a  Outsourcing software to a third party does not

Third party, the management can help the organization, which is incompetent in
relax and let the other firm managing and controlling the software project
develop software for them. internally. The organization invariably suffers
when it out sources the software project

2. User Myths
#  Myth  Reality
1.  Brief requirement stated in the  Starting development with incomplete and
initial process is enough to start ambiguous requirements often lead to software
development; failure.
 Detailed requirements can be  Adding requirements at a later stage often requires
added at the later stages. repeating the entire development process.
2.  Software is flexible; hence  Incorporating change requests earlier in the
software requirement changes development process costs lesser than those that
can be added during any phase of occurs at later stages. This is because incorporating
the development process. changes later may require redesigning and extra
resources.

3. Developer Myths
#  Myth  Reality
1.  Software development is  50% to 70% of all the efforts are expended after the
considered complete when the  software is delivered to the user
code is delivered.
2.  The success of a software project  The quality of programs is not the only factor that
depends on the quality of the makes the project successful instead the
product produced. documentation and software configuration also play
a crucial role.
3.  Software engineering requires  Software engineering is about creating quality at
unnecessary documentation, every level of the software project.
which slows down the project.  Proper documentation enhances quality which
results in reducing the amount of rework.
4.  The only product that is delivered  The deliverables of a successful project includes not
after the completion of a project is only the working program but also the
the working program(s). documentation to guide the users for using the
software.
5.  Software quality can be assessed  The quality of software can be measured during any
only after the program is phase of development process by applying some
executed. quality assurance mechanism. One such mechanism
is formal technical review that can be effectively
used during each phase of development to uncover
certain errors

Dept of CSE , RUCE

 20APC0503T-Requirements analysis and specification (Unit-2)

REQUIREMENTS GATHERING AND ANALYSIS

 The requirements analysis and specification phase starts after the feasibility study.
 The requirements analysis and specification phase ends when The Requirements Specification
Document (SRS) has been developed and reviewed.
(1). The Goal of The Requirements Analysis And Specification Phase:
 The goal of the requirements analysis and specification phase is to clearly understand the customer
requirements and to systematically organize the requirements into a document called the Software
Requirements Specification (SRS) document.
(2). Who carries out requirements analysis and specification?
 Requirements analysis and specification activity is usually carried out by a few experienced
members called by system analysts, and it normally requires them to spend some time at the
customer site.
(3). How is the SRS document validated?
 Once the SRS document is ready, it is first reviewed internally by the project team to
ensure that it accurately captures all the user requirements, and that it is understandable,
consistent, unambiguous, and complete.
 The SRS document is then given to the customer for review.
 After the customer has reviewed and agrees to it, it forms the basis for all future
development activities and also serves as a contract document between the customer and
the development organization.
Activities

We can conceptually divide the requirements gathering and analysis activity into two separate tasks:
1. Requirements gathering (requirements elicitation) Process.
2. Requirements analysis

1. Requirements Gathering Process(Requirements Elicitation):

The primary objective of the requirements gathering task is to collect the requirements from
the stakeholders (usually a person, or a group of persons who either directly or indirectly are
concerned with the software).

 Requirements gathering - The analyst discusses with the client and end users and knows their
expectations from the software.
 Organizing Requirements - The analyst prioritizes and arranges the requirements in order of
importance, urgency and convenience.
 Negotiation & discussion - If requirements are ambiguous/conflicts, then it is then negotiated
and discussed with stakeholders.
 Documentation - All formal & informal, functional and non-functional requirements are
documented and made available for next phase processing.
(a). Requirement Gathering /Elicitation Techniques:
(i). Interviews: Interviews are strong medium to collect requirements. Organization may conduct
several types of interviews such as:
 Structured (closed) interviews, where every single information to gather is decided in
advance.
 Non-structured (open) interviews, where information to gather is not decided in advance.

Dept of CSE , RUCE

 20APC0503T-Requirements analysis and specification (Unit-2)

 Oral interviews
 Written interviews
 One-to-one interviews which are held between two persons across the table.
 Group interviews which are held between groups of participants. They help to uncover
any missing requirement as numerous people are involved.
(ii). Surveys: Organization may conduct surveys among various stakeholders by querying about
their expectation and requirements from the upcoming system.
(iii). Questionnaires: A document with pre-defined set of objective questions and respective
options is handed over to all stakeholders to answer, which are collected and compiled.
(iv). Task analysis: Team of engineers and developers may analyze the operation for which the
new system is required. If the client already has some software to perform certain operation, it is
studied and requirements of proposed system are collected.
(v).Domain Analysis: Every software falls into some domain category. The expert people in the
domain can be a great help to analyze general and specific requirements.
(vi). Brainstorming: An informal debate is held among various stakeholders and all their inputs are
recorded for further requirements analysis.
(vii). Prototyping: Prototyping is building user interface without adding detail functionality for user
to interpret the features of intended software product.
(viii). Observation: Team of experts visit the client’s organization or workplace and observe the
actual working of the existing installed systems.
2. Requirements Analysis
After requirements gathering is complete, the analyst analyses the gathered requirements to form a
clear understanding of the exact customer requirements.
The main purpose of the requirements analysis activity is to analyse the gathered requirements to
remove all ambiguities, incompleteness, and inconsistencies from the gathered customer
requirements and to obtain a clear understanding of the software to be developed.
The following basic questions pertaining to the project should be clearly understood by the analyst
before carrying out analysis:

? What is the problem?

? Why is it important to solve the problem?
? What exactly are the data input to the system and what exactly are the data output by the
system?
? What are the possible procedures that need to be followed to solve the problem?
? What are the likely complexities that might arise while solving the problem?
? If there are external software or hardware with which the developed software has to
interface, then what should be the data interchange formats with the external systems?

During requirements analysis, the analyst needs to identify and resolve three main types of problems
in the requirements:
• Anomaly
• Inconsistency
• Incompleteness
o Anomaly: An ambiguity is an anomaly. When a requirement is ambiguous, several interpretations
of that requirement are possible. Any anomaly in any of the requirements can lead to the
development of an incorrect system.

Example: When the temperature becomes high, the heater should be switched off.

Dept of CSE , RUCE

 20APC0503T-Requirements analysis and specification (Unit-2)

Words like “high”, “low”, “goo d”, “bad” are ambiguous.

o Inconsistency: Two requirements are said to be inconsistent, if one of the requirements
contradicts the other.

Example: Consider the following two requirements that were collected from two different
stakeholders in a process control application development project.

 The furnace should be switched-off when the temperature of the furnace rises above 500.
 When the temperature of the furnace rises above 500 the water shower should be switched-
on and the furnace should remain on.
o Incompleteness: An incomplete set of requirements is one in which some requirements have been
overlooked.
Example:
If a student secures a grade point average (GPA) of less than 6, then the parents of the student must
be intimated about the regrettable performance through a (postal) letter as well as through e-mail.
However, on an examination of all requirements, it was found that there is no provision by which
either the postal or e-mail address of the parents of the students can be entered into the system.
Note: Can an analyst detect all the problems existing in the gathered requirements?
Ans: A few problems in the requirements be very subtle and escape even the most experienced eyes.

Dept of CSE , RUCE

 20APC0503T-Requirements analysis and specification (Unit-2)

SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

SRS document:
The SRS document is the final outcome of the requirements analysis and specification phase.
(1). Users of SRS Document: Usually a large number of different people need the SRS document for
Very different purposes. Some of the important categories of users of the SRS document are as
follows:
a. Users, customers, and marketing personnel
b. Software developers
c. Test engineers
d. User documentation writers
e. Project managers
f. Maintenance engineers:
(2). Why Spend Time and Resource to Develop an SRS Document? (Importance of SRS)
A well-formulated SRS document finds a variety of usage other than the primary intended usage as a
basis for starting the software development work. The following are the major important uses of a
well-formulated SRS document:
a. Forms an agreement between the customers and the developers: A good SRS document sets
the stage for the customers to form their expectation about the software and the developers
about what is expected from the software.
b. Reduces future reworks: The process of preparation of the SRS document forces the
stakeholders to rigorously think about all of the requirements before design and development
get underway. This reduces later redesign, recoding, and retesting.
c. Provides a basis for estimating costs and schedules: Project managers usually estimate the
size of the software from an analysis of the SRS document. Based on this estimate they make
other estimations such as the effort required to develop the software and the total cost of
development. The SRS document also serves as a basis for price negotiations with the
customer. The project manager also uses the SRS document for work scheduling.
d. Provides a baseline for validation and verification: The SRS document provides a baseline
against which compliance of the developed software can be checked. It is also used by the test
engineers to create the test plan.
e. Facilitates future extensions: The SRS document usually serves as a basis for planning future
enhancements.

Dept of CSE , RUCE

 20APC0503T-Requirements analysis and specification (Unit-2)

Characteristics of a Good SRS Document (IEEE 830 Guidelines)

IEEE Recommended Practice for Software Requirements Specifications [IEEE830] describes the content
and qualities of a good software requirements specification (SRS). Some of the identified desirable
qualities of an SRS document are the following:
Attributes of Good SRS Document
1. Concise: The SRS document should be concise and at the same time unambiguous, consistent,
and complete.
2. Implementation-independent: The SRS should be free of design and implementation
decisions unless those decisions reflect actual requirements. This means that the SRS
document should specify the externally visible behavior of the system and not discuss the
implementation issues.
3. The SRS document should describe the system to be developed as a black box, and should
specify only the externally visible behavior of the system. For this reason, the SRS document is
also called the black-box specification of the software being developed.
4. Traceable: Traceability is also important to verify the results of a phase with respect to the
previous phase and to analyse the impact of changing a requirement on the design elements
and the code.
Example: It should be possible to trace a specific requirement to the design elements that
implement it and vice versa. Similarly, it should be possible to trace a requirement to the code
segments that implement it and the test cases that test this requirement and vice versa.
5. Modifiable: Customers frequently change the requirements during the software development
due to a variety of reasons. To cope up with the requirements changes, the SRS document
should be easily modifiable. For this, an SRS document should be well-structured.
6. Identification of response to undesired events: The SRS document should discuss the system
responses to various undesired events and exceptional conditions that may arise.
7. Verifiable: All requirements of the system as documented in the SRS document should be
verifiable. This means that it should be possible to design test cases based on the description
of the functionality as to whether or not requirements have been met in an implementation.
Example: “When the name of a book is entered, the software should display whether the book
is available for issue or it has been loaned out” is verifiable.

Dept of CSE , RUCE

 20APC0503T-Requirements analysis and specification (Unit-2)

Attributes of Bad SRS Documents

1. Over-specification: It occurs when the analyst tries to address the “how to” aspects in the SRS
document. For example, in the library automation problem, one should not specify whether
the library membership records need to be stored indexed on the member’s first name or on
the library member’s identification (ID) number. Over-specification restricts the freedom of
the designers in arriving at a good design solution.
2. Forward references: One should not refer to aspects that are discussed much later in the SRS
document. Forward referencing seriously reduces readability of the specification.
3. Wishful thinking: This type of problems concern description of aspects which would be
difficult to implement.
4. Noise: The term noise refers to presence of material not directly relevant to the software
development process.
For example, in the register customer function, suppose the analyst writes that customer
registration department is manned by clerks who report for work between 8 am and 5 pm, 7
days a week. This information can be called noise.

Important Categories of Customer Requirements (As per the IEEE 830 guidelines)

As per the IEEE 830 guidelines, the important categories of user requirements are the following.
An SRS document should clearly document the following aspects of software:
(i) Functional requirements
(ii). Non-functional requirements
— Design and implementation constraints
— External interfaces required
— Other non-functional requirements
(iii). Goals of implementation.
(i). Functional Requirements
Requirements, which are related to functional aspect of software fall into this category.
They define functions and functionality within and from the software system.
Examples -
 Search option given to user to search from various invoices.
 User should be able to mail any report to management.
 Users can be divided into groups and groups can be given separate rights.
 Should comply business rules and administrative functions.
 Software is developed keeping downward compatibility intact.
(ii). Non-Functional Requirements
The non-functional requirements are non-negotiable obligations that must be supported by the
software. Non-functional requirements usually address aspects concerning:
 External interfaces,
 User interfaces,
 Maintainability,
 Portability,
 Usability,
 Maximum number of concurrent users,
 Timing and throughput (transactions per second, etc.).
 Design and implementation constraints:
Design and implementation constraints describe any items or issues that will limit the options
available to the developers.

Dept of CSE , RUCE

 20APC0503T-Requirements analysis and specification (Unit-2)

Example constraints can be:

 Corporate or regulatory policies that needs to be honored;
 Hardware limitations;
 Interfaces with other applications;
 Specific technologies, tools, and databases to be used; specific communications protocols to
be used; security considerations; design conventions or programming standards to be
followed,
Consider an example of a constraint that can be included —Oracle DBMS needs to be used as this
would facilitate easy interfacing with other applications that are already operational in the
organization.
 External interfaces required: Examples of external interfaces are— hardware, software and
communication interfaces, user interfaces, report formats, etc.
 Other non-functional requirements: This section contains a description of non- functional
requirements that are neither design constraints and nor are external interface requirements.
Example: Performance requirement such as the number of transactions completed per unit time.
(iii). Goals of implementation: The ‘goals of implementation’ part of the SRS document offers some
general suggestions regarding the software to be developed. These are not binding on the developers,
and they may take these suggestions into account if possible.

Example: The developers may use these suggestions while choosing among different design solutions

CASE STUDTY: ATM (Check additional Material)

REPRESENTING COMPLEX REQUIREMENTS USING DECISION TABLES AND DECISION TREES

Decision tree:

A decision tree gives a graphic view of the processing logic involved in decision making and the
corresponding actions taken. The edges of a decision tree represent conditions and the leaf nodes
represent the actions to be performed depending on the outcome of testing the condition.
Example: -
Consider Library Membership Automation Software (LMS) where it should support the following three
options: ƒ
a. New member ƒ
b. Renewal ƒ
c. Cancel membership
a. New member option:
Decision: When the 'new member' option is selected, the software asks details about the member
like the member's name, address, phone number etc.
Action: If proper information is entered then a membership record for the member is created and
a bill is printed for the annual membership charge plus the security deposit payable.
b. Renewal option:
Decision: If the 'renewal' option is chosen, the LMS asks for the member's name and his
membership number to check whether he is a valid member or not.
Action: If the membership is valid then membership expiry date is updated and the annual
membership bill is printed, otherwise an error message is displayed.

Dept of CSE , RUCE

 20APC0503T-Requirements analysis and specification (Unit-2)

c. Cancel membership option:

Decision: If the 'cancel membership' option is selected, then the software asks for member's name
and his membership number.
Action: The membership is cancelled, a cheque for the balance amount due to the member is
printed and finally the membership record is deleted from the database.
Decision tree representation of the above example –
The following tree shows the graphical representation of the above example. After getting information
from the user, the system makes a decision and then performs the corresponding actions.

Decision table

A decision table is used to represent the complex processing logic in a tabular or a matrix form. The
upper rows of the table specify the variables or conditions to be evaluated. The lower rows of the
table specify the actions to be taken when the corresponding conditions are satisfied. A column in a
table is called a rule. A rule implies that if a condition is true, then the corresponding action is to be
executed.
Example: -
Consider the previously discussed LMS example. The following decision table shows how to represent
the LMS problem in a tabular form. Here the table is divided into two parts, the upper part shows the
conditions and the lower part shows what actions are taken. Each column of the table is a rule.

From the above table you can easily understand that, if the valid selection condition is false then the
action taken for this condition is 'display error message'. Similarly, the actions taken for other
conditions can be inferred from the table.

Dept of CSE , RUCE

 20APC0503T-Requirements analysis and specification (Unit-2)

FORMAL SYSTEM SPECIFICATION

Formal System Specification methods provide us with tools to precisely describe a system and show
that a system is correctly implemented.
Formal Technique:
Definition: A formal technique is a mathematical method to specify a hardware and/or software
system, verify whether a specification is realisable, verify that an implementation satisfies its
specification, prove properties of a system without necessarily running the system, etc.
Why Formal Technique: ?
 To accurately describing the execution behavior of a language.
 English descriptions are often incomplete and ambiguous.
 Compiler writers must implement the language description accurately.
 Programmers want the same behaviour on different platforms.
Note:
There is no single widely acceptable notation or formalism for describing semantics
Formal System Types

Formal Language
Formal specification language consists of: —syn ,sem, and sat.
The set syn is called the syntactic domain, the set sem is called the semantic domain, and the relation
sat is called the satisfaction relation.

Dept of CSE , RUCE

 20APC0503T-Requirements analysis and specification (Unit-2)

For a given specification syn, and model of the system sem, if sat (syn, sem), then syn is said to be the
specification of sem, and sem is said to be the specificand of syn.
 Syntactic domains: The syntactic domain of a formal specification language consists of an
alphabet of symbols and a set of formation rules to construct wellformed formulas from the
alphabet.
 Semantic domains: Formal techniques can have considerably different semantic domains.
Abstract data type specification languages are used to specify algebras, theories, and programs.
 Satisfaction relation: Given the model of a system, it is important to determine whether an
element of the semantic domain satisfies the specifications.

Model-oriented vs. property-oriented approaches:

Formal methods are usually classified into two broad categories:

 Model – oriented
 Property – oriented approaches.
In a model-oriented style, one defines a system’s behavior directly by constructing a model of the
system in terms of mathematical structures such as tuples, relations, functions, sets, sequences, etc.
In the property-oriented style, the system's behavior is defined indirectly by stating its properties,
usually in the form of a set of axioms that the system must satisfy.
Operational Semantics
Describe the meaning of a program by executing its statements on a machine, either simulated or
actual. The change in the state of the machine (memory, registers, etc.) defines the meaning of the
statement.

 Linear semantics: In this approach, a run o f a system is described by a sequence (possibly

infinite) of events or states.
 Branching semantics: In this approach, the behaviour of a system is represented by a directed
graph.
 Maximally parallel semantics: In this approach, all the concurrent actions enabled at any state
are assumed to be taken together.
 Partial order semantics: Under this view, the semantics ascribed to a system is a structure of
states satisfying a partial order relation among the states (events).

Dept of CSE , RUCE

 20APC0503T-Requirements analysis and specification (Unit-2)

AXIOMATIC SPECIFICATION

In axiomatic specification of a system, first-order logic is used to write the pre- and post-
conditions to specify the operations of the system in the form of axioms.

 The pre-conditions basically capture the conditions that must be satisfied before an operation
can successfully be invoked. In essence, the pre-conditions capture the requirements on the
input parameters of a function.
 The post-conditions are the conditions that must be satisfied when a function post-conditions
are essentially constraints on the results produced for the function execution to be considered
successful.
How to develop an axiomatic specifications?
The following are the sequence of steps that can be followed to systematically develop the axiomatic
specifications of a function:
1. Establish the range of input values over which the function should behave correctly. Establish
the constraints on the input parameters as a predicate.
2. Specify a predicate defining the condition which must hold on the output of the function if it
behaved properly.
3. Establish the changes made to the function’s input parameters after execution of the
function..
4. Combine all of the above into pre- and post-conditions of the function.
Example:
Specify the pre- and post-conditions of a function that takes a real number as argument and returns
half the input value if the input is less than or equal to 100, or else returns double the value.

Example:
Axiomatically specify a function named search which takes an integer array and an integer key value as
its arguments and returns the index in the array where the key value is present.

ALGEBRAIC SPECIFICATION
 In the algebraic specification technique, an object class or type is specified in terms of
relationships existing between the operations defined on that type.
 Essentially, algebraic specifications define a system as a heterogeneous algebra. A
heterogeneous algebra is a collection of different sets on which several operations are defined
An algebraic specification is usually presented as.
 Types section
 Exception section
 Syntax section
 Equations section
 construction operators
 Inspection operators

Dept of CSE , RUCE

 20APC0503T-Requirements analysis and specification (Unit-2)

Example 1: Let us specify a data type point supporting the operations create, xcoord, ycoord, isequal;
where the operations have their usual.

Example: 2: Let us specify a bounded FIFO queue having a maximum size of MaxSize and supporting
the operations create, append, remove, first, and isempty; where the operations have their usual
meaning.

Dept of CSE , RUCE