![Identifying the Requirements from Problem Statements
Requirements | Characteristics of Requirements | Categorization of Requirements | Functional
Requirements | Identifying Functional Requirements
Introduction
Requirements identification is the first step of any software development project. Until the
requirements of a client have been clearly identified, and verified, no other task (design, coding,
testing) could begin. Usually business analysts having domain knowledge on the subject matter
discuss with clients and decide what features are to be implemented.
In this experiment we will learn how to identify functional and non-functional requirements from a
given problem statement. Functional and non-functional requirements are the primary components
of a Software Requirements Specification.
Objectives
After completing this experiment you will be able to:
Identify ambiguities, inconsistencies and incompleteness from a requirements specification
Identify and state functional requirements
Identify and state non-functional requirements
Time Required
Around 3.00 hours
Requirements
Sommerville defines "requirement" [1] 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.
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](https://image.slidesharecdn.com/v-labs-assignment-1-sepm-210922174029/85/V-labs-assignment-1-sepm-1-320.jpg)
![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.
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
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 [iv], 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 a SRS.](https://image.slidesharecdn.com/v-labs-assignment-1-sepm-210922174029/85/V-labs-assignment-1-sepm-2-320.jpg)
![We show herehow to extract functional requirements when a problem statement is given. Thecase
understudy is a online votingsystem.
Internet has led to discussion of e-democracy and online voting. Many peoples think that the
internet could replace representative democracy, enabling everyone to vote on everything and
anything by online voting .Online voting could reduce cost and make voting more convenient. This
type of voting can be done for e-democracy, or it may be used for finalizing a solution, if many
alternatives are present. Online voting make’s use of authentication, hence it needs security, and the
system must be able to address obtaining, marking, delivering and counting ballots via computer.
Advantage of online voting is it could increase voter turnout because of convenience, and it helps to
reduce fraud voting.
A few of the functional requirements have been shown here. There could be others like email
notifications, error handling and so on. Similarly, one has to identify the non functional
requirements also. For example, the system must remain accessible to thousands of users at a time.
Case Study
[Hide]# 1 : A Library Information System for SE VLabs Institute
The SE VLabs Institute has been recently setup to provide state-of-the-art research facilities in the
field of Software Engineering. Apart from research scholars (students) and professors, it also
includes quite a large number of employees who work on different projects undertaken by the
institution.
As the size and capacity of the institute is increasing with the time, it has been proposed to develop
a Library Information System (LIS) for the benefit of students and employees of the institute. LIS
will enable the members to borrow a book (or return it) with ease while sitting at his
desk/chamber. The system also enables a member to extend the date of his borrowing if no other
booking for that particular book has been made. For the library staff, this system aids them to easily
handle day-to-day book transactions. The librarian, who has administrative privileges and complete
control over the system, can enter a new record into the system when a new book has been
purchased, or remove a record in case any book is taken off the shelf. Any non-member is free to use
this system to browse/search books online. However, issuing or returning books is restricted to
valid users (members) of LIS only.
The final deliverable would a web application (using the recent HTML 5), which should run only
within the institute LAN. Although this reduces security risk of the software to a large extent, care
should be taken no confidential information (eg., passwords) is stored in plain text.
Identificationof functional requirements
The above problem statement gives a brief description of the proposed system. From the above,
even without doing any deep analysis, we might easily identify some of the basic functionality of the
system:
New user registration: Any member of the institute who wishes to avail the facilities of the
library has to register himself with the Library Information System. On successful
registration, a user ID and password would be provided to the member. He has to use this
credentials for any future transaction in LIS.
Searchbook: Any member of LIS can avail this facility to check whether any particular book is
present in the institute's library. A book could be searched by its:](https://image.slidesharecdn.com/v-labs-assignment-1-sepm-210922174029/85/V-labs-assignment-1-sepm-3-320.jpg)
![ Title Authors name Publisher's name
User login: A registered user of LIS can login to the system by providing his employee ID and
password as set by him while registering. After successful login, "Home" page for the user is
shown from where he can access the different functionalities of LIS: search book, issue book,
return book, reissue book. Any employee ID not registered with LIS cannot access the
"Home" page -- a login failure message would be shown to him, and the login dialog would
appear again. This same thing happens when any registered user types in his password
wrong. However, if incorrect password has been provided for three time consecutively, the
security question for the user (specified while registering) with an input box to answer it are
also shown. If the user can answer the security question correctly, a new password would be
sent to his email address. In case the user fails to answer the security question correctly, his
LIS account would be blocked. He needs to contact with the administrator to make it active
again.
Issue book: Any member of LIS can issue a book against his account provided that:
The book is available in the library i.e. could be found by searching for it in LIS
No other member has currently issued the book
Current user has not issued the maximum number of books that can
If the above conditions are met, the book is issued to the member.
Note that this FR would remain incomplete if the "maximum number of books that can be
issued to a member" is not defined. We assume that this number has been set to four for
students and research scholars, and to ten for professors.
Once a book has been successfully issued, the user account is updated to reflect the same.
Return book: A book is issued for a finite time, which we assume to be a period of 20 days.
That is, a book once issued should be returned within the next 20 days by the corresponding
member of LIS. After successful return of a book, the user account is updated to reflect the
same.
Reissue book: Any member who has issued a book might find that his requirement is not over
by 20 days. In that case, he might choose to reissue the book, and get the permission to keep
it for another 20 days. However, a member can reissue any book at most twice, after which
he has to return it. Once a book has been successfully reissued, the user account is updated to
reflect the information.
In a similar way we can list other functionality offered by the system as well. However, certain
features might not be evident directly from the problem system, but which, nevertheless, are
required. One such functionality is "User Verification". The LIS should be able to judge between a
registered and non-registered member. Most of the functionality would be available to a registered
member. The "New User Registration" would, however, be available to non-members. Moreover, an
already registered user shouldn't be allowed to register himself once again.
Having identified the (major) functional requirements, we assign an identifier to each of
them [v] for future reference and verification. Following table shows the list:
Table 01: Identifier and priority for software requirements
# Requirement Priority
R1 New user registration High
R2 User Login High](https://image.slidesharecdn.com/v-labs-assignment-1-sepm-210922174029/85/V-labs-assignment-1-sepm-4-320.jpg)
V labs-assignment-1-sepm
- 1. Identifying the Requirements from Problem Statements Requirements | Characteristics of Requirements | Categorization of Requirements | Functional Requirements | Identifying Functional Requirements Introduction Requirements identification is the first step of any software development project. Until the requirements of a client have been clearly identified, and verified, no other task (design, coding, testing) could begin. Usually business analysts having domain knowledge on the subject matter discuss with clients and decide what features are to be implemented. In this experiment we will learn how to identify functional and non-functional requirements from a given problem statement. Functional and non-functional requirements are the primary components of a Software Requirements Specification. Objectives After completing this experiment you will be able to: Identify ambiguities, inconsistencies and incompleteness from a requirements specification Identify and state functional requirements Identify and state non-functional requirements Time Required Around 3.00 hours Requirements Sommerville defines "requirement" [1] 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. 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
- 2. 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. 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 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 [iv], 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 a SRS.
- 3. We show herehow to extract functional requirements when a problem statement is given. Thecase understudy is a online votingsystem. Internet has led to discussion of e-democracy and online voting. Many peoples think that the internet could replace representative democracy, enabling everyone to vote on everything and anything by online voting .Online voting could reduce cost and make voting more convenient. This type of voting can be done for e-democracy, or it may be used for finalizing a solution, if many alternatives are present. Online voting make’s use of authentication, hence it needs security, and the system must be able to address obtaining, marking, delivering and counting ballots via computer. Advantage of online voting is it could increase voter turnout because of convenience, and it helps to reduce fraud voting. A few of the functional requirements have been shown here. There could be others like email notifications, error handling and so on. Similarly, one has to identify the non functional requirements also. For example, the system must remain accessible to thousands of users at a time. Case Study [Hide]# 1 : A Library Information System for SE VLabs Institute The SE VLabs Institute has been recently setup to provide state-of-the-art research facilities in the field of Software Engineering. Apart from research scholars (students) and professors, it also includes quite a large number of employees who work on different projects undertaken by the institution. As the size and capacity of the institute is increasing with the time, it has been proposed to develop a Library Information System (LIS) for the benefit of students and employees of the institute. LIS will enable the members to borrow a book (or return it) with ease while sitting at his desk/chamber. The system also enables a member to extend the date of his borrowing if no other booking for that particular book has been made. For the library staff, this system aids them to easily handle day-to-day book transactions. The librarian, who has administrative privileges and complete control over the system, can enter a new record into the system when a new book has been purchased, or remove a record in case any book is taken off the shelf. Any non-member is free to use this system to browse/search books online. However, issuing or returning books is restricted to valid users (members) of LIS only. The final deliverable would a web application (using the recent HTML 5), which should run only within the institute LAN. Although this reduces security risk of the software to a large extent, care should be taken no confidential information (eg., passwords) is stored in plain text. Identificationof functional requirements The above problem statement gives a brief description of the proposed system. From the above, even without doing any deep analysis, we might easily identify some of the basic functionality of the system: New user registration: Any member of the institute who wishes to avail the facilities of the library has to register himself with the Library Information System. On successful registration, a user ID and password would be provided to the member. He has to use this credentials for any future transaction in LIS. Searchbook: Any member of LIS can avail this facility to check whether any particular book is present in the institute's library. A book could be searched by its:
- 4. Title Authors name Publisher's name User login: A registered user of LIS can login to the system by providing his employee ID and password as set by him while registering. After successful login, "Home" page for the user is shown from where he can access the different functionalities of LIS: search book, issue book, return book, reissue book. Any employee ID not registered with LIS cannot access the "Home" page -- a login failure message would be shown to him, and the login dialog would appear again. This same thing happens when any registered user types in his password wrong. However, if incorrect password has been provided for three time consecutively, the security question for the user (specified while registering) with an input box to answer it are also shown. If the user can answer the security question correctly, a new password would be sent to his email address. In case the user fails to answer the security question correctly, his LIS account would be blocked. He needs to contact with the administrator to make it active again. Issue book: Any member of LIS can issue a book against his account provided that: The book is available in the library i.e. could be found by searching for it in LIS No other member has currently issued the book Current user has not issued the maximum number of books that can If the above conditions are met, the book is issued to the member. Note that this FR would remain incomplete if the "maximum number of books that can be issued to a member" is not defined. We assume that this number has been set to four for students and research scholars, and to ten for professors. Once a book has been successfully issued, the user account is updated to reflect the same. Return book: A book is issued for a finite time, which we assume to be a period of 20 days. That is, a book once issued should be returned within the next 20 days by the corresponding member of LIS. After successful return of a book, the user account is updated to reflect the same. Reissue book: Any member who has issued a book might find that his requirement is not over by 20 days. In that case, he might choose to reissue the book, and get the permission to keep it for another 20 days. However, a member can reissue any book at most twice, after which he has to return it. Once a book has been successfully reissued, the user account is updated to reflect the information. In a similar way we can list other functionality offered by the system as well. However, certain features might not be evident directly from the problem system, but which, nevertheless, are required. One such functionality is "User Verification". The LIS should be able to judge between a registered and non-registered member. Most of the functionality would be available to a registered member. The "New User Registration" would, however, be available to non-members. Moreover, an already registered user shouldn't be allowed to register himself once again. Having identified the (major) functional requirements, we assign an identifier to each of them [v] for future reference and verification. Following table shows the list: Table 01: Identifier and priority for software requirements # Requirement Priority R1 New user registration High R2 User Login High
- 5. Table 01: Identifier and priority for software requirements # Requirement Priority R3 Search book High R4 Issue book High R5 Return book High R6 Reissue book Low Identificationof non-functional requirements Having talked about functional requirements, let's try to identify a few non-functional requirements. Performance Requirements: This system should remain accessible 24x7 At least 50 users should be able to access the system altogether at any given time Security Requirements: This system should be accessible only within the institute LAN The database of LIS should not store any password in plain text -- a hashed value has to be stored Software Quality Attributes Database Requirements Design Constraints: The LIS has to be developed as a web application, which should work with Firefox 5, Internet Explorer 8, Google Chrome 12, Opera 10 The system should be developed using HTML 5 Once all the functional and non-functional requirements have been identified, they are documented formally in SRS, which then serves as a legal agreement. 1. When is feasibility study done? After requirements specifications have been finalized During the period when requirements specifications are prepared Before the final requirements specifications are done Could be done at eny time 2. A good requirement specification is one, which is Consistent Complete Unambiguous All of the above 3. Requirement specification is done After requirements are determined Before requirements are determined Simultaneously with requirements determination Independent of requirements determination
- 6. 4. Functional requirements of a system are related to Using the system (by users) to get some meaningful work done How the system functions under different constraints Whether they adhere to the organization policies 5. SRS refers to Software Requirements Specification System Resources Statement Statement of Reliability of System Standard Requirements Statement 6. The main objective behind preparing a SRS is to Let client and developers agree that they understand each other Formally note down the requirements Estimate the cost of development To judge whether the project could be undertaken Steps for conducting the experiment General Instructions Follow are the steps to be followed in general to perform the experiments in Software Engineering Virtual Lab. 1. Read the theory about the experiment 2. View the simulation provided for a chosen, related problem 3. Take the self evaluation to judge your understanding (optional, but recommended) 4. Solve the given list of exercises Experiment Specific Instructions Following are the instructions specifically for this experiment: 1. From the given problem statement, try to figure out if there's any inconsistency with the requirement specification 2. Also, try to determine what are the functional and non-functional requirements are 3. Select the check boxes accordingly, and then click on the 'Submit' button Consider the problem statement for an "OnlineAuction System" to be developed: New users can register to the system through an online process. By registering a user agrees to abide by different pre-defined terms and conditions as specified by the system. Any registered user can access the different features of the system authorized to him / her, after he authenticates himself through the login screen. An authenticated user can put items in the system for auction. Authenticated users users can place bid for an item. Once the auction is over, the item will be sold to the user placing the maximum bid. Payments are to be made by third party payment services, which, of course, is guaranteed to be secure. The user selling the item will be responsible for it's shipping. If the seller thinks he's getting a good price, he can, however, sell the item at any point of time to the maximum bidder available.
- 7. Assignment 1 – Learning Objectives: 1. Learn about the three different aspects that have to be taken care of while writing requirements specification Limitations: Following are the ambiguities None There's no specification when an auction gets over It doesn't say who are registered users No mention about what technology to be used for developing the application Following are the inconsistencies None An item is said to be sold to the max bidder after auction is over; it can also be sold before the auction is over A registered user seems could be both buyer and seller The problem statement is incomplete because None No mention of how a new user registers No mention of any dispute regarding the sold product No mention of what kind of products could be put on auction Assignment 2 – Learning Objectives: 1. Identifying different functionaries to be obtained from a system Limitations: This list is in no way complete; exercise #4 would address this again Following functional requirements could be obtained from the requirements specifications Registration: New users have to register themselves online with the site and accept its terms & conditions User Login: A user has to login into the site using his correct user ID & password Upload Item for Auction: An authenticated user can upload an item into the site, which is to be put on auction subsequently Auction Item: User puts an item already uploaded by him ino the site on auction Balance Check: Bidder should have enough bank balance to bid Bid for Item: Any registered & authenticated user of the system could place a bid for an item on auction Win Auction: After the auction is over, the maximum bidder for the item owns the item post payment Ship Item: Seller of the item ships the item to the auction owner after he (seller) receives the payment
- 8. Availability: The system should remain up & running before, during and after an auction Remove item: Owner removes an item after uploading it, and doesn't put on auction Remove auctioned item: System automatically removes an item from its inventory after it has been successfully auctioned Site Support: Customer care for the website should provide 24x7 help over phone Assignment 3 – Learning Objectives: 1. Identifying characteristics that a system should have, but not done by the system itself Limitations: Following possible non-functional requirements could be identified from the requirements specifications The system provides option for online registration of new users The system should remain up & running throughout it's working hours System automatially removes an item from its database after it has been successfully auctioned Sessions of different users must not affect each other Customer care for the website should provide 24x7 help over phone System should maintain privacy of their users and should not leak their information to third parties System should be able to service 100 users simultaneously System could remain unavailable for upto 2 hours for maintenance once in a quarter with 36 hour prior notice Following books and websites have been consulted for this experiment. You are suggested to go through them for further details. Bibliography 1. Requirements Engineering: A Good Practice Guide, Ian Sommerville, Pete Sawyer, Wiley India Pvt Ltd, 2009 2. Fundamentals of Software Engineering, Rajib Mall, Prentice-Hall of India, 3rd Edition, 2009 Webliography i. Lecture on "System Analysis and Design", NPTEL ii. When Telepathy Won’t Do: Requirements Engineering Key Practices iii. Requirements Analysis: Process of requirements gathering and requirement definition iv. IEEE Recommended Practice for Software Requirements Specifications v. Requirements Trace-ability and Use Cases