Software Engineering Practices PDF

Software Engineering Practice ECAP437 Edited by Pawan Kumar Software Engineering Practice Edited By: Pawan Kumar  CONTENT Unit 1: Introduction to Software engineering 1 Aswani Kumar, L...

Software Engineering Practice ECAP437 Edited by Pawan Kumar Software Engineering Practice Edited By: Pawan Kumar  CONTENT Unit 1: Introduction to Software engineering 1 Aswani Kumar, Lovely Professional University Unit 2: Software process models 13 Aswani Kumar, Lovely Professional University Unit 3: Requirement Engineering 30 Aswani Kumar, Lovely Professional University Unit 4: Requirement Specification 41 Aswani Kumar, Lovely Professional University Unit 5: Design 55 Aswani Kumar, Lovely Professional University Unit 6: User Interface Design 79 Aswan i Kumar, Lovely Professional University Unit 7: Standards 93 Aswani Kumar, Lovely Professional University Unit 8: Software Testing 107 Aswani Kumar, Lovely Professional University Unit 9: Testing Strategies 122 Aswani Kumar, Lovely Professional University Unit 10: Testing Levels 135 Aswani Kumar, Lovely Professional University Unit 11: Bugs 147 Aswani Kumar, Lovely Professional University Unit 12: Software Maintenance 158 Aswani Kumar, Lovely Professional University Unit 13: Product Metrics 172 Aswan i Kumar, Lovely Professional University Unit 14: Software Process Improvement 187 Aswani Kumar, Lovely Professional University  Unit 01: Introduction to software engineering Notes Aswani Kumar, Lovely Professional University Unit 01: Introduction to Software engineering CONTENTS Objectives Introduction 1.1 Concepts of Software Engineering 1.2 Types of Software 1.3 Software Characteristics 1.4 Software Myths 1.5 Software Engineering Framework and Process 1.6 software engineering practices 1.7 Software Crisis Summary Keywords Self assessment Answer for Self Assessment Review question Further Reading Objectives After studying this unit, you will be able to: Discuss various concepts of software engineering. Characteristics and types of software software process and software engineering practices Explain the software engineering challenges and approach Introduction User needs and constraints must be determined and explicitly stated before a software product can be developed; the product must be designed to accommodate implementers, users, and maintainers; the source code must be carefully implemented and thoroughly tested; and supporting documents must be prepared. Analysis of change requests, redesign and modification of source code, rigorous testing of the updated code, update of documents to reflect the changes, and dissemination of modified work products to the appropriate user are all examples of software maintenance duties. In the 1960s, the necessity for methodical approaches to software creation and maintenance became obvious. Cost overruns, timetable slippage, lack of reliability, inefficiency, and lack of user approval plagued many software projects at the time. As computer systems grew larger and more complex, it became clear that demand for software was outpacing our ability to create and maintain it. As a result, the field of software engineering has grown into a significant technological discipline. In the last four decades, the complexity and nature of software have changed dramatically. Applications of the 1970s used a single processor, took single line inputs, and returned alphanumeric results. Today's programmes, on the other hand, are significantly more complicated, run-on client-server technology, and have a user-friendly interface. They run on a variety of CPUs, operating systems, and even machines from various parts of the world. 1 LOVELY PROFESSIONAL UNIVERSITY Notes SOFTWARE ENGINEERING PRACTICES The software groups do everything they can to stay on top of fast evolving new technologies while also dealing with development challenges and backlogs. Even the Software Engineering Institute (SEI) recommends that the development process be improved. Change is an unavoidable requirement of the hour. However, it frequently leads to tensions between those who embrace change and others who staunchly adhere to established working methods. As a result, there is a pressing need to adopt software engineering principles, techniques, and strategies in order to avoid conflicts and improve software development in order to provide high-quality software on time and on budget. Software is a set of instructions to acquire inputs and to manipulate them to produce the desired output in terms of functions and performance as determined by the user of the software. It also includes a set of documents, such as the software manual, meant for users to understand the software system Engineering on the other hand, is all about developing products, using well-defined, scientific principles and methods 1.1 Concepts of Software Engineering Evolving Role of Software In the previous few decades, software's position has shifted dramatically. Hardware, processing architecture, memory, storage capacity, and a wide range of unexpected input and output situations are all improved. As a result of all of these tremendous advancements, increasingly complex and sophisticated computer-based systems have emerged. Although sophistication leads to better results, it can also present issues for those who design these systems. A team of software experts has taken the place of the lone coder. In order to deliver a complex application, these professionals concentrate on different pieces of technology. However, the specialists are still confronted with the same issues as a lone coder: Why does it take long to finish software? Why are the costs of development so high? Why aren’t all the errors discovered before delivering the software to customers? Why is it difficult to measure the progress of developing software? All these questions and many more have led to the manifestation of the concern about software and the manner in which it is developed – a concern which lead to the evolution of the software engineering practices. Software now serves a dual purpose. It is both a product and a vehicle for the delivery of a product. It supplies the computational power embodied by computer hardware or, more broadly, a network of computers accessible by local hardware as a product. Software is an information transformer, whether it's in a cell phone or a mainframe computer, creating, organizing, obtaining, changing, displaying, or sending data that might be as simple as a single bit or as complicated as a multimedia presentation. Software serves as the vehicle for delivering the product, serving as the foundation for computer control (operating systems), information exchange (networks), and the creation and control of additional programmes (software tools and environments). The most essential product of our day is information, which is delivered by software. Software transforms personal data (e.g., an individual's financial transactions) to make it more useful in a local context; it manages business information to improve competitiveness; and it serves as a gateway to global information networks (e.g., the Internet) and a means of acquiring information in all of its forms. The role of computer software has undergone significant change over a time span of little more than 50 years. Dramatic improvements in hardware performance, profound changes in computing architectures, vast increases in memory and storage capacity, and a wide variety of exotic input and output options have all precipitated more sophisticated and complex computer-based systems. The lone programmer of an earlier era has been replaced by a team of software specialists, each focusing on one part of the technology required to deliver a complex application. LOVELY PROFESSIONAL UNIVERSITY 2  Unit 01: Introduction to software engineering Notes The same questions asked of the lone programmer are being asked when modern computer- Notes based systems are built. Give answers to questions: 1. Why does it take so long to get software finished? 2. Why are development costs so high? 3. Why can’t we find all the errors before we give the software to customers? 4. Why do we continue to have difficulty in measuring progress as software is being developed? 1.2 Types of Software System Software- A collection of programs written to service other programs at system level, For example, compiler, operating systems. Application software- Developed as per user requirement. Real-time Software- Programs those monitor/analyze/control real world events as they occur. Business Software- Programs that access, analyze and process business information Engineering and Scientific Software -: Software using “number crunching” algorithms for different science and applications, System simulation, computer-aided design. Embedded Software-: Embedded software resides in read-only memory and is used to control products and systems for the consumer and industrial markets. It has very limited and esoteric functions and control capability. Artificial Intelligence (AI) Software : Programs make use of AI techniques and methods to solve complex problems. Active areas are expert systems, pattern recognition, games Internet Software: Programs that support internet accesses and applications. For example, search engine, browser, e-commerce software, authoring tools. Software Tools and CASE environment : Tools and programs that help the construction of application software and systems. For example, test tools, version control tools. 1.3 Software Characteristics A software product can be judged by what it offers and how well it can be used. In the first NATO conference on software engineering in 1968, Fritz Bauer defined Software engineering as “The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines”. Stephen Schach defined the same as “A discipline whose aim is the production of quality software, software that is delivered on time, within budget and that satisfies its requirements”. Let us now explore the characteristics of software in detail: Software is Developed or Engineered and not manufactured: Although there exists few similarities between the hardware manufacturing and software development, the two activities differ fundamentally. Both require a good design to attain high quality. But the manufacturing phase of hardware can induce quality related problems that are either nonexistent for software or can be easily rectified. Although both activities depend on people but the relationship between people and work is totally different. Software does not Wear Out: Figure shows the failure rate of hardware as a function of time. It is often called the “bathtub curve”, indicating that a hardware shows high failure at its early stage (due to design and manufacturing defects); defects get resolved and the failure rate reduces to a steady-state level for some time. As time progresses, the failure rate shoots up again as the hardware wears out due to dust, temperature and other environmental factors. Failure Curve for Hardware 3 LOVELY PROFESSIONAL UNIVERSITY Notes SOFTWARE ENGINEERING PRACTICES Because the software does not undergo environmental degradation, its failure curve ideally should flatten out after the initial stage of its life. The initial failure rate is high because of undiscovered defects. Once these defects are fixed, the curve flattens at a later stage. Thus, the software does not wear out but deteriorates. Software is Custom Built and Not Designed Component Wise: Software is designed and built so that it can be reused in different programs. Few decades ago subroutine libraries were created that re-used well defined algorithms but had a limited domain. Today this view has been extended to ensure re-usability of not only algorithms but data structures as well. Functionality: Refers to the degree of performance of the software against its intended purpose. Reliability: Refers to the ability of the software to provide desired functionality under the given conditions. Usability: Refers to the extent to which the software can be used with ease. Efficiency: Refers to the ability of the software to use system resources in the most effective and efficient manner. Maintainability: Refers to the ease with which the modifications can be made in a software system to extend its functionality, improve its performance, or correct errors. Portability: Refers to the ease with which software developers can transfer software from one platform to another, without (or with minimum) changes. In simple terms, it refers to the ability of software to function properly on different hardware and software platforms without making any changes in it. Program vs. Software Software is more than programs. It comprises of programs, documentation to use these programs and the procedures that operate on the software systems. Components of software A program is a part of software and can be called software only if documentation and operating procedures are added to it. Program includes both source code and the object code. LOVELY PROFESSIONAL UNIVERSITY 4  Unit 01: Introduction to software engineering Notes List of Documentation Manuals Operating procedures comprise of instructions required to setup and use the software and instructions on actions to be taken during failure. List of operating procedure manuals/ documents is given in Figure List of Operating Procedure Manuals 1.4 Software Myths Myth 1: Computers are more reliable than the devices they have replaced. Considering the reusability of the software, it can undoubtedly be said that the software does not fail. However, certain areas which have been mechanized have now become prone to software errors as they were prone to human errors while they were manually performed. Myth 2: Software is easy to change. Yes, changes are easy to make – but hard to make without introducing errors. With every change the entire system must be re-verified. Myth 3: If software development gets behind scheduled, adding more programmers will put the development back on track. Software development is not a mechanistic process like manufacturing. In the words of Brooks: “adding people to a late software project makes it later”. Myth 4: Testing software removes all the errors. 5 LOVELY PROFESSIONAL UNIVERSITY Notes SOFTWARE ENGINEERING PRACTICES Testing ensures presence of errors and not absence. Our objective is to design test cases such that maximum number of errors is reported. Myth 5: Software with more features is better software. This is exactly the opposite of the truth. The best programs are those that do one kind of work. Myth 6: Aim has now shifted to develop working programs. The aim now is to deliver good quality and efficient programs rather than just delivering working programs. Programs delivered with high quality are maintainable. The list is unending. These myths together with poor quality, increasing cost and delay in the software delivery have lead to the emergence of software engineering as a discipline. Types of Myths Software Myths: Software Myth beliefs about software and the process used to build it – can be traced to the earliest days of computing. Myths have a number of attributes that have made them insidious. Management Myths: Managers with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets, keep schedules from slipping, and improve quality. Like a drowning person who grasps at a straw, a software manager often grasps at belief in a software myth, if the Belief will lessen the pressure. Myth: We already have a book that’s full of standards and procedures for building software. Won’t that provide my people with everything they need to know? Reality: The book of standards may very well exist, but is it used? Are software practitioners aware of its existence? Does it reflect modern software engineering practice? Is it complete? Is it adaptable? Is it streamlined to improve time to delivery while still maintaining a focus on Quality? In many cases, the answer to these entire questions is no: Myth: If we get behind schedule, we can add more programmers and catch up (sometimes called the Mongolian horde concept). Reality: Software development is not a mechanistic process like manufacturing. In the words of Brooks: “Adding people to a late software project makes it later.” At first, this statement may seem counter intuitive. However, as new people are added, people who were working must spend time educating the newcomers, thereby reducing the amount of time spent on productive development effort. Myth: If we decide to outsource the software project to a third party, I can just relax and let that firm build it. Reality: If an organization does not understand how to manage and control software project internally, it will invariably struggle when it outsources software project. Customer Myths: A customer who requests computer software may be a person at the next desk, a technical group down the hall, the marketing/sales department, or an outside company that has requested software under contract. In many cases, the customer believes myths about software because software managers and practitioners do little to correct misinformation. Myths led to false expectations and ultimately, dissatisfaction with the developers. Myth: A general statement of objectives is sufficient to begin writing programs we can fill in details later. Reality: Although a comprehensive and stable statement of requirements is not always possible, an ambiguous statement of objectives is a recipe for disaster. Unambiguous requirements are developed only through effective and continuous communication between customer and developer. Myth: Project requirements continually change, but change can be easily accommodated because software is flexible. LOVELY PROFESSIONAL UNIVERSITY 6  Unit 01: Introduction to software engineering Notes Reality: It’s true that software requirement changes, but the impact of change varies with the time at which it is introduced. When requirement changes are requested early, cost impact is relatively small. However, as time passes, cost impact grows rapidly – resources have been committed, a design framework has been established, and change can cause upheaval that requires additional resources and major design modification. 1.5 Software Engineering Framework and Process It is engineering branch associated with the development of software product using well-defined scientific principles, methods and procedures. The outcome of software engineering is an efficient and reliable software product. Need of Software Engineering Large software Adaptability Cost Dynamic Nature Quality Management Software Engineering has a three layered framework. The foundation for software engineering is the process layer. Software engineering process holds the technology layers together and enables rational and timely development of computer software. Process defines a framework for a set of Key Process Areas (KPA) that must be established for effective delivery of software engineering technology. Software Engineering Framework Software engineering methods provide the technical knowhow for building software. Methods encompass a broad array of tasks that include requirements analysis, design, program construction, testing, and support. Software engineering tools provide automated or semi-automated support for the process and the methods. Software Process A process is a series of steps involving activities, constraints and resources that produce an intended output of some kind. In simpler words, when you build a product or system, it’s important to go through a series of predictable steps – a road map that helps you create a timely, high quality result. The road map that you follow is called a software process. In the last decade there has been a great deal of resources devoted to the definition, implementation, and improvement of software development processes. ISO 9000 Software Process Improvement and Capability Determination (SPICE) SEI Processes Capability Maturity Model (CMM) for software Personal Software Process (PSP) Team Software Process (TSP) A set of activities whose goal is the development or evolution of software Generic activities in all software processes are: Specification: what the system should do and its development constraints 7 LOVELY PROFESSIONAL UNIVERSITY Notes SOFTWARE ENGINEERING PRACTICES Development: production of the software system Validation: checking that the software is what the customer wants Evolution: changing the software in response to changing demands. Software Process Model A simplified representation of a software process, presented from a specific perspective. Example: Process perspectives are: Workflow perspective – sequence of activities Data-flow perspective – information flow Role/action perspective – who does what Generic Process Models Waterfall Evolutionary development Formal transformation Integration from reusable components Software Engineering Methods Structured approaches to software development which include system models, notations, rules, design advice and process guidance Rules Constraints applied to system models Notes Recommendations – Advice on good design practice Process guidance – What activities to follow CASE (Computer-Aided Software Engineering) Software systems which are intended to provide automated support for software process activities. CASE systems are often used for method support: Upper- CASE: Tools to support the early process activities of requirements and design. Lower- CASE: Tools to support later activities such as programming, debugging and testing. Model descriptions – Descriptions of graphical models, which should be produced Attributes of Good Software The software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable. Maintainability: Software must evolve to meet changing needs. Dependability: Software must be trustworthy. Efficiency: Software should not make wasteful use of system resources. Usability: Software must be usable by the users for which it was designed. 1.6 software engineering practices Software engineering practices are a set of approaches to software development. To overcome the software development problems. Understand the problem (communication and analysis) Plan the solution ( Modeling and software design) Carry out the plan (code generation) Examine the result for accuracy (testing and quality assurance) Understand the problem Who has a stake in the solution to the problem? LOVELY PROFESSIONAL UNIVERSITY 8  Unit 01: Introduction to software engineering Notes What are unknowns? Can the problem be compartmentalized? Can the problem be represented graphically? Develop Iteratively Critical risks are resolved before making large investments Initial iterations enable early user feedback Testing and integration are continuous Objective milestones provide short term focus Manage Requirements Requirements are dynamic - expect them to change during software development User's own understanding of the requirements evolves over time Gain agreement with user on what the system should do and not how Maintain forward and backward traceability of requirements Use Component Based Architecture Using components permits reuse Choice of thousands of commercially available components Improved maintainability and extensibility Promotes clean division of work among teams of developers Plan the solution Have you seen similar problem before? Has a similar problem being solved? Can sub problems be defined? Can a solution be given for effective implementation? Can a design model be created? Carry out the plan Does the solution conform the plan? Is the source code traceable to the design model Is each component solution correct? Have the design and code being reviewed? Examine the result Is the each component part being tested? Does the solution produce the result? Has the software being evaluated against all stakeholder requirement? Control Changes to Software Without explicit control parallel development degrades to chaos Decompose the architecture into subsystems and assign responsibility of each subsystem to a team. Establish secure workspaces for each team i.e. each team is isolated from changes made in other workspaces. Establish an enforceable change control mechanism where Change requests are prioritized Impact of the change request is assessed Plan put in place to introduce change in a particular iteration 1.7 Software Crisis Size: Software is becoming larger and more complex with the growing complexity and expectations out of software. For example, the code in consumer products is doubling every couple of years. Quality: Many software products have poor quality, i.e., the software produces defects after put into use due to ineffective testing techniques. For example, Software testing typically finds 25 defects per 1000 lines of code. 9 LOVELY PROFESSIONAL UNIVERSITY Notes SOFTWARE ENGINEERING PRACTICES Cost: Software development is costly i.e., in terms of time taken to develop and the money involved. For example, Development of the FAA’s Advance Automation System cost over $700 per line of code. Delayed delivery: Serious schedule overruns are common. Very often the software takes longer than the estimated time to develop which in turn leads to cost shooting up. For example, one in four large-scale development projects are never completed. Summary Software is more than programs. It comprises of programs, documentation to use these programs and the procedures that operate on the software systems. Any area that involves a sequence of steps (i.e. an algorithm) to generate output can make use of software engineering. The software myths together with poor quality, increasing cost and delay in the software delivery have lead to the emergence of software engineering as a discipline. Software engineering process holds the technology layers together and enables rational and timely development of computer software. The software engineering discipline has been faced with a number of challenges over the years, including those related to quality, management and under estimation. One of the challenge for the software engineering discipline is the increasing concern with respect to the design and management of software projects whose complexity is increasing exponentially. Legacy systems will also continue to present a considerable challenge to software engineering because the need to ensure that the old technologies are capable to co-exist with the new and vice-versa will be much greater in the near future Keywords Artificial Intelligence Software: AI software uses algorithms to solve problems that are not open to simple computing and analysis. Determinate Program: A program that takes data in a predefined order, applies algorithms to it and generates results is called a determinate program. Process: A process is a series of steps involving activities, constraints and resources that produce an intended output of some kind. Program: A program is a part of software and can be called software only if documentation and operating procedures are added to it. Real-time Software: It refers to the software that controls the events and when they occur. Software: It is defined as a discipline whose aim is the production of quality software, software that is delivered on time, within budget and that satisfies its requirements. System Engineering: System engineering is an interdisciplinary field of engineering that focuses on the development and organization of complex artificial systems. System Software: It is the software program that interacts with the hardware components so that other application software can run on it. Self assessment 1. Which one is system software? A. MS office B. Windows XP C. Chrome D. all of above 2. What are the software crises? A. Quality B. Size C. Cost D. All of above LOVELY PROFESSIONAL UNIVERSITY 10  Unit 01: Introduction to software engineering Notes 3. Which one is application software _______ A. Sound drivers B. Operating system C. LAN drivers D. Internet explorer 4. Software is _______ A. Documentation and configuration of data B. Set of programs C. Set of programs, documentation & configuration of data D. None of the mentioned 5. Characteristics of a software is __________ A. Operational B. Transitional C. Maintenance D. All of above 6. Software processes resources are______ A. SPICE B. CMM C. PSP D. all of above 7. Software process activities include A. Quality B. Size C. Cost D. All of above 8. The process of developing a software product using software engineering principles and methods is referred to as _______ A. Software Engineering B. Software Evolution C. System Models D. Software Models 9. Software engineering practices are______ A. Understand the problem B. Plan the solution and Carry out the plan C. Examine the result for accuracy D. all of above 10. SDLC stands for A. System Development Life cycle B. Software Design Life Cycle C. Software Development Life Cycle D. System Design Life Cycle 11 LOVELY PROFESSIONAL UNIVERSITY Notes SOFTWARE ENGINEERING PRACTICES Answer for Self Assessment 1. B 2. D 3. C 4. C 5. A 6. D 7. D 8. B 9. 10. C Review question 1. “Software is designed and built so that it can be reused in different programs.” Substantiate with suitable examples. 2. Suppose you are the software engineer of a modern and technically equipped company then explain how software delivers the most important product of our time—information. 3. Critically analyze the role of computer software. “Software has undergone significant change over a time span of little more than 50 years.” Comment. 4. “The software differs from hardware as it is more logical in nature and hence, the difference in characteristics.” Discuss. 5. Software is easy to change. It is myth? Explain why or why not? Explain with example. 6. Process defines a framework for a set of Key Process Areas (KPA) that must be established for effective delivery of software engineering technology. Analyze this statement. 7. Discuss the concept of software engineering framework. Further Reading Books Rajib Mall, Fundamentals of Software Engineering, 2nd Edition, PHI. Richard Fairpy, Software Engineering Concepts, Tata McGraw Hill, 1997. R.S. Pressman, Software Engineering – A Practitioner’s Approach, 5th Edition, Tata McGraw Hill Higher education. Sommerville, Software Engineering, 6th Edition, Pearson Education ftp://ftp.cordis.europa.eu/pub/ist/docs/directorate_d/st-ds/softeng.pdf http://www0.cs.ucl.ac.uk/staff/A.Finkelstein/talks/10openchall.pdf http://thepiratebay.sx/torrent/8192581/Software_Engineering__A_ Practitioner_s_Approach__7th_Ed._[PDF] http://www.etsf.eu/system/files/users/SottileF/XG_Basics_v2.pdf LOVELY PROFESSIONAL UNIVERSITY 12 Aswani Kumar, Lovely Professional University Unit 02: Software process models Notes Unit 02: Software process models CONTENTS Objectives Introduction 2.1 Processes and Models 2.2 The Software Process Model 2.3 Characteristics of a Software Model 2.4 Software Development Life Cycle 2.5 Prototype model 2.6 Water Fall Model 2.7 V model 2.8 Incremental Model 2.9 Agile method of software development Summary Keywords Self Assessment Answer for Self Assessment Review Questions Further Reading Objectives After studying this unit, you will be able to: Discuss the concept of Processes and Models Explain the Software Process Model Characteristics of a Software Model Describe various process models Agile method of software development Introduction The concept of process is central to the software engineering method. “A particular technique of doing something, usually requiring a number of steps or operations,” defines a process. The term "software process" refers to the way of developing software in software engineering. A software process is a set of operations that must be completed in order to create high-quality software. Is it possible to refer to the process as software engineering? Yes and no are the answers. The term "process" refers to the methods used in the development of software. Also included in the process are the technical procedures and tools used in software engineering. Software must be developed keeping in mind the demands of the end-user using a defined software process. In this unit, we will discuss the concept of software process models. We will also discuss different types of process models such as waterfall model, iterative model, etc. 2.1 Processes and Models The software process describes how to manage and organise a software development project while taking limits and restrictions into account. A software process is a collection of actions linked by ordering constraints, with the goal of producing the intended output if the activities are completed 13 LOVELY PROFESSIONAL UNIVERSITY Notes SOFTWARE ENGINEERING PRACTICES ______________________________________________ correctly and in compliance with the ordering constraints. The goal is to produce high -quality software at a reasonable cost. Clearly, a method is not acceptable if it does not scale up and cannot handle massive software projects or produce high-quality software. Many processes are usually running at the same time in large software development organisations. Many of these have little to do with software engineering, yet they do have an impact on software development. These process models could be classified as non-software engineering. Processes that fall under this include business process models, social process models, and training models. These processes have an impact on software development, although they are outside the scope of software engineering. The process that deals with the technical and management issues of software development is called a software process. Clearly, many different types of activities need to be performed to develop software Because different types of activities are usually performed by different persons, it is better to think of the software process as a collection of component processes, each of which has a specific type of activity. Each of these component processes usually has a different goal in mind, while they obviously work together to achieve the overall software engineering goal. Software Process framework is a set of guidelines, concepts and best practices that describes high level processes in software engineering. It does not talk about how these processes are carried out and in what order. As previously stated, a software process defines a method for building software. A software project, on the other hand, is a development project that involves the usage of a software process. A software project's outputs are known as software products. Each software development project begins with a set of requirements and is expected to end with software that meets those requirements. A software process is an abstract set of operations that must be carried out in order to get from user requirements to the end result. One can view the software process as an abstract type, and each project is done using that process as an instance of this type. In other words, there can be many projects for a process and there can be many products produced in a project. This relationship is shown in Figure Relation between Processes, Projects and Products The sequence of activities specified by the process is typically at an abstract level because they have to be usable for a wide range of projects. Hence, “implementing” them in a project is not straightforward. Example : Let us take the example of book writing. A process for book writing on a subject will be something like this: 1. Set objectives of the book – audience, marketing etc. 2. Outline the contents. 3. Research the topics covered. 4. Do literature survey. LOVELY PROFESSIONAL UNIVERSITY 14  Unit 02: Software process models Notes 5. Write and/or compile the content. 6. Get the content evaluated by a team of experts. 7. Proof read the book. 8. Make corrections, if any. 9. Get the book typeset. 10. Print the book. 11. Bind the book. Overall, the process specifies actions that are not project-specific at an abstract level. It's a generalised list of tasks that doesn't provide a precise roadmap for a specific project. The detailed roadmap for a project is the project plan that outlines what precise actions to undertake for this project, when to do them, and how to keep the project on track. The project plan for publishing a book on Software Engineering, in our example, will be a comprehensive marked map outlining the activities, as well as additional specifics such as plans for getting illustrations, photographs, and so on. It should be obvious that a project is driven by its process. A method restricts a project's degrees of freedom by stating which activities must be completed and in what order. Furthermore, the project plan, which is itself within the process's bounds, specifies restrictions on the degrees of freedom for a specific project. To put it another way, a project plan cannot include an action that is n ot part of the process. Because each project is an instance of the process it follows, it is fundamentally the process that determines the expected outcomes of a project. As a result, software engineering places a strong emphasis on the process. Software Process A software process is the set of activities and associated results that produce a software product. Software engineers mostly carry out these activities. There are four fundamental process activities, which are common to all software processes. These activities are: 1. Software Specification: The functionality of the software and constraints on its operation must be defined. 2. Software Development: The software to meet the specification must be produced. 3. Software Validation: The software must be validated to ensure that it does what the customer wants. 4. Software Evolution: The software must evolve to meet changing customer needs. Different software processes organize these activities in different ways and are described at different levels of detail. The timing of the activities varies as does the results of each activity. Different organizations may use different processes to produce the same type of product. However, some processes are more suitable than others for some types of application. If an inappropriate process is used, this will probably reduce the quality or the usefulness of the software product to be developed. Different software processes organize these activities in different ways and are described at different levels of detail. The timing of the activities varies as does the results of each activity. Different organizations may use different processes to produce the same type of product. However, 15 LOVELY PROFESSIONAL UNIVERSITY Notes SOFTWARE ENGINEERING PRACTICES ______________________________________________ some processes are more suitable than others for some types of application. If an inappropriate process is used, this will probably reduce the quality or the usefulness of the software product to be developed. 2.2 The Software Process Model A software process model is a simplified representation of a software process provided from a certain viewpoint. Because models are by definition simplifications, a software process model is an abstraction of the process being represented. Activities that are part of the software process, software products, and the responsibilities of persons involved in software engineering can all be included in process models. Example : Some examples of the types of software process model that may be produced are: A Workflow Model: This shows the sequence of activities in the process along with their inputs, outputs and dependencies. The activities in this model represent human actions. A Dataflow or Activity Model: This represents the process as a set of activities each of which carries out some data transformation. It shows how the input to the process such as a specification is transformed to an output such as a design. The activities here may be at a lower level than activities in a workflow model. They may represent transformations carried out by people or by computers. A Role/action Model: This represents the roles of the people involved in the software process and the activities for which they are responsible. There are a number of different general models or paradigms of software development The Waterfall Approach: This takes the above activities and represents them as separate process phases such as requirements specification, software design, implementation, testing and so on. After each stage is defined it is ‘signed off’ and development goes on to the following stage. Evolutionary Development : This approach interleaves the activities of specification, development and validation. An initial system is rapidly developed from very abstract specifications. This is then refined with customer input to produce a system which satisfies the customer’s needs. The system may then be delivered. Alternatively, it may be reimplemented using a more structured approach to produce a more robust and maintainable system. Formal Transformation: This approach is based on producing a formal mathematical system specification and transforming this specification, using mathematical methods to a program. These transformations are ‘correctness preserving’ this means that you can be sure that the developed program meets its specification. System Assembly from Reusable Components : This technique assumes that parts of the system already exist. The system development process focuses on integrating these parts rather than developing them from scratch. 2.3 Characteristics of a Software Model When creating any form of software, the first question that comes to mind for each developer is, "What are the qualities that good software should have?" We'd want to state the basic expectations one has from any software before diving into technical qualities. First and foremost, a software solution must meet all of the customer's or end-needs. Users In addition, the software's development and maintenance costs should be modest. Software development should be finished within the stated time range. Well these were the obvious things which are expected from any project (and software development is a project in itself). Now let’s take a look at Software Quality factors. These set of factors can be easily explained by Software Quality Triangle. The three characteristics of good application software are: 1. Operational Characteristics 2. Transition Characteristic 3. Revision Characteristics LOVELY PROFESSIONAL UNIVERSITY 16  Unit 02: Software process models Notes Operational Characteristics of a Software These are functionality based factors and related to ‘exterior quality’ of software. Various Operational Characteristics of software are: Correctness : The software which we are making should meet all the specifications stated by the customer. Usability/Learnability: The amount of efforts or time required to learn how to use the software should be less. This makes the software user-friendly even for IT-illiterate people. Integrity: Just like medicines have side-effects, in the same way software may have a side-effect i.e. it may affect the working of another application. But quality software should not have side effects. Reliability: The software product should not have any defects. Not only this, it shouldn’t fail while execution. Efficiency: This characteristic relates to the way software uses the available resources. The software should make effective use of the storage space and execute command as per desired timing requirements. Security: With the increase in security threats nowadays, this factor is gaining importance. The software shouldn’t have ill effects on data/hardware. Proper measures should be taken to keep data secure from external threats. Safety: The software should not be hazardous to the environment/life. Revision Characteristics of Software These engineering based factors of the relate to ‘interior quality’ of the software like efficiency, documentation and structure. These factors should be in-build in any good software. Various Revision Characteristics of software are: Maintainability: Maintenance of the software should be easy for any kind of user. Flexibility: Changes in the software should be easy to make. Extensibility: It should be easy to increase the functions performed by it. Scalability: It should be very easy to upgrade it for more work (or for more number of users). Testability: Testing the software should be easy. Modularity: Any software is said to made of units and modules which are independent of each other. These modules are then integrated to make the final software. If the software is divided into separate independent parts that can be modified, tested separately, it has high modularity. Transition Characteristics of the Software Interoperability: Interoperability is the ability of software to exchange information with other applications and make use of information transparently. Reusability: If we are able to use the software code with some modifications for different purpose then we call software to be reusable. Portability: The ability of software to perform same functions across all env ironments and platforms, demonstrate its portability. Importance of any of these factors varies from application-to-application. 2.4 Software Development Life Cycle The Software Development Life Cycle is process or method which is used to design, develop quality software. SDLC is a systematic process for building software that ensures the quality and correctness of the software built. SDLC process aims to produce high-quality software that meets customer expectations. The system development should be complete in the pre-defined time frame and cost. SDLC consists of a detailed plan which explains how to plan, build, and maintain specific software. Every phase of the SDLC life Cycle has its own process and deliverables that feed into the next phase. 17 LOVELY PROFESSIONAL UNIVERSITY Notes SOFTWARE ENGINEERING PRACTICES ______________________________________________ ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software. SDLC Phase SDLC consist different phases every phase of the SDLC life Cycle has its own process/ activities and it is linked with next phase or it provides the input to the next phase. Requirement analysis Feasibility study Design Coding Testing Installation/Deployment Maintenance Requirement analysis Feasibility study Design Coding Testing Installation/Deployment Maintenance Requirement Analysis Requirement Analysis is use to gather information from different stake holders e.g. sales department, market surveys and domain experts in the industry. This information is then used to plan the basic project approach and to conduct product feasibility study Feasibility study A feasibility study is simply an assessment of the practicality of a proposed plan or method. Economic Time Operation feasibility Technical Legal Design The design phase helps define overall system architecture. In design phase documents are prepared as per the requirement specification document and feasibility study. Coding In this phase developers start build the entire system by writing code using the chosen programming language/ platform. In this phase tools use programming tools like compiler, interpreters, debugger to generate and implement the code LOVELY PROFESSIONAL UNIVERSITY 18  Unit 02: Software process models Notes Testing This phase is used to verify that the entire application works according to the customer requirement by using different testing techniques. Unit Testing Integration Testing Regression Testing Black box testing White box testing Beta Testing Installation/Deployment In this phase software is deploy to the production environment so users can start using the product. Based on the feedback given by the user’s manager, the final software is released and checked for deployment issues. This phase allows users to safely play with the product before releasing it to the market. Maintenance This phase deal with the real world changing conditions, we need to update and advance the software to match. Bug fixing Upgrade Enhancement 2.5 Prototype model It is software development model in which prototype model is built, tested, and reworked until an acceptable prototype is achieved. It is a demo implementation of the actual product or system. Prototyping is used to allow the users evaluate developer proposals and try them out before implementation. A prototype model usually exhibits limited functional capabilities, low reliability, and inefficient performance as compared to the actual software. It is suitable where the project's requirements are not known in detail to customer. It is an iterative, trial and error method which takes place between developer and client. Prototype model phase Requirements gathering and analysis Design Build prototype User evaluation Refining prototype Implementation and Maintenance 19 LOVELY PROFESSIONAL UNIVERSITY Notes SOFTWARE ENGINEERING PRACTICES ______________________________________________ Requirements gathering and analysis The requirements of the system are defined. In this process, the users of the system are interviewed to know what their expectation from the system is. Use different method to gather information. Design In this phase, a simple design of the system is built. It gives a brief idea of the system to the user Build prototype In this phase the initial Prototype is developed, where the basic requirements are showcased and user interfaces are provided. The actual prototype is designed based on the information gathered from design phase User evaluation In this phase prototype developed is presented to the customer and the other important stakeholders in the project for an initial evaluation. The feedback is collected and used for further changes in the product under development. This phase help to find out the strength and weakness of the working model Refining prototype In this phase, Based upon customer feedback negotiations happen on factors like – time and budget constraints and technical feasibility of the actual implementation. Changes are accepted and incorporated in the new Prototype model and the cycle repeats until the customer expectations are met. Implementation and Maintenance After development of final system based on the final prototype, it is tested and deployed to production. The system undergoes routine maintenance and updates based upon real time environment changes for minimizing downtime and prevent large-scale failures and for. Types of Prototyping Models Rapid Throwaway prototypes This technique offers a useful method of exploring ideas and getting customer feedback for each of them. In this method, a developed prototype need not necessarily be a part of the ultimately LOVELY PROFESSIONAL UNIVERSITY 20  Unit 02: Software process models Notes accepted prototype. Customer feedback helps in preventing unnecessary design faults and hence, the final prototype developed is of better quality. Evolutionary prototype The prototype developed is incrementally refined based on customer's feedback until it is finally accepted. It helps you to save time as well as effort. That's because developing a prototype from scratch for every interaction of the process can sometimes be very frustrating. Incremental Prototype In incremental Prototyping, the final product is decimated into different small prototypes and developed individually. Eventually, the different prototypes are merged into a single product. This method is helpful to reduce the feedback time between the user and the application development team. Extreme Prototype Extreme prototyping method is mostly used for web development. It is consists of three sequential phases. Basic prototype with all the existing page is present in the HTML format. You can simulate data process using a prototype services layer. The services are implemented and integrated into the final prototype. Advantages of prototype model The Users involved in development. Errors can be detected in the initial stage of the software development process. Suitable where requirement are changing. Reduce Maintenance cost Disadvantages of prototype model It is a slow and time taking process Cost increases with respect to time. Customer involvement is higher so it requirement changes are very dynamic and it impact overall product development 2.6 Water Fall Model The waterfall model derives its name due to the cascading effect from one phase to the other as is illustrated in the figure below. In this model each phase is well defined, has a starting and ending point, with identifiable deliveries to the next phase. It is Linear sequential model Introduced by Winston W. Royce in 1970. The waterfall model is the classic lifecycle model. Whole system is developed in a sequential approach. Each phase is completed fully before the next begin. Stages of a prototype model are: Requirement analysis Design Implementation Testing Deployment Maintenance 21 LOVELY PROFESSIONAL UNIVERSITY Notes SOFTWARE ENGINEERING PRACTICES ______________________________________________ Requirement analysis In this stage to understand the requirements of the system to be developed Software definition to be detailed and accurate with no ambiguities Documented requirements and reviewed. Software Requirement Specification (SRS) document is created Design In this phase the requirements gathered in the SRS transform into a suitable form for coding in a programming language or selection of platform. It helps in defining the overall system architecture. Implementation In this phase software design is translated into source code using any suitable programming language. Testing In this phase code is thoroughly examined based upon different testing methods. Unit testing Integration testing Alpha testing Beta testing Deployment After testing is done, the product is deployed in the customer environment or released into the market. Maintenance It is performed by every user once the software has been delivered to the customer, installed, and operational as per customer request Meet the changing customer needs Adapted to accommodate changes in the external environment Advantages Simple and easy to understand and use Phases in this model are processed one at a time Suited for smaller projects where requirements are well defined Clearly defined phase. Process and results are well documented LOVELY PROFESSIONAL UNIVERSITY 22  Unit 02: Software process models Notes Disadvantages All requirements must be known upfront Not suitable where requirements are changing frequently Not a good model for complex and object-oriented projects. High amounts of risk and uncertainty It is difficult to measure progress within stages. 2.7 V model The V model is type of SDLC model. Testing phase parallel to each development phase, Process executes in a sequential manner in V-shape. It is also known as Verification and Validation model The next phase starts only after completion of the previous phase i.e. for each development activity, there is a testing activity corresponding to it. Verification and validation Verification: Verification is a static analysis technique. In this technique, testing is done without executing the code. Examples include – Reviews, Inspection It is the process of evaluation of the product development phase to find whether specified requirements meet. Validation: Validation is a dynamic analysis technique where testing is done by executing the code. Examples include functional and non-functional testing techniques. Design phase Requirement Analysis System design Architectural Design Module design Testing phase Unit testing Integration testing System testing User acceptance testing Requirement Analysis In this stage to understand the requirements of the system to be developed, this phase involves detailed communication with the customer and domain experts. Different method are used to gather information System design 23 LOVELY PROFESSIONAL UNIVERSITY Notes SOFTWARE ENGINEERING PRACTICES ______________________________________________ In this phase, a simple design of the system is built as per requirement gathered in previous phase. The system design will have the understanding and detailing the complete hardware and communication setup for the product under development. Architectural Design In architecture design it should understand all modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, and technology detail The system design is broken down further into modules taking up different functionality. This is also referred to as High Level Design (HLD). Module design In this phase, the system breaks down into small modules. The detailed internal design for all the system modules is specified, referred to as Low Level Design (LLD).In this phase design is checked for its compatibility with the other modules in the system architecture and the other external systems. Coding In this phase perform task based upon design phase inputs and follow guidelines for coding, Selection of programming language or platform. Unit testing In this phase Unit Test Plans (UTPs) are developed during the module design phase. These UTPs are executed to eliminate errors at code level or unit level. A unit is the smallest entity which can independently exist Integration testing In this phase modules are integrated and the system is tested. Integration testing is performed on the Architecture design phase. It verifies the communication of modules among themselves. System testing In this phase complete application is checked with its functionality, inter dependency, and communication. It tests the functional and non-functional requirements of the developed application. It is associated with the system design phase. Acceptance testing It is associated with the requirement analysis phase and involves testing the product in user environment. It uncovers the compatibility issues with the other systems available in the user environment. Advantages This model focuses on verification and validation activities early in the life cycle Avoids the downward flow of the defects. This is a disciplined model and Phases are completed one at a time. Useful in small projects where requirements are clear Disadvantages It is not suitable for projects where requirements are more dynamic and contains high risk of changing Not suitable for complex projects. 2.8 Incremental Model In Incremental Model requirements are broken down into multiple standalone modules of software development cycle. Multiple development cycles take place here, making the life cycle a “multi- waterfall” cycle. Each iteration passes through the requirements, design, coding and testing phases. After completion of one module the system adds function to the previous release until all designed functionality has been implemented. LOVELY PROFESSIONAL UNIVERSITY 24  Unit 02: Software process models Notes Incremental Model Phase Requirement analysis Design & Development Testing Implementation Requirement analysis In this phase requirements are gathered and analyzed using different techniques and tools. This phase involves detailed communication with the customer and domain experts. Design and Development In this phase the design of the system functionality and the development method are finished with success. When software develops new practicality, the incremental model uses style and development phase. Testing In this phase the testing phase checks the performance of each existing function as well as additional functionality. Different methods and tools are used to test the behavior of each task. Implementation In this phase final coding is done based upon designing and development phase and tests the functionality in the testing phase. After completion of this phase, the number of the product working is enhanced and upgraded up to the final system product. Characteristics of incremental model System development is broken down into many mini development projects Partial systems are successively built to produce a final total system Highest priority requirement is tackled first Once the incremented portion id developed, requirements for that increment are frozen Advantages Easy to Identify error Flexibility is high, less expensive to change requirements and scope Easier to test and debug Design and development is easy as modules are handled individually. Disadvantages Good planning is required Problems might cause due to all requirements are handled in different modules. Rectifying a problem in one unit requires correction in all the units and consumes a lot of time 25 LOVELY PROFESSIONAL UNIVERSITY Notes SOFTWARE ENGINEERING PRACTICES ______________________________________________ 2.9 Agile method of software development Agile Methodology Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. It is a practice that promotes continuous iteration of development and testing throughout the software development lifecycle of the project. Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. It is a practice that promotes continuous iteration of development and testing throughout the software development lifecycle of the project. Agility is not merely reaction, but also action. It is ability to react, to respond quickly and effectively to both anticipated and unanticipated changes in the business environment. Agility means being responsive or flexible within a defined context. Agile vs. Traditional Models Agile model is based on the adaptive software development methods. Traditional SDLC models like the waterfall model are based on a predictive approach. Predictive methods entirely depend on the requirement analysis and planning done in the beginning of cycle. Agile uses an adaptive approach where there is no detailed planning and there is clarity on future tasks only in respect of what features need to be developed. Agile Process Model It is a combination of iterative and incremental process models with focus on process adaptability and customer satisfaction by rapid delivery of working software product. Agile Methods break the product into small incremental builds. These builds are provided in iterations. Agile process model can be implemented with the help of various methods: Extreme Programming DSDM Essential Unified Process Agile Data Method Agile Modeling Agile Unified Process Advantages of the Agile Models Promotes teamwork and cross training. Realistic approach to software development. Functionality can be developed rapidly and demonstrated. Resource requirements are minimum. Suitable for fixed or changing requirements Delivers early partial working solutions. Disadvantages of the Agile Models Not suitable for complex problem More risk of sustainability, maintainability and extensibility. Depends heavily on customer interaction. Strict delivery management dictates the scope, functionality to be delivered, and adjustments to meet the deadlines. Summary A software process is a set of activities, together with ordering constraints a mong them, such that if the activities are performed properly and in accordance with the ordering constraints, the desired result is produced. Software Process framework is a set of guidelines, concepts and best practices that describes high level processes in software engineering. The sequence of activities specified by the process is typically at an abstract level because they have to be usable for a wide range of projects. A software process model is a simplified description of a software process, which is Notes presented from a particular perspective. LOVELY PROFESSIONAL UNIVERSITY 26  Unit 02: Software process models Notes In waterfall model each phase is well defined, has a starting and ending point, with identifiable deliveries to the next phase. In a prototype model, a working prototype is built with the available set of requirements such that it has limited functionalities, low reliability and performance. An iterative lifecycle model does not attempt to start with a full specification of requirements. Keywords Workflow Model : This shows the sequence of activities in the process along with their inputs, outputs and dependencies. Dataflow or Activity Model : This represents the process as a set of activities each of which carries out some data transformation. Design Phase : A Design phase is a phase in which a software solution to meet the requirements is designed. Prototype Model : It is a model in which a working prototype is built with the available set of requirements such that it has limited functionalities, low reliability and performance. Requirements Phase : A Requirements phase is a phase in which the requirements for the software are gathered and analyzed. Software Processes: Software processes are the activities involved in producing and evolving a software system. Software Process Framework: It is a set of guidelines, concepts and best practices that describes high level processes in software engineering. Software Process Model : A software process model is a simplified description of a software process, which is presented from a particular perspective Self Assessment 1. Which is not a SDLC phase? A. Design B. Coding C. Testing D. Coupling 2. Which is not a part of feasibility study? A. Time B. Operational C. Module D. Cost 3. Which is not a testing type? A. Unit B. Beta C. Cohesion D. Black box 4. Prototype model is____ A. Suitable where the project's requirements are not known in detail to customer B. It is a demo implementation of the actual product or system C. Used to allow the users evaluate developer proposals D. All of above 27 LOVELY PROFESSIONAL UNIVERSITY Notes SOFTWARE ENGINEERING PRACTICES ______________________________________________ 5. Which is not a part of prototype model phases? A. Requirement B. Design C. Process D. Implementation 6. Which is not a prototype model type? A. Evolutionary B. Beta C. Incremental D. Extreme 7. Waterfall model is____ A. It is linear sequential model B. It is the classic lifecycle model C. Introduced by Winston W. Royce in 1970 D. All of above 8. Stages in Waterfall model are_____ A. Design B. Implementation C. Testing and Deployment D. All of above 9. Information is gathered in ________ phase A. Design B. Coding C. Requirement analysis D. Maintenance 10. Incremental Model is____ A. Broken down into multiple standalone modules of software development cycle. B. Multiple development cycles take place C. Each iteration passes through the requirements, design, coding and testing phases D. All of above Answer for Self Assessment 1. D 2. C 3. C 4. D 5. C 6. B 7. D 8. D 9. C 10. D Review Questions 1. Explain the concept of software processes. 2. Describe the relation between Processes, Projects and Products. 3. Explain the concept of software process model with examples. 4. Discuss the number of different general models or paradigms of software development. 5. Discuss the characteristics of a Software Model. LOVELY PROFESSIONAL UNIVERSITY 28  Unit 02: Software process models Notes 6. Explain the working of waterfall model. 7. Describe the phases included in iterative model. 8. What is Agile Methodology? 9. Name few Agile Process Model. Further Reading Books Rajib Mall, Fundamentals of Software Engineering, 2nd Edition, PHI. Richard Fairpy, Software Engineering Concepts, Tata McGraw Hill, 1997. R.S. Pressman, Software Engineering – A Practitioner’s Approach, 5th Edition, Tata McGraw Hill Higher education. Sommerville, Software Engineering, 6th Edition, Pearson Education. http://www.ijcsi.org/papers/7-5-94-101.pdf http://people.sju.edu/~jhodgson/se/models.html http://www.ics.uci.edu/~wscacchi/Papers/SE-Encyc/Process-Models- SEEncyc.pdf https://www.tutorialspoint.com/ https://www.guru99.com/ 29 LOVELY PROFESSIONAL UNIVERSITY Aswani Kumar, Lovely Professional University Unit 03: Requirement Engineering Notes Unit 03: Requirement Engineering CONTENTS Objective Introduction 3.1 Requirement Engineering 3.2 Requirements Engineering Tasks 3.3 Types of requirement 3.4 Requirement Negotiation 3.5 Requirements Validation 3.6 Requirements Management Summary Keywords Self Assessment Answer for Self Assessment Review Questions Further Reading Objective After studying this unit, you will be able to: Describe requirement engineering task Explain requirement management Explain requirement analysis and stakeholder analysis Introduction Requirements define the "what" of a system rather than the "how." Understanding what the customer wants, analyzing the need, determining feasibility, negotiating a reasonable solution, clearly specifying the solution, validating the specifications, and managing the requirements as they are transformed into a working system are all covered by requirements engineering. As a result, requirements engineering is the systematic use of well-established ideas, methodologies, tools, and notations to characterize a proposed system's expected behavior and restrictions. In the engineering design process, requirements engineering refers to the process of identifying, documenting, and managing requirements. Understanding what the customer wants, analysing the need, determining feasibility, negotiating a reasonable solution, clearly specifying the solution, validating the specifications, and managing the requirements as they are transformed into a working system are all covered by requirement engineering. As a result, requirement engineering is the systematic use of well-established ideas, methodologies, tools, and notation to specify a proposed system's expected behaviour and restrictions. It is process to gather, defining, documenting, and maintaining the software requirements from client, analyze and document them is known as requirement engineering. Requirement engineering provides the appropriate mechanism to understand what the customer desires, analyz ing the need, and assessing feasibility, negotiating a reasonable solution. LOVELY PROFESSIONAL UNIVERSITY 30 Notes SOFTWARE ENGINEERING PRACTICES 3.1 Requirement Engineering The requirements engineering includes the following activities: Identification and documentation of customer and user’s needs. Creation of a document describing the external behavior and associated constraints that will satisfy those needs. Analysis and validation of the requirements document to ensure consistency, completeness and feasibility. Evolution of needs. The fundamental output of requirements engineering is the specification of requirements. It is a system requirement if it describes both hardware and software, and a software requirements specification if it solely provides software needs. The system is viewed as a black box in both of these scenarios. Requirements Specification A text, a graphical model, a prototype, or a combination of these can be used to specify requirements. Depending on the system being created, a standard template or a flexible methodology can be used to elicit system specifications. As a result of system and requirements engineering, a system specification is created. It offers information about the hardware, software, and database, among other things. It outlines the function as well as the constraints that must be met while creating a system. It also provides information about the system's input and output. Requirements Validation During the validation process, the work product created as a result of requirements engineering is evaluated for quality. Validation of requirements guarantees that all requirements have been written accurately, that inconsistencies and errors have been identified and addressed, and that the work result meets the process, project, and product standards. Although the requirements validation can be done in any way that leads to discovery of errors, the requirements can be examined against a checklist. Some of the checklist questions can be: Are the requirements clear or they can be misinterpreted? Is the source of the requirements identified? Has the final statement of requirement been verified against the source? Is the requirement quantitatively bounded? Is the requirement testable? Does the requirement violate domain constraints? These questions and their likes ensure that validation team does everything possible for a thorough review. Requirements Management Throughout the life of a computer-based system, requirements may alter. The operations that assist a project team in identifying, controlling, and tracking requirements and modifications to these requirements at any point during the project are referred to as requirements management. Identification is the first step in managing requirements. Traceability tables are developed once the criteria have been identified. Each criterion is linked to one or more aspects of the system or its surroundings in this table. They may be used as a requirements database to understand how a change in one requirement affects other components of the system under construction. A Brigade of Design & Construction Any engineering activity's eventual purpose is to provide some form of documentation. The design documentation is supplied to the manufacturing team when a design effort is completed. This is a different group of people with different abilities than the design team. The production team can proceed to produce the product if the design documentation actually represent a complete design. In fact, they can develop a large portion of the product without the help of the designers. After 31 LOVELY PROFESSIONAL UNIVERSITY  Unit 03: Requirement Engineering Notes evaluating the software development life cycle today, it appears that the source code listings are the only software documentation that appears to meet the criteria of an engineering design. Software runs on computers. It is a sequence of ones and zeros. Software is not a program listing. A program listing is a document that represents a software design. Compilers, linkers, and interpreters actually build (manufacture) software. Software is very cheap to build. You just press a button. Software is expensive to design because it is complicated and all phases of the development cycle are part of the design process. Programming is a design activity; a good software design process recognizes this and does not hesitate to code when coding makes sense. More often than you might think, coding makes sense. Often, the process of coding the design reveals flaws and the need for additional design work. It is preferable if this occurs sooner rather than later. Testing and debugging are design tasks, and they are the engineering equivalents of design validation and refinement. They can't be taken advantage of. Because it is cheaper to design software and test it than to prove it, formal validation methods aren't very useful. Think about it. When you are programming, you are doing detailed design. The manufacturing team for software is your compiler or interpreter. The source is the only complete specification of what the software will do. Design is present whenever objects are developed for humans to utilize. Design can be done systematically or haphazardly, intentionally or unconsciously. However, when people create software – or any other product – they make decisions and build objects with the purpose of knowing what those objects will do and how they will be viewed and used.. The education of computer professionals has often concentrated on the understanding of computational mechanisms, and on engineering methods that are intended to ensure that the mechanisms behave as the programmer intends. The focus is on the objects being designed: the hardware and software. The primary concern is to implement a specified functionality efficiently. When software engineers or programmers say that a piece of software works, they typically mean that it is robust, is reliable, and meets its functional specification. These concerns are indeed important. Any designer who ignores them does so at the risk of disaster. But this inward-looking perspective, with its focus on function and construction, is one-sided. To design software that really works, we need to move from a constructor’s-eye view to a designer’s- eye view, taking the system, the users, and the context all together as a starting point. 3.2 Requirements Engineering Tasks The processes used for RE vary widely depending on the application domain, the people involved and the organization developing the requirements. However, there are a number of generic activities common to most processes: Inception Requirements elicitation Negotiation Requirements specification Requirements validation Requirement Management Requirements Reviews/Inspections Regular reviews should be held while the requirements definition is being formulated. Both client and contractor staff should be involved in reviews. (Stakeholders) Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage. Review Check-list Verifiability: Is the requirement realistically testable? Comprehensibility: Is the requirement properly understood? Traceability: Is the origin of the requirement clearly stated? LOVELY PROFESSIONAL UNIVERSITY 32 Notes SOFTWARE ENGINEERING PRACTICES Adaptability: Can the requirement be changed with minimum impact on other Notes requirements? (Especially when change is anticipated!) Elicitation Involves working with customers to learn about the application domain, the services needed a nd the system’s operational constraints. May also involve end-users, managers, maintenance personnel, domain experts, trade unions, etc. (That is, any stakeholders.) Problems of Elicitation and Analysis Getting all, and only, the right people involved. Stakeholders often don’t know what they really want (“I’ll know when I see it”). Stakeholders express requirements in their own terms. Stakeholders may have conflicting requirements. Requirements change during the analysis process. Organizational and political factors may influence the system requirements. The Elicitation and Analysis Process Viewpoint-oriented Elicitation Stakeholders represent different ways of looking at a problem (viewpoints). A multi-perspective analysis is important, as there is no single correct way to analyze system requirements, provides a natural way to structure the elicitation process. Types of Viewpoints: Data sources or sinks: Viewpoints are responsible for producing or consuming data. Analysis involves checking that assumptions about sources and sinks are valid. Representation frameworks: Viewpoints represented by different system models (i.e., dataflow, ER, finite state machine, etc.). Each model yields different insights into the system. Receivers of services: Viewpoints are external to the system and receive services from it, Natural to think of end-users as external service receivers. Method-based RE “Structured methods” to elicit, analyse, and document requirements. Examples include: Ross’ Structured Analysis (SA), 33 LOVELY PROFESSIONAL UNIVERSITY  Unit 03: Requirement Engineering Notes Volere Requirements Process (www.volere.co.uk). Knowledge Acquisition and Sharing for Requirement Engineering (KARE) (www.kare.org), Somerville’s Viewpoint-Oriented Requirements Definition (VORD), and The baut’s Scenario-Based Requirements Engineering (SBRE)˜ Scenarios Depict examples or scripts of possible system behavior. People often relate to these more readily than to abstract statements of requirements, particularly useful in dealing with fragmentary, incomplete, or conflicting requirements. Scenario Descriptions System state at the beginning of the scenario, Sequence of events for a specific case of some generic task the system is required to accomplish. Any relevant concurrent activities System state at the completion of the scenario. Scenario-Based Requirements Engineering (SBRE) Marcel support environment allows rapid construction of an operational specification of the desired system and its environment. Based on a forward chaining rule-based language, an interpreter executes the specification to produce natural language based scenarios of system behavior. UML Use-cases and Sequence Diagrams Use-cases are a graphical notation for representing abstract scenarios in the UML. They identify the actors in an interaction and describe the interaction itself. A set of use-cases should describe all types of interactions with the system. Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing. Social and Organizational Factors All software systems are used in a social and organizational context. This can influence or even dominate the system requirements. Good analysts must be sensitive to these factors, but there is currently no systematic way to tackle their analysis. Ethnography Social scientist spends considerable time observing and analyzing how people actually work. People do not have to explain or articulate what they do. Social and organizational factors of importance may be observed. Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models. Focused Ethnography Developed during a project studying the air traffic control process Combines ethnography with prototyping. Prototype development raises issues, which focus the ethnographic analysis. Problem with ethnography alone: it studies existing practices, which may not be relevant when a new system is put into place. 3.3 Types of requirement User requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints Written for customers. System requirements A structured document setting out detailed descriptions of the system’s functions, services and operational constraints, Defines what should be implemented so may be part of a contract between client and contractor. Functional requirements Statements of services the system should provide how the system should react to particular inputs and how the system should behave in particular situations. May state what the system should not do. Describe functionality or system services. Depend on the type of software, expected users and the type of system where the software is used. Functional user requirements may be high level LOVELY PROFESSIONAL UNIVERSITY 34 Notes SOFTWARE ENGINEERING PRACTICES statements of what the system should do. Functional system requirements should describe the system services in detail. Non-functional requirement Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Often apply to the system as a whole rather than individual features or services. These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. Process requirements may also be specified mandating a particular IDE, programming language or development method. Types of non-functional requirement Product requirement Efficiency Dependability Security Usability Organizational requirement Operational Development External requirements Regulatory Ethical Non-functional classifications Product requirements Requirements which specify that the delivered product must behave in particular way e.g. execution speed reliability, etc. Organizational requirements Requirements which are a consequence of organizational policies and procedures e.g. process standards used, implementation requirements, etc. External requirements Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc. 3.4 Requirement Negotiation After they have been collected, requirements must be analyzed to obtain a satisfactory understanding of the customer’s need and negotiated to establish an agreed set of consistent (unambiguous, correct, complete, etc.) requirements. The requirements negotiation process is expensive and time-consuming, requiring very experienced personnel exercising considerable judgment. This is exacerbated by the fact that the requirements negotiation process is not sufficiently structured that an automated requirements negotiation methodology would be appropriate. Requirement Specification For most engineering professions, the term “specification” refers to the assignment of numerical values or limits to a product’s design goals. Typical physical systems have a relatively small number of such values. Typical software has a large number of requirements, and the emphasis is shared between performing the numerical quantification and managing the complexity of interaction among the large number of requirements. For complex systems, particularly those involving substantial non-software components, as many as three different types of documents are produced: system definition,