2.

27 Software Requirement Engineering

Sottware Engineering
helpful in clarifying the requirements better, it sometimes creates friction between the
requirements engineer and the stakeholders due to continuous change in the scope.
ACommunication Gap: Even if the end users and stakeholders are clear about the need for
developing the new system, they may find it difficult to express it in a concrete manner due to
theirless exposure to the computing systems. They may state the requirements in an ambiguous
or nontestable fashion.

2.3.6 Developing Use Cases (W-18, W-19)

Tlse casesare arequirements discovery technique that were first introduced in the Objectory method
8snhson et al., 1993). They have now become a fundamental feature of the unified modeling
language.
In their simplest form, a use case identifies the actors involved in an interaction and names the type
of interaction. This is then supplemented by additionalinformation (may be a textual description or
one or more graphical models such as UML sequence or state charts) describing the interaction with
the system.
IUsecases are documented using a high-level use case diagram. The set of use cases represents all of
the possible interactions that will be described in the system requirements.
Actors in the process, wh0may be human or other systems, are represented as stick figures. Each
class of interaction is represented as a named ellipse.
Lines link the actors with the interaction. Optionally, arrowheads may be added to lines to show how
the interaction is initiated. This is shown in Fig. 2.10, which showS some of the use cases for the
patient information system.
Register
Patient

View Manager
Medical Receptionist Personal Info, Generate
Report

View
Record

Doctor
Edit
Nurse
Record

Setup
Consultation
Fig. 2.10: Use Case
Software Engineering 2.31 Software Requirement Engineering

2.4 SRS(SOFTWAREREQUIREMENTS SPECIFICATION) (s-16, S-17, W-18, S-22, S-19)

The software requirements document (sometimes called the Software Requirements Specification
or SRS) is an officialstatement of what the system developers should implement. It should include
both the user requirementsfor a system and a detailed specification of the system requirements.
It is a requirements specification for a software system, and show a complete description of the
behavior of asystem to be developed and may include a set of use cases that describe interactions
the users will have with the software.
Software requirement specification is a document that completely describes what the proposed
software should dowithout describing how software willdo it.
The basic goal of the requirement phase is to produce the SRS, Which describes the complete
behavior of the proposed software. SRS is also helping the clients to understand their own needs.
IEEE defines software requirements specification as, "a ocument that clearly and precisely.
describes each of the essential requirements (functions, performance, design constraints and
quality attributes) of the software and the external interfaces. Each requirement is defined in such a
way that its achievement can be objectively verified by aprescribed method, for example, inspection,
(W-19)
demonstration, analysis or test."
esess
 othersoftware engineering documentation,
technical references,
vendor literature, and
standards
VIL The appendix contains information that supplements the specification. Tabular data, detailed
description of algorithms, charts, graphs and other material are presented as appendices.
2.4.2 Need/Importance of SRS (S-16,W-18, S-19, S-22)
Following points describes need for SRS:
1. There are three major parties interested in a system i.e., the client, the users, and the developer.
Somehow the requirements for the system that will satisfy the needs of the clients and the
concerns of the users have to be communicated to the developer. The problern is that the clhent
usually does not understand software or the software development process and the developer
often does not understand the client's problem and application area. This causes a
communication gap between the parties involved in the development project. Abasic purpose of
Software Requirements Specification (SRS) is to bridge this communication gap. SRS is the
medium through which the client and user needs are accurately specified; indeed SRS forrms the
basis of software development.
2. Another important purpose of developing an SRS is helping the clients understand their own
needs or requirements.
3 An SRS is important because it establishes the basis for agreement between the client and the
supplier on what the software product will do.
4 AnSRS provides a reference for validation of the final product.
5 Ahigh-quality SRS is a prerequisite to high-quality software.
6. SRS enables developer to consider user requirements before the designing of the system. This
reduces rework and inconsistencies, which reduce the development efforts.
7. SRS needed to provide afeedback, which ensures to the user that the organisation understands
the issues or problems to be solved.
8. SRS determines the requirements of the system and thus it enables the developer to have a rough
estimate of the total cost and schedule the software project.
9. SRS uses validation strategies applied to the requirements to acknowledge that requirements are
stated properly.
2.4.3 Characteristics of SRS (W-22, S-22, S-22)
Software requirements specification should be accurate, complete, efficient, and of high quality, so
that it does not affect the entire project plan. An SRS is said to be of high quality when the developer
and user easily understand the prepared document.
The characteristics of SRS are discussed below:
1. Correct: SRS is correct when all user requirements are stated in the requirements document. The
stated requirements should be according to the desired system. This implies that each
requirement is examined to ensure that it (SRS) represents user requirements. Note that there is
no specified tool or procedure to assure the correctness of SRS. Correctness ensures that all
specified requirements are performed correctly.
2. Unambiguous: SRS is unambiguous when every stated requirement has only one interpretation.
This implies that each requirement is uniquely interpreted. In case there is a term used with
multiple meanings, the requirements document should specify the meanings in the SRS So that
it is clear and easy to understand.
 Software Requlremeny
