ISSN (Print) : 0974-6846

Indian Journal of Science and Technology, Vol 10(11), DOI: 10.17485/ijst/2017/v10i11/112289, March 2017 ISSN (Online) : 0974-5645

Requirement Engineering Model for Web

Applications
T. S. Shiny Angel1* and John T. Mesia Dhas2
1
SRM University, Chennai - 603203, Tamil Nadu, India; [email protected]
2
VelTech University, Chennai - 600062, Tamil Nadu, India; [email protected]

Abstract
Objectives: To estimate the schedule of the software process with the help of user requirements. Methods/Statistical
Analysis: The empirical methods like questionnaire, interviews etc. Findings: To classify functional data, technical data,
business data etc and also give priority and value to them. It will help the management to predict the schedule for the
software development. Applications/Improvements: It is giving a separate and unique table for each type of requirement.
So the user can understand the type and importance of requirement easily.

Keywords: Business Data, Functional Data, Technical Data, User Requirement

1. Introduction Requirements Management: The portion of

requirements engineering concerned with controlling
A web application is a software system that is accessed requirements changes and ensuring that changes are
over a network such as the Internet or an intranet. That propagated to the remainder of the life cycle.
consists of computational part and a document part (also
called as web document). This paper describe Major terms
used in requirement engineering, Types of requirements, 2. Types of Requirements
Techniques used for requirement gathering, requirement
The requirements are broadly classified into two.
engineering model for web application and a suggested
• Business Requirements.
requirement management tool.
• Technical Requirements.
Business requirements help to frame the problem.
1.1 Major Terms used in Requirement Technical requirements state the design solution. Figure
Engineering 1 shows the types of requirements.
Requirements: Requirements are the necessities required Technical requirements are classified into three. They
for and from the software system. are Functional, Nonfunctional and Data requirements.
Requirements Elicitation: The process of discovering Functional requirement is one that specifies an action
the client’s requirements. It is otherwise called require- that the information system must be able to perform.
ment gathering. Functional requirements are often expressed in terms of
Requirement Analysis: The process of refining and inputs and outputs. Nonfunctional requirements specify
extending the initial set of requirements. the properties of software system itself. Nonfunctional
Requirement Engineering: The job of creating, modify- requirements include Development requirements and
ing and managing requirements over a products life time. operational requirements. Development requirements are
Requirement Development: The portion of require- the properties essential for meeting the needs and desires
ments engineering concerned with establishing of the stakeholders in the development organization such
requirements. as product portability, maintainability, reusability, reli-

*Author for correspondence

 Requirement Engineering Model for Web Applications

Figure 1. Types of requirements.

ability, etc. Operational requirements specify product interviewer may start with one or more prepared closed
properties important to stakeholders’ interest in the use of ended questions, but subsequent questions are posed
the product such as response time, performance, memory in response to the answer. These subsequent questions
usage, security, etc. Data requirements state the needful may be open ended. Conducting a good interview is not
data. It is classified into Functional data and Document always easy. The interviewer must be fully familiar with
data. Functional data must be input to, output from or the application domain. After the interview conducted,
stored in an application. Document data are stating about the interviewer must prepare a written document outlin-
the purpose of application. It is generally called web doc- ing the results of the interview11.
ument. Business requirements in the context of software
engineering  is about eliciting and documenting busi- 3.2 Questionnaire
ness requirements of business users such as customers,
The requirement team prepares a questionnaire and
employees, and vendors early in the development cycle of
sent to the relevant members of the client organization.
a system to guide the design of the future system.
The requirements to be identified based on the answers
received from the members of client organization.
3. Techniques Used for
Requirement Gathering 3.3 Direct Observation
The members of the requirement team observe and write
The number of different techniques can be used to obtain
down the actions of the employees while they perform
the information needed to develop a web application1–13.
their duties. Modern vision of this technique is use video
cameras within the work place to record the activities.
3.1 Interviewing
The members of requirement gathering team meet with 3.4 Focus Groups
the members of the client organization until they are
A focus group is an informal discussion among six to nine
convinced that they have elicited all relevant information
people led by a facilitator who keeps a group on topic.
from the client and future users of the target web applica-
Requirement elicitation focus group consists of stake-
tion. The members of requirement gathering team may
holders or stakeholders’ representatives.
use two basic types of questions. A closed ended ques-
tion requires a specific answer. Open ended questions
are asked to encourage the person being interviewed to
3.5 Elicitation Workshops
speak out. Similarly there are two basic types of inter- An elicitation workshop is a facilitated and directed dis-
view, namely structured and unstructured. In structured cussion aimed at describing the domain or establishing
interview, specific planned questions are asked, fre- stakeholder’s needs and desires. Elicitation workshops are
quently closed ended. In an unstructured interview the similar to focus groups, but are more tightly controlled.

