Software Engineering and HCI - Essay Example

?Running Head: Software Engineering and Software Engineering and HCI The Greenwich School of Management of Submission Software Engineering and HCI Introduction Analysing requirements at the business, corporate, technical and other functional spheres in a systematic way is the essence of requirements engineering. In more general language, it can be referred to as requirements specification, requirements capture or requirements gathering. An engineering discipline should be based on certain basic definitions, and requirements engineering is no exception to this rule. Hence, first of all, definition for requirements engineering is necessary. According to Laplante (2007, p.44), this field of study is actually “a subdiscipline of systems engineering and software engineering that is concerned with determining the goals, functions, and constraints of hardware and software systems.” Almost the same idea has been elaborated in the definition rendered by Zave (1997, p.315). This definition states, “Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families.” In this definition, by including the term “software families”, Zave (1997, p.315) covers the sector of component level hardware as well which is essentially based on software like driver and .dll file functions. Contextually, it can be mentioned that hardware systems are rendered purposeless if not the hardware specific software, especially the system software, is properly designed and installed. This paper is aimed at an evaluative analysis of a given statement, but the initial review of technological literature to begin with sets a very favourable and meaningful background for the statement under scrutiny. Synchronising the most reliable and recent literature, the framework of a definitive theoretical integration of the very techniques and purposes of requirements engineering appears to be ideally set in Reifer’s perspective of the subject. Statement to Evaluate “Requirements engineering is the systematic use of proven principles, techniques, languages, and tools for the cost effective analysis, documentation, and on-going evolution of user needs and the specification of the external behavior of a system to satisfy those user needs. Notice that like all engineering disciplines, requirements engineering is not conducted in a sporadic, random or otherwise haphazard fashion, but instead is the systematic use of proven approaches.” (Reifer, 2006) Background This paper is primarily based on a relevant selection of sources and literature that were published after 1995. However, in providing comprehensive background information of this field, an earlier reference appears to be very contextual. In finding out the characteristics of the inception phase of requirements engineering, we have to trace back as early as 1980. According to Lehman (1980), as stated in the proceedings of IEEE, introduction of some newly designed computer system alters the features of the job done within an organisation, affects the communication, structure and synchronisation inside that organisation and tends to transform the very organisational needs altogether (Lehman 1980). The 1990’s saw a number of vital and far-reaching shifts in the understanding of requirements engineering. By the early 1990’s, requirements engineering had come out as a field of learning in its own right, as observed by the surfacing of two series of global meetings – the conference and symposium sponsored by IEEE – and the establishment of an international level academic journal available from the Springer. By the late 1990’s, this field had grown adequately to hold up a large number of supplementary smaller workshops and meetings in different countries under the auspices of different organisations. (Nuseibeh and Easterbrook, 2000) The purpose of requirements engineering is based on analysing, and once feasible, implementing better and cost effective software solutions for ensuring better (or perhaps the best) organisational functionality. The theoretical and practical aspects of this subject draw in the ideas of cognitive and social sciences as well. Cognitive psychology helps to understand the difficulties faced by the stakeholders in expressing their views, anthropology helps to understand human activity patterns, sociology provides a comprehension of the socio-economic, political and cultural aspects of computerisation and linguistics is essential for communication, explanation and documentation in regards of the organisation’s and the stakeholders’ needs. Moreover, strong philosophical grounding can be achieved by applying epistemology, phenomenology and ontology in the course of the communication and documentation processes involving requirements validation and related belief systems. (Nuseibeh and Easterbrook, 2000) Thus, requirements engineering must have an inter-disciplinary span which is in furtherance to the evolution of more complex but efficient computer systems. Software cannot work in separation from the system in which it is installed and hence requirements engineering must encompass a systems level perspective too. The “ultimate goal is to deliver some systems behaviour” (Nuseibeh and Easterbrook, 2000, p.36) to the stakeholders and the organisation involved to optimise and economise cumulative performance. Exploration and Synthesis Requirements engineering applies a diverse selection of multidisciplinary tools and techniques at the various developmental stages and application domains of a computer system development and/or enhancement project. This is impossible if the activities are conducted in a sporadic, random or otherwise haphazard fashion, as has been pointed out by Reifer (2006). Application of proven principles and techniques would lead to systematic combination of the diverse perspectives and notations. Further exploration of meta-modelling and method engineering (Brinkkemper and Jooster, 1996) along with the rapidly evolving functional requirements like security, portability, manoeuvrability, manageability, etc. in the context of software and information engineering (Chung et al, 2000) can bring about excellent futuristic changes. How the Business Needs Determine System Design? Business is basically driven by needs. For example, continuous maximisation of profits is rather a critical need than an ambitious goal. Today’s field of business development, management and organisation is embedded in a global economic environment. Hence, a few distinct business needs can be enumerated as the following: Applied cognitive psychology for greater inter cultural communication and trade Greater and faster geographical access and transfer of information Greater security as cyber attacks are increasing Transparent accounting practices which can still protect the core business areas and secrets from the rivals Control on information flow In modern business, there are hundreds of diverse and almost completely mutually exclusive requirements similar to the once mentioned above. Now if there are no organised ways for the synchronisation of business needs and system design, the global superstructure of the information management system and arrangement will rapidly and completely collapse. “Software requirements engineering is a disciplined, process-oriented approach to the definition, documentation, and maintenance of software requirements throughout the software development life cycle.” (Westfall, 2006). Therefore, to understand that how business needs determine system design, software requirements engineering itself has to be examined. “Software requirements engineering is made up of two major processes: requirements development and requirements management. Requirements development encompasses all of the activities involved in eliciting, analyzing, specifying, and validating the requirements.” (Westfall, 2006) Figure – 1: Requirements Engineering Process Source: Westfall, 20061 Majority of the business needs involve building perfect products. Therefore, it sets the goal of avoiding the creation and production of irrelevant and wrong products. This reasoning provides the basic logic of finding out product and process specific requirements which are used to construct the system design and related algorithms. The customer is dissatisfied2 if his or her specific requirements are not met. When enough of the specific requirements are properly met, the customer, or the stakeholder, is satisfied. Generally, a basic level of quality requirements is expected in the product by the customers. Thus, customer satisfaction and related market research become the driving forces of product design. The software application for developing product design is a part of the business level systems design. Quality control should be another major determining factor in this milieu, since exciting quality is the innovative requirements stage and helps in manufacturing unexpected but impressive items that can revolutionise the market altogether and increase the business turnover. (Westfall, 2006) User requirements based elicitation and analyses examine the functionality of the software application from the users’ viewpoint. The software should do certain things and should not do certain other things so that the user can work with it comfortably and meet his or her business and job objectives. Multiplicity of user-level needs cannot be neglected in determining a business need. Therefore, in other words, business needs would determine the systems design by the means of putting forward parameters translating into multiple user requirements. Figure – 2: Levels and Types of Requirements Source: Westfall, 20063 A part of the statement under evaluation puts forward that the requirements engineering is based on “cost effective analysis, documentation, and on-going evolution of user needs and the specification of the external behavior of a system” which would generate more satisfaction among the stakeholders involved. Hence, we get a fair idea of how business needs become the major determinants in software engineering and development. To conclude this section of the paper, it should be states, “The tools and techniques used in RE draw upon a variety of disciplines, and the requirements engineer may be expected to master skills from a number of different disciplines.” (Nuseibeh and Easterbrook, 2000, p.36). Notably, contemporary business is also an interdisciplinary process involving diverse but synchronised management. This makes the business needs more critical. Components of Quality Systems Development of the new methods and techniques for analysing and modelling the properties of the prospective software environment is very important and rife among the contemporary practitioners. “Such techniques must take into account the need to deal with inconsistent, incomplete, and evolving models. We expect such approaches will better support areas where RE (requirements engineering) has been weak in the past, including the specification of the expectations that a software component has of its environment. This facilitates migration of software components to different software and hardware environments, and the adaptation of products into product families.” (Nuseibeh and Easterbrook, 2000, p.43) The most important component needed at the beginning of system design is an authentic and reusable documentation. At the level of documentation, regulations, laws and industry standards should be fully applied. Product literature should be ready and to the point. Work instructions and help-desk reports must be integrated. An “ease of learning requirement” (Westfall, 2006) must be provided to the stakeholder. Quality attribute must specify the features the software must have to meet the stakeholder purposes and expectations. Thus, the component of quality control is crucial and should be fully operational during run time. The software must be synchronised with the external interface. The component of external interface mainly rivets the following elements: Hardware (card and component level) Associated software applications like drivers, firewalls, spam guards, etc. Human agency (i.e., user intervention and interaction) Information flow patterns and systems Moreover, some requirements may state that “the completed software use no more than 50 percent of available system memory or disk space” (Westfall, 2006) so that scope of future upgrades and speed can be maintained. Thus, the component of data management (which engross memory and storage issues) becomes a critical functional element. Finally, the software may be part of a much larger system that includes other components involving the greater dimensions of information management. The component of system architecture is therefore a major determinant of the quality of a system design and implementation program and outcomes thereof. (Westfall, 2006) Conclusion The available definitions about requirements engineering as put forward by Zave (1997) and Laplante (2007) provide considerable insight to the subject and help to develop a holistic and coherent approach, despite the fact that these definitions were published at a gap of ten years. Actually, until of late, the developments in requirements engineering have been slow at the industry level although scholastic activities were rather inntense. However, the statement by Reifer (2006) can be evaluated as a very appropriate note on the practical aspects of this complicated discipline of study covered under high level software engineering. Professionals in this field should understand the diverse levels and classes of requirements to execute a good job. It requires a comprehension of the advantages of having the relevant requirements defined lucidly. This would facilitate proper resource allocation, funding, prioritisation and integration regarding the software application under development and deployment. “RE is often treated as a time-consuming, bureaucratic and contractual process. This attitude is changing as RE is increasingly recognised as a critically important activity in any systems engineering process. The novelty of many software applications, the speed with which they need to be developed, and the degree to which they are expected to change, all play a role in determining how the systems development process should be conducted.” (Nuseibeh and Easterbrook, 2000, p.42) Issues for Further Exploration Requirements engineering will play an important role in determining the quality of the future systems. Research based on statistical correlation and evidence regarding industry experience should be conducted to popularise requirements engineering among the future decision makers. The issue of determining the discrete chronological stages entailed in a requirements engineering program should also be solved, since the stage of system modelling (Holzmann, 1997) remains an area of debate. Use of multiple languages is also a very crucial issue because the requirements elicitation needs a lot of surveys, feedbacks, interviews, etc. among the professionals and stakeholders from the different parts of the world. For example, software user manuals are generally available in English and other European languages, although India and China are the major growth engines of the present day world economy. Hence, linguistic skills should be given high importance and new languages should be welcome in the realm of requirements development. Reference List Brinkkemper, S. & Joosten, S. (1996). ‘Editorial: Method Engineering and Meta-modelling.’ Information and Software Technology, Vol. 38, No. 4, pp. 250-278. Chung, L., Nixon, B., Yu, E. & Mylopoulos, J. (2000). Non-Functional Requirements in Software Engineering. Boston: Kluwer Academic Publishers. Holzmann, G. J. (1997). ‘The Model Checker Spin.’ Transactions on Software Engineering, Vol. 23, No. 5, pp. 279-295. Lehman, M. M. (1980). ‘Programs, Life Cycles, and Laws of Software Evolution.’ Proceedings of the IEEE, Vol. 68, No. 9, pp. 1060-1076. Nuseibah, B. and Easterbrook, S. (2000). Requirements engineering: a roadmap. Proceedings of the Conference on the Future of Software Engineering (ICSE ‘00). Limerick, Ireland, 4-11June 2000, pp. 35-46. Reifer, D. J. (2006). Software Management. West Sussex: Wiley. Wiegers, K. E. (2003). Software Requirements. Redmond: Microsoft Press. Westfall, L. (2006). Software Requirements Engineering: What, Why, Who, When, and How. Available: http://www.westfallteam.com/Papers/The_What_Why_Who_When_and_How_Of_Software_Requirements.pdf. Last accessed 17 July, 2011. Zave, P. (1997). Classification of Research Efforts in Requirements Engineering. ACM Computing Surveys, Vol. 29, No. 4, pp. 315-321. Read More