An Automated Requirements Traceability: Managing Evolving Requirements Using Ontology-based Approach

A Computer Software Engineer develops software systems to be used by their clients, such as a website used to sell the client’s products. Although software engineers spend the majority of their time programming and testing the software, a key component to the success of a software engineer is the ability to write a thorough Software Requirement Specification (SRS). A SRS documents the requirements and dependencies needed for the software, prior to beginning any programming. Therefore, a Software Engineer must po The SRS is so important because engineers can have a wide scope of clients that they regularly work with.

Redesigning the software development process in an effective way helps in solving many problems. Upon asking question about when exactly the redesign is needed, it is quite obvious that in certain conditions where the involvement by the team and the management is sincere yet the difficulties exist and continue to increase even after a good effort on the particular problem. This has been the same situation in the Jharna Software where the company is privileged with good staff yet they face the problem in the integration stage and also they face difficulty with the suggestions or the changes by the customer on their requirement at later stages.

A: In the software lifecycle there are 4 phases that are derived from the old System Development Life Cycle (SDLC) and they are as follow; Planning, Implementation, Maintenance, and the Removal process. The planning phase is defined by all planning activities including the analysis of the software to be installed, verification of its compatibility, supported methods of installations, and the identification of any risks associated with the software and the desired deployment method. The Implementation phase is used to prepare for deployment such as; creating a shared access location for files and creating or using the appropriate package files. After all these steps have been

This is an issue for current processes because there are often incomplete system requirements at the start of development and because requirements may change and the process is not set up to adapt to late-breaking changes.

As the world became more and more dependent on technology with each passing day, software automatically became an important organ for development. Since software is needed almost everywhere today, its development is a highly intelligent and precise process, involving various steps. Known as software development life cycle, these steps include planning, analysis, design, development & implementation, testing and maintenance. These steps go on to create the perfect software for clients. ”

Analyze user needs and develop user requirements and convert the requirements to required functionality. ("Systems development life,”)

In addition, defining requirements can be difficult and sometimes early assumptions are flawed. Some opponents of Waterfall argue that it is impossible to fully understand the system requirements until the development phase and that some performance issues cannot be predicted or are not evident until the testing phase. Waterfall is not well-suited for custom software projects that rely heavily on continuous customer feedback and changing needs because communication and collaboration is not always stressed; once the requirements are established, the customer may have little contact with the development team until delivery. (Chatterjee, 2010) Because Waterfall projects are not based upon small iterations that can be easily and promptly modified, occasionally critical errors are found in the late stages of a Waterfall software development project that require scrapping the project and starting over; a very costly and disappointing result. Another negative is that some programmers believe that Waterfall is out-of-date and that it does not accommodate for the unknown factors that are a constant challenge in designing leading edge technology. Developers who abide by

Current challenge resolutions with the company and software architecture department demand a sketch of the outlined requirements, software processes, technology changes, professional processes, and management influence. To identify current trends and exercising solutions that maximize a scalable platform. By establishing a solid foundation that will result in

Dealing with an increasingly volatile organizational environment is a serious challenge for managers of any software development project [11]. Traditional formal software development methodologies can be characterized as reflecting linear, sequential processes, and the related management approaches can be effective in developing software with stable, known, consistent requirements. Yet most real-world

Andrew Kannenberg and Dr. Hossein Saiedian have explore some problems with manual traceability [14]. Traceability information can be captured manually through utilizing techniques such as traceability matrices. A traceability matrix can be defined as “a table that illustrates logical links between individual functional requirements and other system artifacts” [15]. Unfortunately, manual traceability methods are not suitable for the needs of the software engineering industry. In [17], the authors found that the number of traceability links that need to be captured grows exponentially with the size and complexity of the software system. This means that manual traceability data for large software projects requires an extreme amount of time and effort. If any change occur to any elements then the affected portions of the traceability data must be updated manually, which requires discipline and a significant amount of time and effort spent on link-checking throughout the traceability data. Because of this, it is easy for manually created traceability data to become out-of-sync with the current set of requirements, design, code, and test cases. Manual traceability methods are also prone to errors that are not easy to catch. Errors can arise from simple typographic mistakes, from inadvertently overlooking a portion of the traceability data (such as an individual requirement), or from carelessness by the individual capturing the data. Because traceability artifacts for large

In the software industry, it is common place to find large and very complex software system development projects with the number of individual requirements expected from it running into the multitude of thousand many times. There are usually more requirements than you can implement in the allocated stakeholder’s time and resources. The software solution that the customer has in mind and wants to be in place cannot be delivered in a single release. Even if it could be done, it would be a very costly affair which would eat away a lot of time and pose greater risks due to the nature of the ‘big bang’ approach one has to follow to implement it. Further, there will also be restrictions in the form of capital and time from the stakeholder or

Requirements elicitation is an important process of requirements engineering. Different requirements elicitation methods have been proposed in literature to identify the need of the requirements of the software. For example, goal oriented requirements elicitation, group requirements elicitation process etc. Among various requirements elicitation methods, goal oriented requirements elicitation method is a promising method in which the need of the stakeholders are identified using goal models. In goal models, the high level objective of the stakeholders are decomposed and refined into sub-goal. These sub-goals are further refined and decomposed until the responsibility of the sub-goal is assigned to some stakeholder or software. After refining and decomposing the goals, we will get the set of requirements. Therefore, it is an important research issue that how to select and prioritize the requirements for the next release of software development. In real life application, several stakeholders participate in requirements elicitation and they may have different opinion for the same requirement. Therefore, the objective of our work would be to propose a method to elicit the attributed values of goal models under fuzzy environment.

So it is not realistic to expect no change in requirements while a system is being built. However uncontrolled changes play havoc with a system under development and have caused many project failures.

Five Methods for Identifying System Requirement and How They are Applied in any System Development Venture

Keeping in view the need of the requirements collection, the requirements management approach which was considered to this report development is “Change Driven Approach”. This particular approach has been chosen for this report keeping in mind the Academic support perspective which has been chosen for this project report. As the education sector is envisaging seamless integration of technology, and today the key stakeholders like Learners (Students) and also the tutors prefer online medium for education to increase the access to content and ease of learning from anywhere anytime. By using change driven approach, it shall be easy to gather the requirements from the key stakeholders in terms of academic support perspective and knowing the expectations. (Das)