International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)

Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 3, Issue 1, January February 2014 ISSN 2278-6856

Requirement Engineering Monitoring Elicitation Technique for End Product Software

Abstract A systematic approach to eliciting organizing
and documenting the software requirements of the system and establishing and maintaining agreement between the client and development project team on changes to those requirements which includes maintaining a clear statement of the requirements along with appropriate attribute and traceability to other requirements. Describes the requirements types specifying the information to be collected and control mechanisms to be used for measuring reporting and controlling changes to the product requirements. Stakeholders might same requirements not met at the same time we introduced the concept of business requirements reduce the effort cost issues in development. We also provided example end product requirement analysis meets the client satisfaction.

Keywords - Requirement Engineering, Elicitation, Intrusion, Software Development.

Introduction I
Software systems analysts have to identify the software systems are to be developed, the purpose is to perform certain tasks as determined by the software users. Hence software systems have to provide functionalities that allow them to perform the tasks for which they have been designed. Furthermore software systems are destined to be embedded into organizational settings, consisting of human beings, machines and possibly other software systems. The organizations impose constraints on the operational and performance characteristics of the software. Human beings benefit from the applications of software systems in data processing, information management, machine control systems, communication networks etc. The usability of software systems depends on the perception of their users as to what the software should do, can do and how well they fit into the users' environment. Requirements engineering can be regarded as consisting of a set of interrelating activities that result in the production of a SRSD. Requirement engineering consists of requirement elicitation activities, requirement analysis activities and requirement specification activities. The decomposition of the software requirement engineering process has to be taken as a convenient description of necessary tasks that are carried out and not necessarily performed in any order or at distinct periods in time. However a particular item in the software requirement development will have been elicited, analyzed and specified. In fact, a single activity may be seen as requirement elicitation and requirement analysis at the same time. Requirements are often synthesized during an iterative elicitation and analysis cycle. There is no Volume 3, Issue 1 January February 2014

necessary clear distinction between the elicitation and analysis phases. For example a discussion between the analyst and the customer can reveal particular characteristics of the requirements analysis and stimulate the customer to enunciate new or modified requirements elicitation. It is appropriate to explain what is considered as being an item of requirement as used throughout this document an item of requirement refers to a capability provided by the software system and which can produce a particular result an input, an output, or a data transformation that is observable by the user. The characteristic that a requirement relates to an observable result is necessary, as it provides a means of verifying that the software behaves as expected by the users. Each capability can be considered on its own, and can be implemented independently from other capabilities provided by the system. However the design of the software should not affect the actual result produced by the capability, but should only be considered as a matter of convenience and efficiency, given the particular software development platform chosen. In fact, it is generally accepted that design consideration should not be considered during the requirement engineering process, set of all such requirement items form the requirement specification for the software system.

SECTION II 2. Related Work: System development problems and

failure is the omission of important requirements or the inclusion of unwanted rigid requirements. Requirement errors are a primary factor for all rework efforts which according to industry statistics within a given project. Problems are partially caused by the absence of a systematic process to relate requirements to business goals either of the development or system. Pedigreed attribute Elicitation method is a method that elicits and relates important requirement to business goals to capture the business goals for an organization that lie behind the development of a software reliant system. A comprehensive list of potential business goals is used as the starting point for the elicitation reduces the likelihood that important requirements will be negotiated while doing the elicitation the source and rationale for the requirements are captured as a pedigree. The output of PALM is a collection of important requirements tied to the business goals that they support where the requirements have a pedigree. PALM utilizes a comprehensive catalog of business to elicit the specific goals for the system being developed, these specific goals may change technology or the legal social business or Page 32

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)

Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 3, Issue 1, January February 2014 ISSN 2278-6856
customer environment is also elicited for example if system requires a transaction turnaround time of 0.2 seconds can we say it is 0.2 and 0.3 or 0.1 . Perhaps it is 0.2 seconds because a business goal is to beat out competition product that has a transaction time of 0.25 seconds. is the quality requirements such as those for safety and security whereas other elicitation methods are focused on end-user requirements so their effectiveness in the identification of security requirements is unknown. Use case describes system behavior in terms of functional requirements, misuse provides opportunities to investigate and validate the security requirements necessary to accomplish the system mission. Soft system deals with the situation of problem in which there is a high social political and human activity component to define rather than hard problems that are more technology oriented. Soft system provides structure to soft problem situation and enables their resolution in an organized manner. Quality function deployment provides the translating requirements into the appropriate technical requirements for each stage of product development and production. Identifying the customer, gathering high level customer requirements, and constructing a set of system features that can satisfy customer needs. Controlled requirement is analysis method that clarifies the users view of the services to be supplied by the proposed system and the limitations imposed by the system operational environment in conjunction with some degree of performance and reliability investigation.

