State of Art in Software Requirements Engineering - Report Example

Student Name: Instructor’s Name: Title: State of Art in Software Requirements Engineering: Critical Review of the state of the art Course: Institution: State of Art in Software Requirements Engineering: Critical Review of the state of the art Introduction For the success of any software system, its suitability to the users and the way it fits to the environment play an important role. This brings out the notion that every need has its requirements. Cheng and Atlee (2007) presented the software requirements as the needs while the process for the determination of the software requirements were presented as requirements engineering (RE). The orientation of this paper needs a further definition of requirements engineering. The definition by Zave (1994) gives some broad understanding of what RE entails. It was stated to be the branch of systems engineering that deals with real world goals for services provided by complex software –intensive system. The definition added that RE is concerned with the relationship of factors to their exact specifications of the behavior of the system and to their advancement over time and across families of systems. This definition finds favor because it highlights the significance of real-world goals that stimulate a software system’s development. They represent the ‘why’ and the ‘what’ of the system. In addition, it mentions the precise specifications which give the basis for analysis of requirements, validation of stakeholders’ needs, definition of the design and verification of what has been done. It goes ahead to emphasize the reality that the world changes and there is need for reuse of partial specifications like is done in other engineering branches. In this paper, a critical review of the state of art in software requirements engineering shall be presented. Some of the misconceptions about requirements engineering together with the advancements on requirements engineering will be brought out and discussed in the paper. Context and background From the definition above, the crude way of expressing what RE is would be to present what it focuses on. RE looks at the front end of the life cycle of the development of a system and focuses on its improvements. The needs that give rise to the process of development have to be established and the information organized in a form that supports the conception and implementation of the system. This would be put simply as the ‘why’ and the ‘how’ of the system. The operation of a system will be assessed in terms of its quality by how it is able to meet the requirements set by the stakeholders. It presents a difficult case in establishing how the requirements can be accurately determined and how to keep the focus throughout the process of development. The positive view would be on the importance of RE. The other negative view is from the perception of practitioners who always state that the difficulties they face during system development are traced back to the inadequacy of requirements engineering. It means that the requirements set are found not to fulfill the needs during development and they are therefore required to carry out correction of errors during development. This view purports that improvements should be done during development. Both of these views present one fact: requirements are important for the success of a system. The importance of the positive view is that it helps reduce the costs incurred during system development. For instance, the errors identified in the early stages of development are cheap to correct, so the negative view doesn’t have much criticism here. However, as the process gets more complex, the cost of removal of errors rapidly escalates and a point is reached where the removal of an identified error will become too costly to the whole process. In addition, these errors spread across components and locating them becomes difficult (Finkelstein, 1997). Challenges faced in requirements engineering Confusion may be created by the close relation between RE and software engineering. This is especially escalated by Zave’s definition of RE. But presenting it as a branch of systems engineering makes more sense. This is in accordance with Bashar and Easterbrook’s (2000) argument that software cannot operate in isolation from its embedded system and therefore RE has to include the view of systems level. But regardless of the view, RE is a multi-disciplinary process that is human-centered. Requirements engineering is not an entirely satisfying process. Some of the challenges as presented by Cheng and Atley (2007) are that the analysts usually begin with ill-defined and at times conflicting ideas on what the system will be designed to do, yet they are supposed to progress to a single and detailed specification of the system. Besides, the problem space of requirements is less constrained. This presents many options to be considered and decisions to be made on requirements. Having many options to choose from is a problem since it requires setting aside objective criteria of acceptance. The challenges get more complex in the process of constraining the environmental conditions that the system will operate under. This requires the reasoning about the behavior of the system and making assumptions about the environment. This gets complex since the system’s environment could be a combination of human factors, hardware and other software devices and the physical phenomena. Further, reasoning about the system’s environment requires more than the assumptions of the normal environmental behavior and needs an identification of possible hazards and threats posed by the environment to the system. Finally, one other important challenge is the need to maintain a balance between producing suitable descriptions for the non-computing audience and technical documents which are precise enough for developers at the downstream end. State of the art: Methodology Requirements elicitation The state of the art for requirements engineering dictates that certain tasks are carried out in the process of RE. Requirements elicitation is one of the tasks. It involves activities that facilitate the understanding of objectives, goals and motives for developing the proposed system. In this task, the requirements that the system has to satisfy are identified and they range from modifications to problems and systems that are well understood. This literature on the process of software maturity indicates that improvements in development of software are interlocking. However, there is no clear indication of the procedure in this task and in the words of Finkelstein (1997), it is assumed that the process is a standard “waterfall” process. Such a process would involve a clear mechanism that feeds the products of the RE process all through to design and management break points for control and measurement. In this regard therefore, requirements engineering is no better than other areas of systems and software engineering. Modeling The process would then be made clear in the modeling process. The specifications of a project are presented as models. These models appear to be more exact, complete and they lack ambiguity. This process evokes details which were missed during elicitation. In fact, the resulting models can serve to communicate the requirements of the system to downstream developers. Various techniques can be used in modeling and these include modeling strategies which give guidelines while structuring models. Gunter et al (2000) argued that modeling strategies like RE reference models decompose descriptions that are related to the requirements into the requirements of the stakeholders. They also establish the correctness criteria that can be used to verify that the system shall meet the requirements. When patterns are used in modeling, they encode the solutions which were otherwise generic into common modeling problems. Further, model transformations can be used to merge or manipulate the existing models so as to derive new models. These approaches may differ in the specifics but their broad outline I the same. They can therefore be considered among the most promising tasks in the wide area of RE. Gilb (2005) feels that the analysis of non-functional requirements as well as modeling has had significant changes made since the criteria on how best the eventual system will achieve the various non-functional properties has been made more objective. Analysis Requirements engineering requires that a requirements analysis is done to check for errors in requirements, incompleteness or inconsistency. Wasson (2006) stated that this task focuses on improved techniques that can be used to evaluate the quality of requirements that have been recorded. Any obstacles to the requirements satisfaction as well as any missing assumptions are brought up during this task. In essence, it entails validation of the products of products for the RE process, exploration of the requirements, verification that the products of the process of development reflects the requirements accurately as documented and inspection as a formal analysis for eliminating any errors. But these elements create issues in the process of analysis. First, validation is meant to be tied to the requirements production but at some point, organizational factors may intervene and prevent this. The validator faces a lot of information but has no clear guidance on how to proceed. This calls for methods to provide such guidance. Another issue arises during exploration difficulties are faced on what to include in the simulation, how much of the simulation will be carried to the final realization and how exploration can be guided and feedback organized. The verification process will essentially involve management of consistency meaning some inconsistency might be tolerated at some point while at times consistency is enforced. This presents challenges during verification. Finally, use of computer support and groupware during the inspection process deserves attention and further research can be done on these areas. Requirements management Requirements management is another task that has to be carried out in RE. The requirements have to be managed along with monitoring requirements’ evolution over time and through the product families. Tools and techniques are used to ease and partly automate the process of identification and documentation of traceability links among artifacts of requirements as well as between the requirements and downstream artifacts (Settimi et al, 2005). In addition, the analyses that will determine the stability and maturity of elicited requirements have to be included. Bush and Finkelstein (2003) stated that this will facilitate the isolation of requirements that are likely to change. It remains to be seen whether this process is a smooth one but according to Alspaugh and Ant´on (2001), the basic requirements management still poses a challenge on the techniques that can organize large requirements’ numbers which are globally distributed. Measurement Since requirements engineering is similar to other industrial processes, it is supposed to be predictable along with meeting scheduled commitments with reasonable consistency. Metrics can be used as a means for measuring the products and process of RE and a statistical control used to improve the process. However, this calls for an established RE process along with an approved set of products that are derived from the process. Use of metrics has not been extensively developed and it only focuses on simple metrics such as that in error detection rates. A wider variety of general purpose metrics has to be developed. This brings to the use of estimation which has often been used in development costs, schedule and effort. The estimates may be obtained from measurements and experience of development. The research on estimation cannot be placed high on the agenda of RE research. But RE products and processes have to be framed with a view to estimation. This calls for enhancing support for comprehensive collection of data in the methods and tools. Communication and documentation The importance of information management cannot be stressed more. The RE process involves production of large amounts of interconnected technical and information and documentation. These could be textual or graphical. This demonstrates the practical importance of the storage, retrieval and production of quality documentation. This area has not lagged behind since there have been considerable improvements in software support on this task largely based on improvements in database technology. Research in this area has recorded a broad thrust due to progress in software engineering repositories along with the associated issues on allotment and long transactions. The future could see use of videos and sound records for information management because presentation and extraction of information has exciting research issues. The recording rationale and argumentation should be process oriented and it should underpin the products of RE. Use of argumentation support in development of systems has rapidly proceeded even without a systematic assessment. This is because of the importance of the process but rectification should be done and a systematic assessment done to understand the advantages and disadvantages of the argumentation schemes before further advancement (Porter et al, 1994). Traceability This is the ability to track requirements life in a forward and backward approach during the development process. Forward traceability demonstrates how to manifest a requirement in a system and the intermediary system development products. On the other hand, backward traceability maintains the requirements’ integrity in during subsequent changes in design. Sutcliffe et al, 2006 purports that this area has seen an upsurge of interest in its research and most of the work focuses on the capability to connect fragments of text and to navigate the links. The issue raised in terms of pre-requirements traceability cannot be ignored. Most particularly, the problems that link the artifacts produced in requirements engineering to the groups and individuals that were involved in production are raised. Attention may be drawn to the interesting ideas of using constraint networks and truth maintenance. Standards and conformance Finkelstein A. (1997) stated that codes of practice and standards dictate how documentation of requirements and organization of processes should be done. The standards and guidelines in RE have check lists and prescribed layouts of documents. Since standards comprise least good practice, a gap exists between the suggestion by standard bodies and the actual state of the art. Standards have been seen to slip from the known in requirements engineering and this brings the notion that the standards process should be re-examined. Agreeing requirements During elicitation and modeling, maintaining agreement with stakeholders may be difficult especially whenever stakeholders have different goals. Since validation involves determining that the requirements and elicited models give an accurate account of requirements by the stakeholder, the requirements have to be explicitly described both for validation and resolving of conflicts among stakeholders. Bashar and Easterbrook (2000) argued that when requirements validation presents a lot of challenges in terms of the techniques to be used, it becomes essential to shift this problem of validating requirements to persuading stakeholders that the representation that has been chosen for requirements model is the appropriate one. Even so, maintaining an agreement with stakeholders gets difficult as elicitation and modeling of requirements takes place. If stakeholders don’t agree on the choice of a problem frame, then there will be a problem agreeing on the statement of requirements. According to Goguen and Linde (1993), some ethnomethodologists have tried to avoid the problem by not imposing modeling constructs on stakeholders. By resolving to embark on observations of stakeholders’ activities, and abandoning the traditional way of problem analysis tools, the issue of requirements validation is avoided. Recent approaches have tried to clarify the problem of stakeholders’ disagreement by explicitly modeling the goal hierarchy of stakeholders (Lamsweerde et al, 1998). Further developments in terms of requirements negotiation have called for resolving of conflicts without weakening the satisfaction of each stakeholder. It is such an approach that pushed Boehm et al (1995) to bring up the win-win approach where each stakeholder’s conditions are identified and the process managed and measured to ensure that all win conditions are fulfilled via stakeholder negotiation. Essentially, the theory underlying the negotiation models is similar in each case: the goals for each stakeholder are identified and met. The approach is not unique since it has been applied in other RE techniques to ensure agreement and not explicit the goals. This can be illustrated in the way matrices for Quality Function Deployment are constructed in a way as to compare the functional requirements with each other and rate their significance without explicitly identifying the goals of stakeholders (Karlsson and Ryan, 1997). Conclusion Requirements engineering has made an important progress across many fronts. Nevertheless, there is increasing demand on computing and cyber infrastructure has dramatically increased, in effect, raising a lot of critical questions on requirements engineering research. The many technologies that might bring an end to some of the problems could cause paradigm shifts which will impact on future generations of computing systems and developers and in the long run the consumers who are the stakeholders. It is however important that the technologies are adopted so as to facilitate development of systems. Bibliography Alspaugh T. A. and Ant´on A. I., 2001. Scenario networks for software specification and scenario management. Technical Report TR-2001-12, North Carolina State University at Raleigh. Bashar Nuseibeh and Easterbrook Steve, 2000, Requirements Engineering: A Roadmap, Ontario, Canada. Bush D. and Finkelstein A., 2003, Requirements stability assessment using scenarios. In Proc. of the IEEE Int. Req. Eng. Conf. (RE), pages 23–32. Cheng H. C. Betty and Atlee M. Joanne, 2007, Research Directions in Requirements Engineering: Future of Software Engineering, IEEE, Computer Society, Washington DC. Finkelstein Anthony, 1997, Requirements Engineering: A Review and Research Agenda, City University, Department of Computer Science, London. Gilb, T., 2005, Competitive Engineering: A Handbook for System Engineering, Requirements Engineering, and Software Engineering using Planguage. Butterworth-Heinemann. Gunter et al, 2000, A reference model for requirements and specifications. IEEE Soft., 17(3):37 43. Settimi et al, 2005, Goal-centric traceability for managing non-functional requirements. In Proc. of the IEEE Int. Conf. on Soft. Eng. (ICSE), pages 362–371. Sutcliffe eta l, 2003, Evolutionary requirements analysis. In Proc. of the IEEE Int. Req. Eng. Conf. (RE), pages 264–273. Zave, P. (1994); Call for Papers and Associated Classification Scheme; IEEE International Symposium on Requirements Engineering 1995. Read More