History and Definition of Software Engineering Requirements - Research Paper Example

Requirement 1-Introduction to software engineering Classic Definition (1969) The establishment and implementation of sound engineering ideologies in order to get a hold on economically software that is dependable and works professionally on real machines (Kenneth, 1998). IEEE Definition (1993) The employment of a well-organized, discipline, scientific approach to the improvement, operation, and maintenance of software is the application of engineering to software. Figure below presents the software engineering main working scenario. This figure shows how software engineering uses the theories of computer science and user requirement analysis to solve the problem that have specified by the user. Fig # 1Software engineering working structure [source: sciencedirect.com] Software engineering is the function of a methodical, regimented, scientific approach to the improvement, process, and upholding of software. It includes methodology and calculations, frequently synchronized by a software development procedure, with the intention of humanizing the consistency and maintainability of software systems. The attempt is impose by the possible complexity of those systems that may hold millions of lines of code (Roger, 2001). The phrase software engineering was invented by F.L. Bauer and popularized by the 1968 NATO Software Engineering consultation that was planned by Brian Randell (Hans, 2002). The field of software engineering comprises information, tools, and techniques for (Donald, 1989): • Project/ Software requirements, • Project/software design, • Project/software construction, • Project/software testing, and • Project/software maintenance tasks. Software engineering is connected with computer science, task management, and systems engineering (Kenneth, 1998). In year 2004, the U. S. agency of Labor Statistics intended 760,840 software engineers grasping occupations in the U.S.; in the parallel time phase there were a number of 1.4 million practitioners functioning in the U.S. in all other engineering regulations mutually. Owing to its comparative innovation as a field of study, proper learning in software engineering is frequently taught as fraction of a computer science syllabus, and as a consequence the majority software engineers hold computer science degrees. The expression software engineer is employs incredibly liberally in the business world. Extremely a small number of the working software engineers in fact hold Engineering degrees from credited universities. Actually, according to the Association for Computing Machinery that is also known as ACM, the majority of the people presently working in the U.S. as professional engineers have degrees in computer discipline, not in software-engineering (Giunchiglia et al, 2001). History Software engineering has an extended developing history together with the tools that are used and the soft wares that are developed eventually. It appears probable that software engineering will carry on developing for a lot of decades to approach (Kenneth, 1998). In the 1940s the initial computer users wrote down machine code by hand. Initial tools, like that macro assemblers and interpreters were fashioned and extensively employed in the 1950s to build up efficiency and superiority, and the initial-generation optimizing compilers appeared. In the 1960s the next generation tools similar to optimizing compilers and checkers were being utilized to develop productivity and excellence. The idea of software engineering was extensively talked about. Initial huge scale projects profitable mainframes and traditional software for large industry. The important Conference on Software Engineering was held on 1968. In the 1970s joint software tools, like as UNIX, code repositories, create, and so on come out, with the minicomputers and the boost of petite business software. While the 1980s the PCs or Personal computers and individual workstations turned out to be wide-ranging also equal increase in customer software. The 1990s carried Object-oriented programming and supple procedures similar to Extreme programming increased mainstream receipt. Computer memory ability sky-rocketed and costs dropped radically. These novel technologies permitted software to grow additional multifaceted. The WWW and hand-held personal computers prepared software yet additional extensively accessible. While the 2000s supervised code came out Java, Ruby, Python .NET, and PHP made writing software simpler than ever earlier. Offshore outsourcing altered the environment and centered of software engineering careers. In relation to half of all practitioners nowadays have computer science degrees. A little, but rising, number of professionals has software engineering degrees. In 1987 Imperial College London brought in the initial three year software engineering Bachelor's degree in the United Kingdom and the world, in the next year the University of Sheffield recognized a alike programmer. In 1996, Rochester Institute of Technology recognized the initial software engineering Bachelor's degree plan in the US, though, it did not get ABET pending 2003, the similar circumstance as Clarkson University, Milwaukee School of Engineering and Mississippi State University. Software engineering student degrees have been recognized at a lot of institutions of higher education. A standard international set of courses for undergraduate software engineering degrees was newly distinct by the CCSE. The initial software engineering Master's degree was recognized at Seattle University in 1979. As then graduate software engineering degrees have been readily obtainable from a lot of additional universities. 2-History of Requirement and some of privies researches have token about Requirement. The term software Requirements has emerged since from the set up of the software engineering that was first appeared in the late 1950s and early 1960s. The requirements become the most basic component of any software engineering process. Our software engineering project starts only if we have proper requirements to implement. So the basic born of the term of software Requirement has started since the emergence of software engineering. In the table below I have presented few important events in the history of software engineering field (Giunchiglia et al, 2001). Year Activity `1966 Bridgestone Tire Corporation uses a "process assurance items for the software Requirements Engineering 1967 Akoa writes about Quality Function Deployment for Requirements Engineering 1972 Mitsubishi's heavy Industries Kobe Shipyard uses a "quality chart" for the software Requirements Engineering (House of Quality) 1978 Toyota Auto body uses QFD for software Requirements Engineering 1983 First software Requirements Engineering Seminar in Japan 1990's American automotive industry adopts QFD for the software Requirements Engineering 1996 Survey indicates that software Requirements Engineering QFD is used more in the US than in Japan, based on a survey of companies that participated in QFD seminars and conferences Above I have talked about the software Requirements Engineering field history regarding main incorporation of some quality standards in it. That makes this field more valuable. 3-What is Requirement? In this section I will explain what requirements are why we need them, what are the types of user requirements. In software, we often talk about functional, non functional requirements, user requirements and system requirements. The typical process by which requirements are defined on large projects has not changed for several years. Teams of analysts and subject matter experts define functional requirements. Misunderstandings and divergence between requirements and the first delivery of a product can occur with off shoring when requirements are specified using natural language (Willcocks et al, 1994). Architects and other experts define non-functional requirements, often at different locations, different in different countries. In addition the media of the deliverables differ strongly for each activity in the requirements engineering processes (Dardenne et al, 1999). Now I will present the different requirements collection techniques where I will try to present more usually used methods of requirements gathering. Data Collection Systems Stakeholder interviews: Stakeholder interviews are a universal employed in requirement analysis.These interviews might come across requirements not taken in the past as being inside the scope of the scheme, and requirements may be contradictory. But, every stakeholder will have a thought of their vision will have visualized their requirements and want the way how they want to implement them (Kenneth, 1998). Population Census For the construction of some big production that can be used on a huge level then in that case we have to conduct the population census. Information at dissimilar levels of desegregation inside the country or areas; It is also called the Descriptive statistics of housing stock; Here we need to required services succor as software: and Employment patterns. Household Surveys The pointer to be deliberate, a review that aspires to determine nationwide averages of profits will necessitate a better example than a survey designed to gauge the proportion of the population with requirements relatives. The stage at which data is needed; formative the software association rate will necessitate fewer households to be interviewed than influential a regional or quarter rate. The population, Household reviews are a enormous deal slighter than a population survey and therefore as well fewer costly. We design the survey test to distribute at different homes to acquire the requirements. But in software requirements we have don’t have such condition so we can design the survey for the user to access the requirements. Employment Surveys Micro enterprise and other casual activity that might be important in a lot of economies Household production or wages paid incompletely in kind, which are mainly important in rural areas changes in household net worth used to stabilize consumption; and intra-family transfers. Here we use survey to bring together the data if the accessed the requirements can be implemented so that the staff can implement those requirements. Qualitative and Participatory Poverty Analyses Involve policymakers in the near the beginning planning of PPA. Carry key policymakers to the ground to participate in PPA research. Following the cost are presented, gather workshops with policymakers and limited people. Negotiate high-level commitment to the go after up PPA and observe the implementation of key commendations Open questioners We can also make use of this practice to acquire the detailed requirements regarding the developments of software. We can write the questioner and agree to the user to sketch or write his ideas to help in the development of the product. Analysis We can make use of this technique to have the detailed requirement for the development. This is a natural way in which we can present the prototype to extract the requirements from the user. Prototype analysis We can make use of this practice to extract the requirements from the user, we can use and sketched of initial working GUI to get the working or design requirements from the user. Kinds of Requirement In software engineering, it is traditional to distinguish between two kinds of requirements: functional requirements (FR) and non-functional requirements (NFR). A FR shall be defined as the requirement from an object to acknowledge a message and respond to it by varying its state and/or outputting an appropriate output message. This definition applies at all levels of system decomposition (Roger, 2001). Requirements analysis consists of refining a given set of requirements by determining lower-level requirements and artifacts needed to realize the given requirements (Maiden, et al, 2004). The Rational Unified Process (RUP), which is widely known and used in industry, will be referred to in this paper as a representative process of object oriented analysis and design (OOAD). A fundamental action defined in the RUP is use-case analysis, which consists primarily of drawing up collaboration diagrams, provides a means of refining FRs but not NFRs. This is mainly due to the fact that NFRs may sometimes be realized by lower level FRs. But this will not be discovered if the collaboration diagrams drawn in use-case analysis only show objects and messages needed to realize FRs (Vickers, 2007). User Requirement Let’s start with simple definitions. A good user requirement comes from a user or other type of stakeholder and expresses a property of the domain or organizational process that is the introduction of a new system bring about. Consider the following simplified user requirements on a work-based learning system that I recently specified: UR1: A user of the work-based learning system should be able to trace the person who is in charge for a document (Vickers, 2007). UR2: A user of the work-based learning system would be able to control the volume of information that the system presents to the user during learning. Both requirements are on the user rather than the system users would be able to trace a person and control the volume of information. Of course, how users do this either with the assistance of new software features or by only asking a colleague next to them—isn’t relevant here. Functional Requirement The existing definitions follow two threads that correspond to a great scope. In the first thread, the prominence is on functions: a functional requirement specifies a function that a system must be capable to perform, what the product must do, what the system should do. The second thread emphasizes behavior: functional requirements describe the behavioral aspects of a system behavioral requirements are those requirements that specify the inputs (stimuli) to the system, the outputs (responses) from the system, and behavioral relationships between them; also called functional or operational requirements that is a statement of a piece of required functionality or a behavior that a system will exhibit under specific conditions and a requirement that specifies an action that a system must be able to perform, without considering physical constraints; a requirement that specifies input/output behavior of a system (Mylopoulos et al, 2003). Functional Requirements Checklist: Are the requirements comprehensive? Are all the requirements exclusively identifiable? Are the requirements obviously and suitably prioritized? Are the requirements consistent? ( no internal contradictions) Does the set of supplies adequately address all suitable exception conditions? Does the set of necessities sufficiently addresses boundary conditions? Are the requirements possible? Can the necessities be implemented inside known constraints? Are the requirements enough? Are inverse requirements explicitly avowed? Are these the simplest set of requirements that gathered the stake-holder's needs? Are all the cross-references to other requirements correct? Is each requirement testable/verifiable? Ensure that each requirement wants to be a answer in its place of being stake-holder's account. The requirements require to be in customer's language by means of customer's terminology. Non-Functional Requirements: Software development is driven, like any engineering doings by considerations of gain versus investment, which in the commercial setting means profits. Nonfunctional requirements such as response time and resource usage impact openly on measures such as productivity and cost. Ultimately, it is these quantitative measures that conclude the justification for investment in a software development project. In view of this reality it is surprising that non-functional requirements are often ignored in the analysis process (Vickers, 2007). Let’s talk about non-functional requirements. Although this term has been in use for more than two decades, there is still no compromise about the nature of non-functional requirements and how to document them in requirements specifications (Giunchiglia et al, 2001). In every current requirements classification we find a distinction between requirements concerning the functionality of a system and other requirements. Non-functional requirements: The IEEE standard 830-1998 on Software Requirements Specifications sub-classifies non-functional requirements into external interface requirements, performance requirements, attributes and design constraints, where the attributes are a set of qualities such as reliability, availability, security, etc. The IEEE Standard Glossary of Software Engineering Terminology distinguishes functional requirements on the one hand and design requirements, implementation requirements, interface requirements, performance requirements, and physical requirements on the other. It uses a sub-classification into product requirements, organizational requirements and external requirements (IEEE, 2008). More classification problems arise due to mixing three concepts that should better be separated. These are the concepts of kind (should a given requirement considerd as a function, a quality, a constraint, etc.), representation, and satisfaction (hard vs. soft requirements) (Mylopoulos et al, 2003). There is only one semantic difference that may take place between the different definitions: timing requirements may be viewed as behavioral, while they are not functional. On the other hand, mostly publications in RE believes timing requirements to be performance requirements which in turn are categorized as non-functional requirements. On the other hand, there is no such consensus for non-functional requirements (Dardenne et al, 1999). Scenarios have been useful to the analysis of nonfunctional requirements (NFRs) by means of dependency tables to assess the relationships between different NFRs and by modeling the dependencies between goals (representing functional requirements and nonfunctional requirements, also called soft goals) and the agents and responsibilities that achieve them in the language. The satisfying or implementation of soft goals (i.e., NFRs) by functional requirements is assessed by inspecting strategic dependency and rationale models that illustrate goals, agents, tasks, and dependency relationships. Although supported tools provide limited reasoning support for assessing dependencies, many validations still requires human proficiency. The TROPOS language supports more formal reasoning about models; however, it does not explicitly assess nonfunctional requirements (Vickers, 2007). Non-Functional Requirements Checklist: Performance Performance requirements of the application supplies; throughput necessities, data quantity requirements (input, stored, output), Peak or short term freight requirements Platform It holds up which Operating systems, prerequisite software and hardware necessities. Licensing Licensing system of the product and additional OEM/external certifies necessities. Internationalization What locales/languages is this software parting to be developed for at the present and in the future? Integration requirements How do you desire third party applications to put mutually with your application to set aside more practice scenarios and sales firm opportunities? How do you wish for to put together with third party applications for the same benefits. Setup How should the make it to be deployed? You must think install, uninstall, restore and get better situations. Security What is the safety and security model for your application? think about authentication, approval and confined data transfer. You have to consider together application and platform (windows) safety. Configurations Are the Supported Configurations particular? Are the Compatibility requirements scrupulous? Usability Are the usability requirements particular? Are sense requirements specific? Operational Is any operational constraint or rations specified? (The user should be able to work the system by means of ski gloves etc). Reliability Are the dependability requirements particular? Are the accessibility rations specified? Are the serviceability rations specified? Are the strength requirements specified? System Requirement In contrast, a good system requirement expresses a desirable system property that, when implemented in the domain or business process, will lead (we hope) to the accomplishment of at least one user requirement. Here are two system requirements on the same work-based learning system: SR1: The work-based learning system would retrieve the name and contact details of a person in charge for a chosen document. SR2: The work-based learning system would allow the user to hide information that the system presents to the user. Each, if satisfied, provides one means by which the corresponding user requirements can be satisfied. So where’s the problem? The definitions of user requirements and system requirements are clear and distinct. We’ve got the requirements Perhaps the most serious thing that goes wrong is, when projects initiate, people speedily forget the differences between the two requirements types. User requirements and system requirements swiftly happen to the requirements. One reason for this is project pressure. Projects often lack the resources and time to treat the two types differently. Another reason is what I call requirements shock. People in projects are sometimes, so shocked to see any set of well written requirements that they just run with them. They attribute all manner of roles to these requirements, even if the requirements were specified for different roles (Willcocks et al, 1994). Mixing user and system requirements can lead to many kinds of problems. Okay, you can declare that your project has one place of requirements, but in certainty you’re just changing the nature of the problems that you still need to overcome. 3- Here in this section I will discuss the Feasibility study , Collect Requirement Analyses Requirement The feasibility study point is the first stage of the system development life cycle. It is aimed at providing early exposure to the costs, benefits, and risks of the proposed project, as well as good estimates on the efforts required for follow-up project development (Kenneth, 1998). For decision systems, the feasibility study part is more than ever critical and intricate, as the value of decision systems often hinges on subtle, intangible benefits that are potentially powerful but which may also be come with by a substantial amount of risk (Kenneth, 1998). At the Information Technology Institute in Singapore, their mission is to provide services in the inventive exercise of information technology in market. As a part of this mission, one of their key functions is to assist user organizations in the conducting the feasibility studies. In particular, they strongly advocate the feasibility study stage for operations management domains, in which decision processes are both central and often highly complex (Dardenne et al, 1999). The objectives of the feasibility study phase are: to get hold of a detailed understanding of the problem domain; to perform a detailed technical feasibility assessment on systems for the domain; to carry out a detailed economic feasibility assessment on systems for the domain; to carry out a detailed environmental feasibility assessment on systems for the domain; and to produce recommendations on follow-up project development. The feasibility study structure supports all of these objectives. The framework comprises the following sequence of six components: (Dardenne et al, 1999) 1) Scoping; 2) Feasibility Study Proposal; 3) Carry out the Study; 4) Feasibility Assessment; 5) Study Reporting; 6) Project approval. The sequences of components 1-6 correspond to a logical and inclusive flow of activities in the conduct of the feasibility study phase. In the rest of this section, we outline the functions of each component. Scoping is an initial process of communication between the study team and the user organization. The aims of scoping are: (1) TO obtain a general understanding of the problem domain, (2) to obtain a preliminary assessment on the technical, economic, and environmental feasibility, (3) to define the scope, schedule, and resource requirements for the follow-up feasibility study, and (4) to set up lines of communication with users for the study. Scoping typical consists of two informal, half-day sessions with users. No commitments to the project are made by the study team or the users during scoping. Should scoping determine that the feasibility study proper is deemed necessary, a feasibility study proposal is prepared and submitted to the user management. The conduct of the study involves the organization of activities that together cover the scope of the study. Activities include knowledge acquisition sessions held with users, as well as brainstorming sessions which are in part held with users and in part held inside to the study team, for the function of feasibility assessment and drawing up the recommendations. Feasibility assessment is the central part of the study and is thus given extraordinary emphasis in the framework. The study results in the generation of a wide-ranging report on findings in the domain understanding, feasibility assessment, and recommendation aspects. Presentations to the user management on the findings are made once the report is ready (Mylopoulos et al, 2003). Project acceptance is a phase internal to the study consultant that is carried out to determine the possibilities and attractiveness of continued connection with the user organization into the development phase. It is a kind of feasibility assessment in itself, except that the beneficiary of this assessment is the consultant, rather than the user organization. A set of project acceptance criteria is provided in the structure. The criteria include such factors as whether the project is within the research focus and long-term directions of the consultant, whether the consultant has available the resources and capabilities to carry out the project, and whether the user organization has demonstrated obligation and provided the compulsory infrastructure for the project to be carried out. The researchers do not think about the data gathered during feasibility study of the project. During feasibility study, project managers, CEOs, and concerned will take part in discussions with stakeholders to assess the project practicability. In all these feasibility studies several issues would be discussed: Identification of document, description of current situation, problem description, business and financial aspects, technical aspects and organizational aspects of proposed development, development costs and operational costs, envisaged benefits and recommendation. These technical factors gathered during feasibility study are not accounted for calculating concert in early SDLC. These technical factors can be realized only during detailed design or deployment of software systems. In all the works done in untimely phases, the authors have not considered the technical factors that are important for early prediction (Dardenne et al, 1999). Why we collect the Collect Requirement and Analyses Requirement during the feasibility study. The conduct of the study depends on the study scope and the scheduling of activities in the study. Our Study Scope is to encompass the following 1) Study of the Organization; 2) Study of Decision-Making Procedures; 3) Analysis of Technical Feasibility 4) Analysis of Economic Feasibility; 5) Analysis of Environmental Feasibility; 6) Overall Feasibility Assessment; 7) Exploration on Plausible Frameworks for Follow-Up Project Development. Each module of the study scope is held in cooperation with users; at the end of the study, the users should have familiarity of, demand in full agreement with the findings of the study. In the following subsections, key issues in each component are highlighted (Vickers, 2007). 1) Study of the Organization: The purpose here is to be aware of the significance of the domain to the organization, and the interactions of the domain with other functions in the organization. 2) Study of Decision-Making Procedures: The purpose here is to gain an in-depth perceptive of the decision-making procedures involved. (Note that this component of the study, which is concerned with the domain, should not be confused with the assessment practice (Maiden, et al, 2004). 3) Analysis of Technical Feasibility: It is important that technical feasibility analysis be free of a meticulous technology, except it is the intention of the user organization to assess the suitability of particular technologies. In general, the choice of technology should be an end result of the study, rather than be a mechanism to drive the study. 4) Analysis of Economic Feasibility: From the user’s viewpoint, economic feasibility is the most prominent concern. As substantial investment is going to be made, the key question is whether the benefits of the system is worth the investment. 5) Analysis of Environmental Feasibility: The concern here is to understand no technical, no economic factors that, if not addressed prior to project development kickoff, would impede project development or affect the successful implementation of the system. 6) Overall Feasibility Assessment: The findings from technical, economic, and environmental feasibility analyses are consolidated and interpreted in this module (Vickers, 2007). 7) Exploration on Plausible Frameworks for Follow- up Project Development: Based on the production of the previous modules of the study, a set of recommendations for follow-up project development is drawn up. 5- Impact of good collect requirement and analysis them in build quality programs as the users need. In this section I will explain how the collected requirement and analysis can impact in building a quality programs as the users need. Here I expel this thing through different points. The good collected Requirements Engineering has following effects on the better-ness of project. They are: (Vickers, 2007) (1) By defining good requirements we have goals to represent non-functional requirements that we have to satisfy (good-enough) for better product, (2) By having good requirements collection we can match the requirements to components and the goals we have to do to make the development possible, (3) By having good requirements analysis we can rank modules, the possible candidates are ranked by how they satisfied the requirements, and (4) We can discuss to change decisions to change the requirements to match the component or to modify the component to match the requirements only of we have good requirements collection and analysis. This shows us that what we can so and which is not possible. Top business management should not agree to any application software development project to begin, or be continued, until an acknowledged and committed user community steps to the plate and accepts ownership of requirements and the attendant responsibilities. So we have to gather the requirements in a improved way so that we can be able to implement the project in an effective way. Ongoing project requirement change can effect the project implementation so we have to collect the requirement in an effective way, before the beginning of the project. 1- Good program and quality of it In this section I will explain the good program and its qualities. (Rogers, 2001) I will discuss the qualities that a good program should have. A Good program possesses the characteristic of portability A Good program possesses the characteristic maintainability A Good program possesses the characteristic testability A Good program possesses the characteristic usability A Good program possesses the characteristic reliability. A Good program possesses Structured ness A Good program possesses the characteristic efficiency A Good program possesses the characteristic security A Good program possesses the characteristic Testability A Good program possesses the characteristic Usability A Good program possesses the characteristic Consistency A Good program possesses the characteristic Completeness Here from the user prospective A Good program must have the following things in it: (Vickers, 2007) It must have the user interface intuitive It must have to execute uncomplicated operations It must be feasible to carry out complicated operations It must not give error messages It must behave as expected It must be well documented Is the user interface self-explanatory/ self-documenting? It must have user interface responsive or too slow There are also a lot of other good qualities that must be needed to present in good program. References 1. Dardenne, A. van Lamsweerde, and Fickas, S. 1993. ‘Goal-Directed Requirements Acquisition’; Science of Computing Programming, vol. 20, P.P. 3−50. 2. Donald C. Gause. 1989. ‘Exploring Requirements: Quality Before Design’; Dorset House Publishing Company. 3. Giunchiglia. 2001. ‘The tropos: Software development methodology processes, models and diagrams’; Technical Report No. 0111-20, ITC-IRST. 4. Hans Van Vliet. 2002. ‘Software Engineering: Principles and Practice’; John Wiley and Sons. 5. Hoboken, NJ. 2005. ‘Fundamentals of system engineering’; SYS 625 Course Notes. 6. Ian Sommerville. 2001. ‘Software Engineering’; Pearson Education (Addison Wesley). 7. IEEE Standard Glossary of Software Engineering Terminology. 1990. ‘quoted at the beginning of Chapter 1: Introduction to the guide’; Guide to the Software Engineering Body of Knowledge (February 6, 2004). Retrieved on 2008-10-28. 8. Kenneth C. Laudon. 1998. ‘Management Information System Sixth Edition’; New York. Addison Wesley Publishing Company. 9. Maiden, N. Gizikis, A. and Robertson, S. 2004. ‘Provoking Creativity: Imagine What Your Requirements Could Be Like’; IEEE Software, vol. 21, P.P. 68−75. 10. Mylopoulos, J. M. 2003. ‘Understanding ‘Why’ in Software Process Modeling, Analysis, and Design’; Proc. 16th Int’l Conf. Software Eng., IEEE CS Press. P.P. 159−168. 11. Roger S. Pressman. 2001. ‘Software Engineering: A Practicioner's Approach’; McGraw Hill. 12. Vickers, A. 2007. ‘Satisfying Business Problems’; IEEE Software, vol. 24, no. 3. P.P.18−20. 13. Willcocks L., Lester S. 1994. ‘The evaluation and management of information systems investments: from feasibility to routine operations’; In Information management: the evaluation of information systems investments, Chapman & Hall. Read More