2 Vol 10 (11) | March 2017 | www.indjst.org Indian Journal of Science and Technology
 T. S. Shiny Angel and John T. Mesia Dhas

Figure 2. Requirement engineering model for web application.

3.6 Document Studies 4. Requirement Engineering
The requirement gathering team can learn about the Model for Web Application
problem domain using the documents maintained by
the client organization. The documents include orga- A web application consists of web document regard-
nizational policies and procedures, work processes and ing Clients organization, needed functionalities which
current products information. support for data store and retrieval, computations, com-
munications, interfaces, etc. The web document may
include textual, animated, images, audio and video kind
3.7 Competitive Product Studies
of information. All the required information should be
Collect the information about the similar product avail- collected in the time of requirement gathering. Figure 2
able on market and use it for identifying user level provides help for requirement gathering.
requirements. Requirements are collected from various sources
using various techniques. All the collected require-
3.8 Prototype Demonstration ments are stored in requirements storage. The sources of
A prototype is a working model of part or all of final requirements list out the requirements but not maintain
product. Prototype provides a useful basis for conversa- the order like functional requirement, etc. The require-
tions with stakeholders about features, capabilities, and ment gathering team points that the requirement be
user interface issues. functional or business. Requirements may be added or

Vol 10 (11) | March 2017 | www.indjst.org Indian Journal of Science and Technology 3
 Requirement Engineering Model for Web Applications

deleted or modifiable. The requirements are classified as and modify requirements. In future, requirement classi-
Data, functional, Nonfunctional or business after gather- fication, requirements tracking activities is to be updated.
ing all the requirements. This Model should support for
requirement gathering for web applications.
7. References
1. Yinhuan Z, Beizhan W, Yilong Z, Liang S. Estimation of soft-
5. Algorithm for Requirement ware projects effort based on function point. International
Classification Conference on Computer Science and Education; 2009. p.
941–3. Available from: Crossref
The following algorithm suggests the way in which the 2. Jones C. Estimating Software costs. 2nd ed. NY: McGraw
requirements are classified. The terms used in algorithms Hill company; 2007.
are listed below. 3. Ferchichi A, Bourey J P, Bigand M, Barron M. Design
Req – Requirements. System engineering of software products implementation
BR – Business Requirements. of a software estimation model. IEEE IMACS; Beijing,
FR – Functional Requirements. China. 2006 Oct.
DR – Development Requirements. 4. Zheng Y, Wang B. Estimation of software projects
OR – Operational Requirements. effort based on function point. Proceedings of 2009 4th
FDR – Functional Data Requirements. International Conference on Computer Science and
DDR - Document Data Requirements. Education; 2009.
5. Musilek P, Pedrycz W, Sun N. On the sensitivity of
COCOMO II software cost estimation model. Proceedings
Algorithm
of the Eighth IEEE Symposium on Software Metrics; 2002.
1. Start
PMid:12096686 PMCid:PMC130837. Available from:
2. Collect the requirements from various sources Crossref
3. Store it in the requirements database. 6. Barros RC, Ruiz DD, Tenório NN, Basgalupp MP. Issues on
4. While end of records of requirements database estimating software metrics in a large software operation,
a. If (req == BR) Then Update in BR table IEEE Software Engineering Workshop; 2009.
b. ELSE If (req == FR) Then Update in FR table 7. Nasir M. A survey of software estimation techniques
c. ELSE If (req == DR) Then Update in DR table and project planning practices. 7th ACS International
d. ELSE If (req == OR) Then Update in OR table Conference on Software Engineering, Artificial Intelligence,
e. ELSE If (req == FDR) Then Update in FDR table Networking and Parallel/ Distributed Computing; 2006.
f. ELSE If (req == DDR) Then Update in DDR table Available from: Crossref
g. Endif 8. Stutzke RD. Estimating software- intensive systems.
Addison Wesley; 2005.
h. Endif
9. Vliet HV. Software engineering principles and practice. 2nd
i. Endif
ed. Wiley Student Edition; 2007.
j. Endif 10. Pressman RS. Software engineering a practitioners
k. Endif approach, 6th ed. McGraw Hill International; 2005.
l. Endif 11. Waman S, Jawadekar. Fundamental of software
5. List the Needful Table engineering.1st ed. TATA McGraw Hill; 2008.
6. End 12. Mathew S. Software engineering. Chennai: S Chand
Limited; 2007.
13. Aggarwal KK, Yogesh S. Software engineering. 3rd ed. New
6. Conclusion Age International Publishers; 2007.
This paper deals about requirement engineering process.
The suggested model supports to create, update, delete

4 Vol 10 (11) | March 2017 | www.indjst.org Indian Journal of Science and Technology