Figure 1 shows the Business Requirements Quality Attributes Figure represents the relationship between goals and architecture, business goal is to capture market share by providing best of breed quality in domain and other hand make use of development staffs current knowledge training might lead the architecture to choose a familiar technology over an unfamiliar one. To build PALM we clustered categories of standard business goals for example growth and continuity of the organization managing market position and meeting responsibility towards society. PALM takes place in a workshop format where representatives for the business development support and technical development aspects of the product being participate. Advantages of PALM includes Clarified quality attribute requirement Improved architecture documentation Documented basis for architectural decisions Identified risks early lifecycle

SECTION III 3. Problem Definition: To find the actual performed

requirements elicitation has experienced its challenges some of the problems faced by business analysts during requirements elicitation gathering requirements. Different stakeholders at different times which cannot all be met at the same time because there are in conflict to get all stakeholders in the same room to document and publish. Continuously improve communication skills document information gathered publish for review feedbacks verify assumptions create a glossary of terms use multiple subject experts etc. Poorly documented processes situation high level executive may look like doing the work at the same way when the actual details of the process vary from end user to end user. It management understand the requirements and happens in the business and do not enable or allow the business analyst to have direct access to the end user. Stakeholders who are new to the requirement elicitation process are faced with unprecedented concepts or processes tend to have a hard time identifying their preferences tend to keep changing. When stakeholders presented with too many choices generally have a harder time deciding the option to select when they do make decision they are less satisfied than if those who have to pick from a much smaller list of options. Requirements are bad if they ambiguous incomplete not verifiable when stakeholder provide and analysts document bad requirement they result in systems which are not completed or not used. Page 33

Eliciting security requirements with security in mind and used for traditional requirements engineering, developing a list of selection process we have different elicitation method. Use-case describes the system owner need the system to show specification of requirements is collection of use cases should not be used as a substitute for a requirements specification document. Misuse cases apply the concept of negative scenario situation that the system owner does not want to occur in a use case context for example business leaders military planners are familiar with analyzing their opponents best moves as identifiable threats. Misuse case Volume 3, Issue 1 January February 2014

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)

Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 3, Issue 1, January February 2014 ISSN 2278-6856
the elicited requirements. Many techniques can be used in the requirements elicitation process that is Ethnography, Contextual query, Scenarios. Requirements analysis and negotiation is a process during which requirements are analyzed and modeled and possible conflicts are resolved by negotiation between stakeholders. The input to this process is elicitation and consistent and complete set of requirements is the output. Unified modelling language is a collection of technique for modeling software or system UML provides mechanisms for modeling requirements, specification description language is a relatively mature requirements description language, structural analysis structured design uses a set of different techniques such as functional decomposition technique data flow and data dictionary data processing of the system. Languages that used to modeled are Informal language is the most typical and widely used informal modeling technique has an intuitive syntax and semantics and can be easily used, Semi-formal language has a formal syntax but informal semantics are conceptual modeling language, Formal language is category of language has a well-defined formal syntax and semantic typically built on mathematical theory such as set, logic or algebra theory or a combination of all. Requirements documentation is the process of documenting the requirements at an appropriate level of detail in the most suitable notation based on a welldefined document structure, key issues in the process are to select proper notations to document requirements and at the appropriate level of detail. Documentation process receives input from the analysis and negotiation process output is a well-structured and defined specification verified and validated. Requirements verification and Validation: Requirements verification and validation is the process of document to ensure that is unambiguous consistent and complete and that the stakeholders are satisfied with the final requirements specification. Verification and validation does not repeat the tasks of requirements analysis instead it uses now a system view. Output of the requirement documentation process is the finalized requirements specification document agreed and authorized by all stakeholders. Formal requirements inspection is used for identification of incompleteness inconsistency ambiguity and conflict in the requirements specification, requirements testing is used to examine the implement ability and understandability of the requirements through writing test cases for requirements finally requirement checklist is a technique used to examine a list of common concerns in requirements specification. Page 34

Once after the discussion requirement elicitation team to understand the each requirement methods and effective use them in the real case to focus on the different methods. Conversational techniques are really help for collection hectic information about the requirements along with conversational methods uncover opinions and goals of different individuals. Observational methods are best choice for uncovering basic aspects of routine order to provide vital information for designing solution, these methods are used to directly extracted requirements from peoples behavior and verbalized thoughts. Analytical methods have numerous advantages as people are not the only source of information in terms of requirements, reuse of already available information saves the time and cost.

