Scribd
Upload
3 views

Software engineering

The document outlines an experiment focused on identifying requirements from problem statements in software engineering. It emphasizes the importance of clear, unambiguous, consistent, and complete requirements, categorizing them into functional and non-functional types. Additionally, it discusses the preparation of Software Requirements Specifications (SRS) as a formal agreement between clients and service providers.

Uploaded by

Arwa Bohra
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
3 views

Software engineering

The document outlines an experiment focused on identifying requirements from problem statements in software engineering. It emphasizes the importance of clear, unambiguous, consistent, and complete requirements, categorizing them into functional and non-functional types. Additionally, it discusses the preparation of Software Requirements Specifications (SRS) as a formal agreement between clients and service providers.

Uploaded by

Arwa Bohra
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 4

IT3CO36: Software Engineering Experiment no- 1

Experiment Title: Identifying the Requirements from Problem Statements Page 1 of 4

1. Objective (s):
After completing this experiment, student will be able to:
 Identify ambiguities, inconsistencies and incompleteness from a
requirements specification
 Identify and state functional requirements
 Identify and state non-functional requirements

2. Theory:
Requirements
Sommerville defines "requirement" as a specification of what should be
implemented. Requirements specify how the target system should behave. It
specifies what to do, but not how to do. Requirements engineering refers to the
process of understanding what a customer expects from the system to be
developed, and to document them in a standard and easily readable and
understandable format. This documentation will serve as reference for the
subsequent design, implementation and verification of the system.
It is necessary and important that before we start planning, design and
implementation of the software system for our client, we are clear about it's
requirements. If we don't have a clear vision of what is to be developed and what
all features are expected, there would be serious problems, and customer
dissatisfaction as well.
Characteristics of Requirements
Requirements gathered for any new system to be developed should exhibit the
following three properties:
 Unambiguity: There should not be any ambiguity what a system to be
developed should do. For example, consider you are developing a web
application for your client. The client requires that enough number of people
should be able to access the application simultaneously. What's the "enough
number of people"? That could mean 10 to you, but, perhaps, 100 to the
client. There's an ambiguity.

Department of Information Technology


Medi-Caps University
1
IT3CO36: Software Engineering Experiment no- 1
Experiment Title: Identifying the Requirements from Problem Statements Page 2 of 4

 Consistency: To illustrate this, consider the automation of a nuclear plant.


Suppose one of the clients say that it the radiation level inside the plant
exceeds R1, all reactors should be shut down. However, another person
from the client side suggests that the threshold radiation level should be R2.
Thus, there is an inconsistency between the two end users regarding what
they consider as threshold level of radiation.
 Completeness: A particular requirement for a system should specify what
the system should do and also what it should not. For example, consider a
software to be developed for ATM. If a customer enters an amount greater
than the maximum permissible withdrawal amount, the ATM should display
an error message, and it should not dispense any cash.
Categorization of Requirements
Based on the target audience or subject matter, requirements can be classified
into different types, as stated below:
 User requirements: They are written in natural language so that both
customers can verify their requirements have been correctly identified
 System requirements: They are written involving technical terms and/or
specifications, and are meant for the development or testing teams
Requirements can be classified into two groups based on what they
describe:
 Functional requirements (FRs): These describe the functionality of a
system -- how a system should react to a particular set of inputs and what
should be the corresponding output.
 Non-functional requirements (NFRs): They are not directly related what
functionalities are expected from the system. However, NFRs could
typically define how the system should behave under certain situations. For
example, a NFR could say that the system should work with 128MB RAM.
Under such condition, a NFR could be more critical than a FR.

Department of Information Technology


Medi-Caps University
2
IT3CO36: Software Engineering Experiment no- 1
Experiment Title: Identifying the Requirements from Problem Statements Page 3 of 4

Non-functional requirements could be further classified into different types


like:
 Product requirements: For example, a specification that the web
application should use only plain HTML, and no frames
 Performance requirements: For example, the system should remain
available 24x7
 Organizational requirements: The development process should comply to
SEI CMM level 4
Functional Requirements
Identifying Functional Requirements
Given a problem statement, the functional requirements could be identified by
focusing on the following points:
 Identify the high-level functional requirements simply from the conceptual
understanding of the problem. For example, a Library Management System,
apart from anything else, should be able to issue and return books.
 Identify the cases where an end user gets some meaningful work done by
using the system. For example, in a digital library a user might use the
"Search Book" functionality to obtain information about the books of his
interest.
 If we consider the system as a black box, there would be some inputs to it,
and some output in return. This black box defines the functionalities of the
system. For example, to search for a book, user gives title of the book as
input and get the book details and location as the output.
 Any high-level requirement identified could have different sub-
requirements. For example, "Issue Book" module could behave differently
for different class of users, or for a particular user who has issued the book
thrice consecutively.
Preparing Software Requirements Specifications

Department of Information Technology


Medi-Caps University
3
IT3CO36: Software Engineering Experiment no- 1
Experiment Title: Identifying the Requirements from Problem Statements Page 4 of 4

Once all possible FRs and non-FRs have been identified, which are complete,
consistent, and non-ambiguous, the Software Requirements Specification (SRS)
is to be prepared. IEEE provides a template [4], also available here, which could
be used for this purpose. The SRS is prepared by the service provider, and
verified by its client. This document serves as a legal agreement between the
client and the service provider. Once the concerned system has been developed
and deployed, and a proposed feature was not found to be present in the system,
the client can point this out from the SRS. Also, if after delivery, the client says
a new feature is required, which was not mentioned in the SRS, the service
provider can again point to the SRS. The scope of the current experiment,
however, doesn't cover writing an SRS.

3. Outcome of Study:

4. Output:

5. Some Sample questions:


1.

Department of Information Technology


Medi-Caps University
4

You might also like