3. Complete:SRS is COmplete when the regquirements
2.34 clearly define what the Software ls,
Software Enginoering performance, design and

mpfuonrcttaichinots,n, alitishen oltw

to
requirements related
requirements not equally Eo
are requrements,
to do. This includes all the
mportance/Stabilitv: All Stability oher the probability of changes
4. toRanked
clearly identify
for each requirement.
differences amongimplies
make e
requirement is identified to
requirements

consisd.teontcuumey nt
hence
requirement in future. can change, modified easily,
requirements of the user sh
5.
Modifiable: The those changes can be main
created in such a manner that requirement 1s clear ax

backwardesdfiagcnil ttrac,at
the structure andstyle of the SRS. source of each tracing and
the
6.
Traceable: SRS is traceable when future. For this, forward be traceable to
reference of each requirement in each requirement should explicitly

7.
used. Forward tracimg implies that defining each requirement
elements. process
effective Backwardtotracing implies
Check whether
Verifiable: SRS is verifiable when the specified
the
requirements Can bereferencingwith
final software meets those requirementsa
ann
verifie its so,,

unambiguity
Note that is
requirements are verified with the help of reviews.
essentia
individual requirements
8.
verifiability. subsets of
Consistent: SRS is consistent when the can be a case when different conflicts defin
requirements ed do
cah
conflict with each other. For example, there temporal
can be logical ortermporal
different terms to refer to the same object. There
requirements whose logical or
betweenan:
characteristics
specified requirements and some
satisfied.
 2.36
migntlook
Oumne
basicSKS
Software Engineering what a 830-1998. Outline
shows
Table21 Standard
BasicSRS
Case Studies on SRS: IEEE ofa
ofthe. Sample
adaptation and extension Table2.1:
1. Introduction:
1.1 Purpose
L.z Document conventions
1.3 Intended audience
1.4 Additional information team members
/SRSt
1.5 Contact information
1.6 References
2. Overall Description:
2.1 Product perspective
2.2 Product functions
2.3 User classes and characteristics
2.4 Operating environment
2.5 User environment
2.6 Designn/implementation Constraints
2.7 Assumptions and dependencies
3. External Interface Requirements:
3.1 User interfaces
3.2 Hardware interfaces
3.3 Software interfaces
3.4 Communication protocols and interfaces
4. System Features:
4.1 System feature A
4.1.1 Description and priority
4.1.2 Action/result
4.1.3 Functional requirements
4.2 System feature B
5. Other Non-functional
Requirements:
5.1 Performance requirements
5.2 Safety requirements
5.3 Security requirements
5.4 Software quality attributes
5.5 Project documentation
5.6 User documentation
6. Other Requirements:
Appendix B:A:
Appendix
Advantages of SRS:
Terminology/Glossary/Definitions list
To be determined
1
Software SRS establishes
the software product will the basic for
2. ASRS do. agreement between the client andthe supplieron
provides a reference
for
3. A
4. A high-quality SRS is a validation
prerequisite to
of the final
product.
high-quality SRS reduces the
Practice Questions develoohipment
gh-qualcost.ity software.