SECTION IV 4. Requirement Process Monitoring in Software Development: Requirement engineering

is process an essential to overall quality of the software product based on empirical investigations, in according to Loucopouloss definition requirement engineering is a process as a collection of well-defined activities and transformations that people use to develop requirements of a system and maintain the requirements specification artefacts.

Figure 2 Requirements Process in Software Lifecycle Requirements elicitation is a process of identifying needs and disparities among the involved communities for the purpose of defining and distilling requirements to meet the constraints. Requirements elicitation are acquisition requirements capture, discovery requirements gathering problem analysis and understanding etc. sources that can be used for eliciting requirements some of them are customer requirements specification, documentation pertaining to pre-existing system that perform functions similar to the anticipated novel software system, users of pre-existing systems, potential users of the new system. Challenges during the elicitation phase ensure effective communication between various stakeholders and tacit knowledge, requirement elicitation phase is a collection of elicitation notes or informal document which describes Volume 3, Issue 1 January February 2014

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)

Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 3, Issue 1, January February 2014 ISSN 2278-6856 SECTION V 5. Requirement for Real Time Applications:
The requirement must be written so that several contracts can bid for the contract offering perhaps different ways of meeting the client organization needs. Once the awarded the contract must start on system definition & requirement document contains all the types of requirements for the product to demonstration in front of the client and can validate what the software will do. User requirements must provide a means of representing and accessing external files created by other tools, user should be provided with facilities to define the type of external files, each external file type may have an associated tool which may be applied to the file and represented as a specific icon on the users display, facilities should be provide for the icon representing an external file to be defined by the user, when a user selects an icon representing an external file effects tool to apply with the type of file represented by the selected icon. Functional requirements services that the system should provide how the system should react to particular inputs and how the system should behave in particular situation. Describes the system service depend on the type of software expected users and the type of system where the software is used. Non-functional requirements constraints on the services or functions offered by the system such as timing constraints on the development process, requirement which specify that the delivered product must behave in a particular thing. Requirements which arise from factors which are external to the system and its development process. Domain requirements that come from the application domain of the system that reflect the characteristics of that domain, it may be functional requirements constraints on existing requirements define specific computations Model Based design requirement uncertainties in software development requirements continue to escalate development costs and frequently challenge product, software development is responsible for more than 80% of design delays and associated design complications whether the system is poorly conceived or crucial algorithms fail to address systems performance traditional methods of software development are yielding to process as model based design. Model based design emerged as a means of addressing the difficulties and complexities inherent in system design, developers recognized that software design needs to start before physical prototypes Volume 3, Issue 1 January February 2014 and system are available. Traditional design processes information is communicated and managed as text based documentation is difficult to comprehend, code is created manually from specification and requirements documents that are time consuming and error free tracking to ensure that changes are correctly implemented. Model based design works the entire system model is visualized through block diagram and state charts to describe knowledge and implementation details. Design options can be evaluated and systems performance predicted via simulation of the system model. Algorithm and behavioral model are optimized and refined yielding a fully tested specification. Production quality software is automatically created for real time testing and deployment from the fully tested specification. Model based design takes less time and providing final design that more closely approximate predesign expectations for performance system functionality and features and schedule provides faster design iterations that produce desired performance functionality and capabilities, design cycles that are more predictable and result in faster product shipments, reduction in design development and implementation costs.

SECTION VI 6. Anomaly Detection Application Requirement Analysis: Requirements management

is the time to get all the teammates customers and stakeholders gather to define the requirements for the system, they discuss on formal meetings and object discussion which is to be developed. Business analyst should lead an open meeting where all ideas are encouraged to draw out the customer requirements, customers are not always good at articulating their needs so it is important to play back understanding of the requirements to ensure clarity. Including use cases in the business requirements specification can be very useful for documenting business process and identifying different roles in the process. Requirements are written in the language of the user Confirm what the system will not do as well as it will do Include a section for non-functional requirements. Once we established a clear set of requirements the next step is to model a software solution, using a recognized notation can be useful at this stage and help the team create a clear and unambiguous software design document. Software development contains functional requirements and non-functional requirements to develop end-product. Suppose to develop Detection of Anomaly in Computer Networks is an application to identify intrusion in computer network data. User characteristics Page 35

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)

Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 3, Issue 1, January February 2014 ISSN 2278-6856
Analyzes and developing the classification of normal or anomalies in the Network Anomaly Data. Identifying the attacks in the computer system Analysis of the proposed system is to implemented in a human understandable and monitors the behavior of the system. Results Dataset selection: Analyst can select any of the dataset for analysis. K-Means: groups the dataset instances in order to find anomaly. ID3 : Classifies the cluster dataset which is normal or anomaly type. Results : Anomaly detection for network data are explained clearly. Communication interfaces As the system works with purely in Java Jdk1.6 with the user interface through the Perl language which does not involve in the proposed system. Product Function: K-means:

Developing Environment
Table 1 : Software Requirements Specifications for proposed system

Particulars Operating System Processor Hard Disk RAM

System Requirements Windows XP Pentium IV 160 GB 1 GB

Requirements Specification External Interface Requirements Overview of data requirements

Input: 1. Training data in the form of synthetic, real time records as an input. 2. Analyst is giving the datasets to group the clusters. 3. Type of dataset is given by the Analyst 4. k-means algorithms arrange the dataset if it is overlapping then sends the data to id3 decision tree 5. Automatically determines the anomaly instance from the proposed system Output: 1. First the training data is creates the clusters 2. Clusters are created using Euclidean distance 3. Each Cluster represents the percentage 4. k-means output is integrated with the id3 decision tree 5. identifies the normal or anomalies instances are determined by the proposed algorithm. Functional requirements It must utilize as much data provided in the k-means as possibly creates the type of clusters It should preferably be easily be adapted to any different new domains. The method discussed in the anomaly detection must be explainable in human understandable and meaningful Non-Functional requirements It must be scalable to handle network data that contain complex number of instance. It should support different levels of explanation. Interface requirements User interface Datasets that are under analysis for identifying the anomalies. K-Means ID3 decision tree Volume 3, Issue 1 January February 2014

Figure 3 Requirement for Anomaly K-means Cluster

ID3 Decision Tree:

Figure 4 Requirements for Anomaly Machine Learning

Deployment Diagram:

Figure 5: End Product Overview in Requirement Analysis Page 36

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)

Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 3, Issue 1, January February 2014 ISSN 2278-6856 CONCLUSION VII
In this paper, presents multiple page-level web data extraction, A framework Requirement Analysis for Anomaly Detection using Machine Learning, along with Requirement process some more tools specification mechanism shows resolves the issues in developers effort cost and schedule increases best performance in software lifecycle. Work analysis, how we gathering analyze monitor and documents in development to meet client satisfaction. Future work extends to investigate more analysis and services for real-time application with implementation research. Arvind Tudigani M.Tech (IT) from AAIDU, Allahabad, B. Tech(IT), JNTU,Hyderabad He is having 8+ years of experience in teaching currently working as Asst Prof for Osmania University Hyderabad has guided many UG & PG students. His research areas include Distributed Systems, Network Security, and Design Patterns.

Reference [1] Borgida A. and Greenspan S..J. (1980), "Data and Activities: Exploiting Hierarchies of Classes", in Proc of Workshop on data Abstraction, Databases and Conceptual Modelling, M. Brodie and S. Zilles (eds), Joint SIGART,SIGMOD, SIGPLAN Newsletter. [2] Conklin J. and Begeman M. (1988), "gIBIS, a Hypertext tool for exploratory policy discussion", in ACM Transaction on Office Information Systems, vol 6, pp303-331. Davis A.M. (1990), "Software Requirements, Analysis and Specifications", Englewood Cliffs, N.J., Prentice Hall. [3] Business goals to architecturally significant requirements for software systems Paul C May 2010 [4] Frank Carr with Kim Hurtado, Charles Lancaster, Charles Markert, and Paul Tucker, Partnering in Construction: A Practical Guide to Project Success James Herbsleb, Anita Carlton, James.

Thirupathi Marupaka pursuing M.Tech Computer Science Engineering from IETE B.E from Osmania University He is having 5 years of experience in teaching currently working as Asst Prof for Osmania University Hyderabad has guided many UG & PG students. His research areas include Distributed Systems, Network Security, and Design Patterns. Ch. Raju M.Tech Computer Science and Engineering from JNTUH MS.Is from Osmania University BCA from Osmania University. He is having 8+ years of experience in teaching currently working as Asst Prof for Osmania University Hyderabad has guided many UG & PG students. His research areas include Distributed Systems, Network Security, and Design Patterns.

Volume 3, Issue 1 January February 2014

Page 37