Introduction To Software Engineering (SEN 201) LECTURE MATERIAL PDF

INTRODUCTION TO SOFTWARE ENGINEERING (SEN 201) COURSE MATERIAL INTRODUCTION We can’t run the modern world without software. National infrastructures and utilities are controlled by computer-based systems and most electrical products include a computer and controlling sof...

INTRODUCTION TO SOFTWARE ENGINEERING (SEN 201) COURSE MATERIAL INTRODUCTION We can’t run the modern world without software. National infrastructures and utilities are controlled by computer-based systems and most electrical products include a computer and controlling software. Industrial manufacturing and distribution, the financial system, entertainment (including the music industry, computer games, film and television) are completely computerized, and they are software intensive. Therefore, the term software engineering is composed of two words, software and engineering. Software is more than just a program code. A program is an executable code, which serves some computational purpose. Software is considered to be a collection of executable programming code, associated libraries and documentations. Software, when made for a specific requirement is called software product. Engineering on the other hand, is all about developing products, using well-defined, scientific principles and methods. So, we can define software engineering as an 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. IEEE defines software engineering as: The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software. We can alternatively view it as a systematic collection of past experience. The experience is arranged in the form of methodologies and guidelines. A small program can be written without using software engineering principles. But if one wants to develop a large software product, then software engineering principles are absolutely necessary to achieve a good quality software cost effectively. Without using software engineering principles it would be difficult to develop large programs. In industry it is usually needed to develop large programs to accommodate multiple functions. A problem with developing such large commercial programs is that the complexity and difficulty levels of the programs increase exponentially with their sizes. Software engineering helps to reduce this programming complexity. 1 Software engineering principles use two important techniques to reduce problem complexity: abstraction and decomposition. The principle of abstraction implies that a problem can be simplified by omitting irrelevant details. In other words, the main purpose of abstraction is to consider only those aspects of the problem that are relevant for certain purpose and suppress other aspects that are not relevant for the given purpose. Once the simpler problem is solved, then the omitted details can be taken into consideration to solve the next lower-level abstraction, and so on. Abstraction is a powerful way of reducing the complexity of the problem. The other approach to tackle problem complexity is decomposition. In this technique, a complex problem is divided into several smaller problems and then the smaller problems are solved one by one. However, in this technique any random decomposition of a problem into smaller parts will not help. The problem has to be decomposed such that each component of the decomposed problem can be solved independently and then the solution of the different components can be combined to get the full solution. A good decomposition of a problem should minimize interactions among various components. If the different subcomponents are interrelated, then the different components cannot be solved separately and the desired reduction in complexity will not be realized. Software engineering is essential for the functioning of national and international societies. Software systems are abstract and intangible. They are not constrained by the properties of materials, governed by physical laws, or by manufacturing processes. This simplifies software engineering, as there are no natural limits to the potential of software. However, because of the lack of physical constraints, software systems can quickly become extremely complex, difficult to understand, and expensive to change. There are many different types of software systems, from simple embedded systems to complex, worldwide information systems. However, there are still many reports of software projects going wrong and ‘software failures’. Software engineering is criticized as inadequate for modern software development. However, many of these so-called software failures are a consequence of two factors: 1. Increasing demands: As new software engineering techniques help us to build larger, more complex systems, the demands change. Systems have to be built and delivered more quickly; larger, even more complex systems are required; systems have to have new capabilities that were previously thought to be impossible. Existing software engineering methods cannot cope and new software engineering techniques have to be developed to meet new these new demands. 2. Low expectations It is relatively easy to write computer programs without using software engineering methods and techniques. Many companies have drifted into software development as their products and services have evolved. They do not use software engineering methods in their everyday work. Consequently, their software is often more expensive and less reliable than it should be. We need better software engineering education and training to address this problem. 2 Many people think that software is simply another word for computer programs. However, when we are talking about software engineering, software is not just the programs themselves but also all associated documentation and configuration data that is required to make these programs operate correctly. Some Likely Question and Answer 1. What is software? Computer programs and associated documentation. Software products may be developed for a particular customer or may be developed for a general market. 2. What are the attributes of good software? Good software should deliver the required functionality and performance to the user and should be maintainable, dependable, and usable. 3. What is software engineering? Software engineering is an engineering discipline that is concerned with all aspects of software production. 4. What are the fundamental software engineering activities? Software specification, software development, software validation, and software evolution. 5. What is the difference between software engineering and computer science? Computer science focuses on theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software. 6. What is the difference between software engineering and system engineering? System engineering is concerned with all aspects of computer-based systems development including hardware, software, and process engineering. Software engineering is part of this more general process. 7. What are the key challenges facing software engineering? Coping with increasing diversity, demands for reduced delivery times, and developing trustworthy software. 8. What are the best software engineering techniques and methods? While all software projects have to be professionally managed and developed, different techniques are appropriate for different types of system. For example, games should always be developed using a series of prototypes whereas safety critical control systems require a complete and analyzable specification to be developed. You can’t, therefore, say that one method is better than another. 9. What differences has the Web made to software engineering? The Web has led to the availability of software services and the possibility of developing highly distributed service-based systems. Web-based systems development has led to important advances in programming languages and software reuse. 3  MODULE ONE THE PRODUCT: COMPUTER SOFTWARE Computer software is the product that software engineers design and build. It encompasses programs that execute within a computer of any size and architecture, documents that encompass hard-copy and virtual forms, and data that combine numbers and text but also includes representations of pictorial, video, and audio information. Software engineers build it, and virtually everyone in the industrialized world uses it either directly or indirectly. 1.1 The Evolving Role of Software Today, software takes on a dual role. It is a product and, at the same time, the vehicle for delivering a product. As a product, it delivers the computing potential embodied by computer hardware or, more broadly, a network of computers that are accessible by local hardware. Whether it resides within a cellular phone or operates inside a mainframe computer, software is an information transformer producing, managing, acquiring, modifying, displaying, or transmitting information that can be as simple as a single bit or as complex as a multimedia presentation. As the vehicle used to deliver the product, software acts as the basis for the control of the computer (operating systems), the communication of information (networks), and the creation and control of other programs (software tools and environments). 1.2 Software Definition In 1970, less than 1 percent of the public could have intelligently described what "computer software" meant. Today, most professionals and many members of the public at large feel that they understand software. What is software? Software is: (1) instructions (computer programs) that when executed provide desired function and performance, (2) data structures that enable the programs to adequately manipulate information; and (3) documents that describe the operation and use of the programs. 1.3 Kinds of software products Software engineers are concerned with developing software products (i.e., software which can be sold to a customer). There are two kinds of software products: 4  1. Generic products: These are stand-alone systems that are produced by a development organization and sold on the open market to any customer who is able to buy them. Examples of this type of product include software for PCs such as databases, word processors, drawing packages, and project- management tools. 2. Customized products: These are systems that are requested by a particular customer. A software contractor develops the software especially for that customer. Examples of this type of software include control systems for electronic devices, systems written to support a particular business process, and air traffic control systems. 1.4 Software Characteristics To gain an understanding of software (and ultimately an understanding of software engineering), it is important to examine the characteristics of software that make it different from other things that human beings build. Software is a logical rather than a physical system element. Therefore, software has the following characteristics: 1. Software is developed or engineered; it is not manufactured in the classical sense: Although some similarities exist between software development and hardware manufacture, the two activities are fundamentally different. In both activities, high quality is achieved through good design, but the manufacturing phase for hardware can introduce quality problems that are non-existent (or easily corrected) for software. 2. Software does not wear out: As time passes, the failure rate of hardware components rises again as it suffers from the cumulative effects of dust, vibration, abuse, temperature extremes, and many other environmental maladies. Stated simply, the hardware begins to wear out. Software is not susceptible to the environmental maladies that cause hardware to wear out. Software does not wear out but it does deteriorate. 3. Although the industry is moving toward component-based assembly, most software continues to be custom built. The reusable components are created so that the engineer can concentrate on the truly innovative elements of a design, that is, the parts of the design that represent something new. 4. Operational: This tells us how well software works in operations, and it can be measured on: budget, usability, efficiency, correctness, functionality, dependability, security, safety. 5. Transitional: This aspect is important when the software is moved from one platform to another: portability, interoperability, reusability, adaptability. 5  6. Maintenance: This aspect briefs about how well a software has the capabilities to maintain itself in the everchanging environment: modularity, maintainability, flexibility, scalability In summary, Software engineering is a branch of computer science, which uses well- defined engineering concepts required to produce efficient, durable, scalable, in- budget and on-time software products. 1.5 Software Applications Software may be applied in any situation for which a prespecified set of procedural steps (i.e., an algorithm) has been defined (notable exceptions to this rule are expert system software and neural network software). Information content and determinacy are important factors in determining the nature of a software application. The following software areas indicate the breadth of potential applications: 1. System software: System software is a collection of programs written to service other programs. Some system software (e.g., compilers, editors, and file management utilities) process complex, but determinate, information structures. Other systems applications (e.g., operating system components, drivers, telecommunications processors) process largely indeterminate data. In either case, the system software area is characterized by heavy interaction with computer hardware; heavy usage by multiple users; concurrent operation that requires scheduling, resource sharing, and sophisticated process management; complex data structures; and multiple external interfaces. 2. Real-time software: Software that monitors/analyzes/controls real-world events as they occur is called real time. Elements of real-time software include a data gathering component that collects and formats information from an external environment, an analysis component that transforms information as required by the application, a control/output component that responds to the external environment, and a monitoring component that coordinates all other components so that real-time response (typically ranging from 1 millisecond to 1 second) can be maintained. 3. Business software: Business information processing is the largest single software application area. Discrete "systems" (e.g., payroll, accounts receivable/payable, inventory) have evolved into management information system (MIS) software that accesses one or more large databases containing business information. Applications in this area restructure existing data in a way that facilitates business operations or management decision making. In addition to conventional data processing application, business software applications also encompass interactive computing (e.g., point-of-sale transaction processing). 4. Engineering and scientific software: Engineering and scientific software have been characterized by "number crunching" algorithms. Applications range 6  from astronomy to volcanology, from automotive stress analysis to space shuttle orbital dynamics, and from molecular biology to automated manufacturing. However, modern applications within the engineering/scientific area are moving away from conventional numerical algorithms. Computer-aided design, system simulation, and other interactive applications have begun to take on real-time and even system software characteristics. 5. Embedded software: Intelligent products have become commonplace in nearly every consumer and industrial market. Embedded software resides in read- only memory and is used to control products and systems for the consumer and industrial markets. Embedded software can perform very limited and esoteric functions (e.g., keypad control for a microwave oven) or provide significant function and control capability (e.g., digital functions in an automobile such as fuel control, dashboard displays, and braking systems). 6. Personal computer software: The personal computer software market has burgeoned over the past two decades. Word processing, spreadsheets, computer graphics, multimedia, entertainment, database management, personal and business financial applications, external network, and database access are only a few of hundreds of applications. 7. Artificial intelligence software: Artificial intelligence (AI) software makes use of nonnumerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis. Expert systems, also called knowledge-based systems, pattern recognition (image and voice), artificial neural networks, theorem proving, and game playing are representative of applications within this category. 7  MODULE TWO SOFTWARE ENGINEERING Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use. In this definition, there are two key phrases: 1. Engineering discipline: The Engineers make things work. They apply theories, methods, and tools where these are appropriate. However, they use them selectively and always try to discover solutions to problems even when there are no applicable theories and methods. Engineers also recognize that they must work to organizational and financial constraints so they look for solutions within these constraints. 2. All aspects of software production: Software engineering is not just concerned with the technical processes of software development. It also includes activities such as software project management and the development of tools, methods, and theories to support software production. 2.1 Essential attributes of good software The essential/important attributes of a good software are the following: 1. Maintainability: Software should be written in such a way so that it can evolve to meet the changing needs of customers. This is a critical attribute because software change is an inevitable requirement of a changing business environment. 2. Dependability and security: Software dependability includes a range of characteristics including reliability, security, and safety. Dependable software should not cause physical or economic damage in the event of system failure. Malicious users should not be able to access or damage the system. 3. Efficiency: Software should not make wasteful use of system resources such as memory and processor cycles. Efficiency therefore includes responsiveness, processing time, memory utilization, etc. 4. Acceptability: Software must be acceptable to the type of users for which it is designed. This means that it must be understandable, usable, and compatible with other systems that they use. 2.2 Importance of Software engineering Software engineering is important for two reasons: 1. More and more, individuals and society rely on advanced software systems. We need to be able to produce reliable and trustworthy systems economically and quickly. 8  2. It is usually cheaper, in the long run, to use software engineering methods and techniques for software systems rather than just write the programs as if it was a personal programming project. For most types of systems, the majority of costs are the costs of changing the software after it has gone into use. 2.3 Need of Software Engineering The need of software engineering arises because of higher rate of change in user requirements and environment on which the software is working. 1. Large software: It is easier to build a wall than to a house or building, likewise, as the size of software become large engineering has to step to give it a scientific process. 2. Scalability: If the software process were not based on scientific and engineering concepts, it would be easier to re-create new software than to scale an existing one. 3. Cost: As hardware industry has shown its skills and huge manufacturing has lower down the price of computer and electronic hardware. But the cost of software remains high if proper process is not adapted. 4. Dynamic Nature: The always growing and adapting nature of software hugely depends upon the environment in which the user works. If the nature of software is always changing, new enhancements need to be done in the existing one. This is where software engineering plays a good role. 5. Quality Management: Better process of software development provides better and quality software product. 2.4 Software engineering ethics Like other engineering disciplines, software engineering is carried out within a social and legal framework that limits the freedom of people working in that area. As a software engineer, you must accept that your job involves wider responsibilities than simply the application of technical skills. You must also behave in an ethical and morally responsible way if you are to be respected as a professional engineer. It also means that you should uphold normal standards of honesty and integrity. You should not use your skills and abilities to behave in a dishonest way or in a way that will bring disrepute to the software engineering profession. However, there are areas where standards of acceptable behavior are not bound by laws but by the more tenuous notion of professional responsibility. Some of these are: 1. Confidentiality: You should normally respect the confidentiality of your employers or clients irrespective of whether or not a formal confidentiality agreement has been signed. 9 2. Competence: You should not misrepresent your level of competence. You should not knowingly accept work that is outside your competence. 3. Intellectual property rights: You should be aware of local laws governing the use of intellectual property such as patents and copyright. You should be careful to ensure that the intellectual property of employers and clients is protected. 4. Computer misuse: You should not use your technical skills to misuse other people’s computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses or other malware). 10  MODULE THREE THE PROCESS: SOFTWARE DEVELOPMENT LIFE CYCLE Software Development Life Cycle (SDLC) is a well-defined, structured sequence of stages in software engineering to develop the intended software product. 3.1 SDLC Activities SDLC provides a series of steps to be followed to design and develop a software product efficiently. SDLC framework includes the following steps: Figure 3.1: SDLC framework Communication: This is the first step where the user initiates the request for a desired software product. He contacts the service provider and tries to negotiate the terms. He submits his request to the service providing organization in writing. Requirement Gathering: This step onwards the software development team works to carry out the project. The team holds discussions with various stakeholders from problem domain and tries to bring out as much information as possible on their requirements. The requirements are contemplated and segregated into user 11 requirements, system requirements and functional requirements. The requirements are collected using a number of practices as given: a. studying the existing or obsolete system and software b. conducting interviews of users and developers c. referring to the database d. collecting answers from the questionnaires. Feasibility Study: After requirement gathering, the team comes up with a rough plan of software process. At this step the team analyzes if the software can be made to fulfill all requirements of the user and if there is any possibility of the software being no more useful. If the project is financially, practically and technologically feasible for the organization to take up, they take up the project else they let it go. System Analysis: At this step the developers decide a roadmap of their plan and try to bring up the best software model suitable for the project. System analysis includes understanding of software product limitations, learning system related problems or changes to be done in existing systems beforehand, identifying and addressing the impact of project on organization and personnel etc. The project team analyzes the scope of the project and plans the schedule and resources accordingly. Software Design: Next step is to bring down whole knowledge of requirements and analysis on the desk and design the software product. The inputs from users and information gathered in requirement gathering phase are the inputs of this step. The output of this step comes in the form of two designs; logical design and physical design. Engineers produce meta-data and data dictionaries, logical diagrams, data- flow diagrams and in some cases pseudo codes. Coding: This step is also known as programming phase. The implementation of software design starts in terms of writing program code in the suitable programming language and developing error-free executable programs efficiently. Testing: An estimate says that 50% of whole software development process should be tested. Errors may ruin the software from critical level to its own removal. Software testing is done while coding by the developers and thorough testing is conducted by testing experts at various levels of code such as module testing, program testing, product testing, in-house testing and testing the product at user’s end. Early discovery of errors and their remedy is the key to reliable software. Integration: Software may need to be integrated with the libraries, databases and other program(s). This stage of SDLC is involved in the integration of software with outer world entities. Implementation: This means installing the software on user machines. At times, software needs post-installation configurations at user end. Software is tested for portability and adaptability and integration related issues are solved during implementation. Operation and Maintenance: This phase confirms the software operation in terms of more efficiency and less errors. If required, the users are trained on, or aided with the 12 documentation on how to operate the software and how to keep the software operational. The software is maintained timely by updating the code according to the changes taking place in user end environment or technology. This phase may face challenges from hidden bugs and real-world unidentified problems. Disposition: As time elapses, the software may decline on the performance front. It may go completely obsolete or may need intense up gradation. Hence a pressing need to eliminate a major portion of the system arises. This phase includes archiving data and required software components, closing down the system, planning disposition activity and terminating system at appropriate end-of-system time. 3.2 The Need for a Software Life Cycle Model The development team must identify a suitable life cycle model for the particular project and then adhere to it. Without using of a particular life cycle model, the development of a software product would not be in a systematic and disciplined manner. When a software product is being developed by a team there must be a clear understanding among team members about what and when to do. Otherwise, it would lead to chaos and project failure. This problem can be illustrated by using an example. Suppose a software development problem is divided into several parts and the parts are assigned to the team members, and the team members are allowed the freedom to develop the parts assigned to them in whatever way they like. It is possible that one member might start writing the code for his part, another might decide to prepare the test documents first, and some other engineer might begin with the design phase of the parts assigned to him. This would be one of the perfect recipes for project failure. A software life cycle model defines entry and exit criteria for every phase. A phase can start only if its phase-entry criteria have been satisfied. So, without software life cycle model the entry and exit criteria for a phase cannot be recognized. Without software life cycle models, it becomes difficult for software project managers to monitor the progress of the project. 3.3 Software Development Paradigm (Software Process) A software process is a set of related activities that leads to the production of a software product. These activities may involve the development of software from scratch in a standard programming language like Java or C. However, business applications are not necessarily developed in this way. New business software is now often developed by extending and modifying existing systems or by configuring and integrating off-the-shelf software or system components. There are many different software processes but all must include four activities that are fundamental to software engineering: 13  1. Software specification: The functionality of the software and constraints on its operation must be defined. 2. Software design and implementation: 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. When we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing a user interface, etc., and the ordering of these activities. However, as well as activities, process descriptions may also include: 1. Products, which are the outcomes of a process activity. For example, the outcome of the activity of architectural design may be a model of the software architecture. 2. Roles, which reflect the responsibilities of the people involved in the process. Examples of roles are project manager, configuration manager, programmer, etc. 3. Pre- and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced. For example, before architectural design begins, a pre-condition may be that all requirements have been approved by the customer; after this activity is finished, a post-condition might be that the UML models describing the architecture have been reviewed. Software processes are complex and, like all intellectual and creative processes, rely on people making decisions and judgments. There is no ideal process and most organizations have developed their own software development processes. Processes have evolved to take advantage of the capabilities of the people in an organization and the specific characteristics of the systems that are being developed. For some systems, such as critical systems, a very structured development process is required. For business systems, with rapidly changing requirements, a less formal, flexible process is likely to be more effective. Generally, you need to find a balance between plan-driven and agile processes. Although there is no ‘ideal’ software process, there is scope for improving the software process in many organizations. Some of the existing process models are: Waterfall model, Incremental model, spiral, prototype models, among others. 3.3.1 Classical Waterfall Model Classical waterfall model (popularly known as waterfall model) is the simplest model of software development paradigm. It says the all the phases of SDLC will function one after another in a linear manner. That is, when the first phase is finished then only the second phase will start and so on. 14  Figure 3.2: Waterfall Model This model assumes that everything is carried out and taken place perfectly as planned in the previous stage and there is no need to think about the past issues that may arise in the next phase. Waterfall model does not work smoothly if there are some issues left at the previous step. The sequential nature of model does not allow us go back and undo or redo our actions. This model is best suited when developers already have designed and developed similar software in the past and is aware of all its domains as illustrated in Figure 3.2 above. Because of the cascade from one phase to another, this model is known as the ‘waterfall model’ or the linear sequential model or software life cycle. The waterfall model is an example of a plan-driven process—in principle, you must plan and schedule all of the process activities before starting work on them. The principal stages of the waterfall model directly reflect the fundamental development activities: 1. Requirements analysis and definition: The system’s services, constraints, and goals are established by consultation with system users. They are then defined in detail and serve as a system specification. 2. System and software design: The systems design process allocates the requirements to either hardware or software systems by establishing an overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships. 3. Implementation and unit testing: During this stage, the software design is realized as a set of programs or program units. Unit testing involves verifying that each unit meets its specification. 4. Integration and system testing: The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to the customer. 15  5. Operation and maintenance: Normally (although not necessarily), this is the longest life cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle, improving the implementation of system units and enhancing the system’s services as new requirements are discovered. In principle, the result of each phase is one or more documents that are approved (‘signed off’). The following phase should not start until the previous phase has finished. In practice, these stages overlap and feed information to each other. During design, problems with requirements are identified. During coding, design problems are found and so on. The software process is not a simple linear model but involves feedback from one phase to another. Documents produced in each phase may then have to be modified to reflect the changes made. During the final life cycle phase (operation and maintenance) the software is put into use. Errors and omissions in the original software requirements are discovered. Program and design errors emerge and the need for new functionality is identified. The system must therefore evolve to remain useful. Making these changes (software maintenance) may involve repeating previous process stages. The waterfall model is consistent with other engineering process models and documentation is produced at each phase. This makes the process visible so managers can monitor progress against the development plan. Its major problem is the inflexible partitioning of the project into distinct stages. Commitments must be made at an early stage in the process, which makes it difficult to respond to changing customer requirements. In principle, the waterfall model should only be used when the requirements are well understood and unlikely to change radically during system development. However, the waterfall model reflects the type of process used in other engineering projects. As is easier to use a common management model for the whole project, software processes based on the waterfall model are still commonly used. 3.3.2 Iterative Model This model leads the software development process in iterations. It projects the process of development in cyclic manner repeating every step after every cycle of SDLC process. Figure 3.3: Iterative Model 16 The software is first developed on very small scale and all the steps are followed which are taken into consideration. Then, on every next iteration, more features and modules are designed, coded, tested and added to the software. Every cycle produces a software, which is complete in itself and has more features and capabilities than that of the previous one. After each iteration, the management team can do work on risk management and prepare for the next iteration. Because a cycle includes small portion of whole software process, it is easier to manage the development process but it consumes more resources. Key features of the iterative model include: i. Repetition of Activities: The development cycle is repeated, and each iteration involves a revisit to the stages of planning, designing, implementing, testing, and evaluating. ii. Incremental Development: The software is built incrementally, with each iteration adding new features or refining existing ones. This allows for the delivery of a partial but functional product after each iteration. iii. Feedback Mechanism: Iterations facilitate a continuous feedback loop. Stakeholders, including end-users and clients, provide feedback after each cycle. This feedback is then used to make improvements and adjustments in subsequent iterations. 3.3.3 Incremental Model (Iterative Enhancement Model) This approach interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with each version adding functionality to the previous version. Incremental development is based on the idea of developing an initial implementation, exposing this to user’s comment and evolving it through several versions until an adequate system has been developed. Specification, development, and validation activities are interleaved rather than separate, with rapid feedback across activities. 17  Figure 3.4: Incremental Incremental software development, which is a fundamental part of agile approaches, is better than a waterfall approach for most business, e-commerce, and personal systems. Incremental development reflects the way that we solve problems. We rarely work out a complete problem solution in advance but move toward a solution in a series of steps, backtracking when we realize that we have made a mistake. By developing the software incrementally, it is cheaper and easier to make changes in the software as it is being developed. Each increment or version of the system incorporates some of the functionality that is needed by the customer. Generally, the early increments of the system include the most important or most urgently required functionality. This means that the customer can evaluate the system at a relatively early stage in the development to see if it delivers what is required. If not, then only the current increment has to be changed and, possibly, new functionality defined for later increments. Incremental development has three important benefits, compared to the waterfall model: 1. The cost of accommodating changing customer requirements is reduced. The amount of analysis and documentation that has to be redone is much less than is required with the waterfall model. 2. It is easier to get customer feedback on the development work that has been done. Customers can comment on demonstrations of the software and see how much has been implemented. Customers find it difficult to judge progress from software design documents. 3. More rapid delivery and deployment of useful software to the customer is possible, even if all of the functionality has not been included. Customers are able to use and gain value from the software earlier than is possible with a waterfall process. 18 Incremental development in some form is now the most common approach for the development of application systems. This approach can be either plan-driven, agile, or, more usually, a mixture of these approaches. In a plan-driven approach, the system increments are identified in advance; if an agile approach is adopted, the early increments are identified but the development of later increments depends on progress and customer priorities. From a management perspective, the incremental approach has two problems: 1. The process is not visible. Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system. 2. System structure tends to degrade as new increments are added. Unless time and money are spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly. Key characteristics of an incremental model include: i. Progressive Development: The project is divided into small, manageable parts or increments. Each increment represents a portion of the overall system functionality. ii. Iterative Process: Each increment goes through a cycle of development, testing, and deployment. After one increment is completed, the development team moves on to the next one. iii. Feedback Loop: The incremental model allows for feedback from users or stakeholders after each increment. This feedback is then incorporated into the subsequent increments, allowing for adjustments and improvements. 19  Differences between Iterative and Incremental Model Here are the key differences between the iterative and incremental model (iterative enhancement model). Incremental Model (Iterative Enhanced Aspect Iterative Model Model) Repetitive cycles with Delivering the software Development Approach continuous refinement in functional parts Highly flexible and Offers flexibility but less Flexibility adaptive to changes than iterative Testing is integrated Testing is done for each Testing throughout the cycle increment Complete features are Features are delivered developed in each incrementally Delivery of Features iteration Risks are identified and Risks are managed as Risk Management addressed in each cycle increments are delivered Feedback is collected Feedback is obtained and incorporated after each increment Client Feedback regularly Offers visible progress Provides a clearer view with each delivered of the project's progress Project Visibility increment Dependencies can be Dependencies between Dependency identified and resolved increments need careful Management in each iteration management May take longer to Allows for partial deliver the complete delivery in shorter Completion Time product timeframes 20  Writing a draft and Building a house floor Example Analogy refining it multiple times by floor Detailed Examples of both incremental and iterative models in different Industries’ Software Development Iterative Approach: i. Start by developing a basic prototype of the entire software with placeholder features. ii. Refine and improve the software in cycles based on user feedback, fixing bugs, and enhancing usability. iii. Example: A messaging app where the prototype has basic chat functionality but improves through iterations by adding encryption, better user interface, and emojis. Incremental Approach: i. Start by delivering a single feature like text messaging. ii. Add voice messaging, then video calling, followed by file sharing, one at a time. iii. Example: A messaging app delivers the text chat feature first. Once completed and approved, the team starts adding video call functionality. Painting a Picture Iterative Approach: i. Start with a rough sketch of the entire painting (a basic prototype). ii. Gradually add colors, textures, and details across the entire canvas, revisiting and improving the painting until it’s complete. iii. Example: The artist works on the whole painting in cycles, refining it as feedback or new inspiration arises. Incremental Approach: i. Paint one section of the picture completely (e.g., the sky). ii. Move to the next section (e.g., the trees), perfecting each part before starting the next. iii. Example: The artist perfects the sky, then the mountains, and finally the foreground, completing each increment sequentially. Construction Industry Iterative Approach: i. Build the entire structure in basic form first (e.g., foundation, walls, and roof). 21  ii. Gradually add layers of refinement, such as painting, interior design, and landscaping. iii. Example: A house is constructed in rough form and then improved upon in stages until it’s livable and polished. Incremental Approach: i. Build and complete one part of the house entirely before moving to the next (e.g., first the garage, then the living room, then the bedrooms). ii. Example: A modular home where each room is completed before the next is started. Product Development (e.g., Mobile Phones) Iterative Approach: i. Design a prototype of the entire phone, including basic hardware and software. ii. Improve the hardware in stages (e.g., better camera, battery), while refining the software (e.g., adding new features) over time. iii. Example: A company launches a beta version of a phone and iteratively updates it with better features through software patches. Incremental Approach: i. Release the first model with basic functionality. ii. Add advanced features in future versions, like dual cameras in the next model and foldable screens in another. iii. Example: A phone company releases Model A with basic features, then adds high-end features incrementally in Models B and C. Education and Training Iterative Approach: i. Deliver the entire course in a basic form, covering all topics lightly in the first pass. ii. Revisit the topics in-depth during subsequent iterations, refining and expanding each section. iii. Example: A language class teaches basic grammar and vocabulary in the first month and refines pronunciation, complex sentences, and idioms in later months. Incremental Approach: i. Teach one topic at a time, completing it before moving to the next (e.g., grammar, then vocabulary, then pronunciation). 22 ii. Example: The teacher spends the first month on grammar, the second on vocabulary, and the third on pronunciation, perfecting each topic before advancing. 3.3.4 Prototyping Model A prototype is a toy implementation of the system. A prototype usually exhibits limited functional capabilities, low reliability, and inefficient performance compared to the actual software. A prototype is an initial version of a software system that is used to demonstrate concepts, try out design options, and find out more about the problem and its possible solutions. A prototype is usually built using several shortcuts. The shortcuts might involve using inefficient, inaccurate, or dummy functions. The shortcut implementation of a function, for example, may produce the desired results by using a table look-up instead of performing the actual computations. A prototype usually turns out to be a very crude version of the actual system. Following is the stepwise approach to design a software prototype: 1. Basic Requirement Identification: This step involves understanding the very basic product requirements especially in terms of user interface. The more intricate details of the internal design and external aspects like performance and security can be ignored at this stage. 2. Developing the initial Prototype: The initial Prototype is developed in this stage, where the very basic requirements are showcased and user interfaces are provided. These features may not exactly work in the same manner internally in the actual software developed and the workarounds are used to give the same look and feel to the customer in the prototype developed. 3. Review of the Prototype: The prototype developed is then presented to the customer and the other important stakeholders in the project. The feedback is collected in an organized manner and used for further enhancements in the product under development. 4. Revise and enhance the Prototype: The feedback and the review comments are discussed during this stage and some negotiations happen with the customer based on factors like, time and budget constraints and technical feasibility of actual implementation. The changes accepted are again incorporated in the new Prototype developed and the cycle repeats until customer expectations are met. 23  Figure 3.5: Prototype Model 3.3.5 Spiral Model The Spiral model of software development is shown in fig. 3.6. The diagrammatic representation of this model appears like a spiral with many loops. The exact number of loops in the spiral is not fixed. Each loop of the spiral represents a phase of the software process. For example, the innermost loop might be concerned with feasibility study. The next loop with requirements specification, the next one with design, and so on. Each phase in this model is split into four sectors (or quadrants) as shown in the fig.5. The following activities are carried out during each phase of a spiral model. Fig 3.6: Spiral Model 24 - First quadrant (Objective Setting) During the first quadrant, it is needed to identify the objectives of the phase. Examine the risks associated with these objectives. - Second Quadrant (Risk Assessment and Reduction) A detailed analysis is carried out for each identified project risk. Steps are taken to reduce the risks. For example, if there is a risk that the requirements are inappropriate, a prototype system may be developed. - Third Quadrant (Development and Validation) Develop and validate the next level of the product after resolving the identified risks. - Fourth Quadrant (Review and Planning) Review the results achieved so far with the customer and plan the next iteration around the spiral. Progressively more complete version of the software gets built with each iteration around the spiral. 3.3.6 RAD (Rapid Application Development) Model RAD is a linear sequential software development process model that emphasizes a concise development cycle using an element-based construction approach. If the requirements are well understood and described, and the project scope is a constraint, the RAD process enables a development team to create a fully functional system within a concise time period. RAD (Rapid Application Development) is a concept that allows products to be developed faster and of higher quality through: a. Gathering requirements using workshops or focus groups b. Prototyping and early, reiterative user testing of designs c. The re-use of software components d. A rigidly paced schedule that refers design improvements to the next product version e. Less formality in reviews and other team communication 25  Figure 3.7: RAD model The various phases of RAD are as follows: 1. 1.Business Modelling: The information flow among business functions is defined by answering questions like what data drives the business process, what data is generated, who generates it, where does the information go, who process it and so on. 2. Data Modelling: The data collected from business modeling is refined into a set of data objects (entities) that are needed to support the business. The attributes (character of each entity) are identified, and the relation between these data objects (entities) is defined. 3. Process Modelling: The information object defined in the data modeling phase are transformed to achieve the data flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting, or retrieving a data object. 4. Application Generation: Automated tools are used to facilitate construction of the software; even they use the 4th GL techniques. 5. Testing & Turnover: Many of the programming components have already been tested since RAD emphasis reuse. This reduces the overall testing time. But the new part must be tested, and all interfaces must be fully exercised. When to use RAD Model? o When the system should need to create the project that modularizes in a short span time (2-3 months). o When the requirements are well-known. o When the technical risk is limited. 26  o When there's a necessity to make a system, which modularized in 2-3 months of period. o It should be used only if the budget allows the use of automatic code generating tools. Advantage of RAD Model o This model is flexible for change. o In this model, changes are adoptable. o Each phase in RAD brings highest priority functionality to the customer. o It reduced development time. o It increases the reusability of features. Disadvantage of RAD Model o It required highly skilled designers. o All application is not compatible with RAD. o For smaller projects, we cannot use the RAD model. o On the high technical risk, it's not suitable. o Required user involvement 3.3.7 Big Bang Model In this model, developers do not follow any specific process. Development begins with the necessary funds and efforts in the form of inputs. And the result may or may not be as per the customer's requirement, because in this model, even the customer requirements are not defined. This model is ideal for small projects like academic projects or practical projects. One or two developers can work together on this model. Figure 3.8: Big bang model 27 When to use Big Bang Model? As discussed above, this model is required when this project is small like an academic project or a practical project. This method is also used when the size of the developer team is small and when requirements are not defined, and the release date is not confirmed or given by the customer. Advantage (Pros) of Big Bang Model: 1. There is no planning required. 2. Simple Model. 3. Few resources required. 4. Easy to manage. 5. Flexible for developers. Disadvantages (Cons) of Big Bang Model: 1. There are high risk and uncertainty. 2. Not acceptable for a large project. 3. If requirements are not clear that can cause very expensive. 3.3.8 V-Model V-Model is also referred to as the Verification and Validation Model. In this, each phase of SDLC must be completed before the next phase starts. It follows a sequential design process same as the waterfall model and the testing of the device is planned in parallel with a corresponding stage of development. Figure 3.9: V-model 28 Verification: It involves a static analysis method (review) done without executing code. It is the process of evaluation of the product development process to find whether specified requirements meet. Validation: It involves dynamic analysis method (functional, non-functional), testing is done by executing code. Validation is the process to classify the software after the completion of the development process to determine whether the software meets the customer expectations and requirements. So, V-Model contains Verification phases on one side of the Validation phases on the other side. Verification and Validation process is joined by coding phase in V-shape. Thus, it is known as V-Model. There are the various phases of Verification Phase of V-model: 1. Business requirement analysis: This is the first step where product requirements understood from the customer's side. This phase contains detailed communication to understand customer's expectations and exact requirements. 2. System Design: In this stage system engineers analyze and interpret the business of the proposed system by studying the user requirements document. 3. Architecture Design: The baseline in selecting the architecture is that it should understand all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology detail, etc. The integration testing model is carried out in a particular phase. 4. Module Design: In the module design phase, the system breaks down into small modules. The detailed design of the modules is specified, which is known as Low-Level Design 5. Coding Phase: After designing, the coding phase is started. Based on the requirements, a suitable programming language is decided. There are some guidelines and standards for coding. Before checking in the repository, the final build is optimized for better performance, and the code goes through many code reviews to check the performance. There are the various phases of Validation Phase of V-model: 1. Unit Testing: In the V-Model, 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, e.g., a program module. Unit testing verifies that the smallest entity can function correctly when isolated from the rest of the codes/ units. 2. Integration Testing: Integration Test Plans are developed during the Architectural Design Phase. These tests verify that groups created and tested independently can coexist and communicate among themselves. 3. System Testing: System Tests Plans are developed during System Design Phase. Unlike Unit and Integration Test Plans, System Tests Plans are composed 29  by the client’s business team. System Test ensures that expectations from an application developer are met. 4. Acceptance Testing: Acceptance testing is related to the business requirement analysis part. It includes testing the software product in user atmosphere. Acceptance tests reveal the compatibility problems with the different systems, which is available within the user atmosphere. It conjointly discovers the non- functional problems like load and performance defects within the real user atmosphere When to use V-Model? 1. When the requirement is well defined and not ambiguous. 2. The V-shaped model should be used for small to medium-sized projects where requirements are clearly defined and fixed. 3. The V-shaped model should be chosen when sample technical resources are available with essential technical expertise. Advantage (Pros) of V-Model: 1. Easy to Understand. 2. Testing Methods like planning, test designing happens well before coding. 3. This saves a lot of time. Hence a higher chance of success over the waterfall model. 4. Avoids the downward flow of the defects. 5. Works well for small plans where requirements are easily understood. Disadvantage (Cons) of V-Model: 1. Very rigid and least flexible. 2. Not a good for a complex project. 3. Software is developed during the implementation stage, so no early prototypes of the software are produced. 4. If any changes happen in the midway, then the test documents along with the required documents, has to be updated. 3.3.9 Reuse-oriented software engineering In the majority of software projects, there is some software reuse. This often happens informally when people working on the project know of designs or code that are similar to what is required. They look for these, modify them as needed, and incorporate them into their system. 30 This informal reuse takes place irrespective of the development process that is used. However, in the 21st century, software development processes that focus on the reuse of existing software have become widely used. Reuse-oriented approaches rely on a large base of reusable software components and an integrating framework for the composition of these components. Sometimes, these components are systems in their own right (COTS or commercial off-the-shelf systems) that may provide specific functionality such as word processing or a spreadsheet. A general process model for reuse-based development is shown in the figure above. Although the initial requirements specification stage and the validation stage are comparable with other software processes, the intermediate stages in a reuse-oriented process are different. These stages are: 1. Component analysis Given the requirements specification; a search is made for components to implement that specification. Usually, there is no exact match and the components that may be used only provide some of the functionality required. 2. Requirements modification During this stage, the requirements are analyzed using information about the components that have been discovered. They are then modified to reflect the available components. Where modifications are impossible, the component analysis activity may be re-entered to search for alternative solutions. 3. System design with reuse During this phase, the framework of the system is designed or an existing framework is reused. The designers take into account the components that are reused and organize the framework to cater for this. Some new software may have to be designed if reusable components are not available. 4. Development and integration Software that cannot be externally procured is developed, and the components and COTS systems are integrated to create the new system. System integration, in this model, may be part of the development process rather than a separate activity. Reuse-oriented software engineering has the obvious advantage of reducing the amount of software to be developed and so reducing cost and risks. It usually also leads to faster delivery of the software. However, requirements compromises are inevitable and this may lead to a system that does not meet the real needs of users. Furthermore, some control over the system evolution is lost as new versions of the reusable components are not under the control of the organization using them. 31 3.4 Process activities Real software processes are interleaved sequences of technical, collaborative, and managerial activities with the overall goal of specifying, designing, implementing, and testing a software system. Software developers use a variety of different software tools in their work. Tools are particularly useful for supporting the editing of different types of documents and for managing the immense volume of detailed information that is generated in a large software project. The four basic process activities of specification, development (design and implementation), validation, and evolution are organized differently in different development processes. In the waterfall model, they are organized in sequence, whereas in incremental development they are interleaved. How these activities are carried out depends on the type of software, people, and organizational structures involved. In extreme programming, for example, specifications are written on cards. Tests are executable and developed before the program itself. Evolution may involve substantial system restructuring or refactoring. 3.4.1 Software specification Software specification or requirements engineering is the process of understanding and defining what services are required from the system and identifying the constraints on the system’s operation and development. Requirements engineering is a particularly critical stage of the software process as errors at this stage inevitably lead to later problems in the system design and implementation. The requirements engineering process (Figure 3.10) aims to produce an agreed requirements document that specifies a system satisfying stakeholder requirements. Requirements are usually presented at two levels of detail. End-users and customers need a high-level statement of the requirements; system developers need a more detailed system specification. There are four main activities in the requirements engineering process: 1. Feasibility study: An estimate is made of whether the identified user needs may be satisfied using current software and hardware technologies. The study considers whether the proposed system will be cost-effective from a business point of view and if it can be developed within existing budgetary constraints. A feasibility study should be relatively cheap and quick. The result should inform the decision of whether or not to go ahead with a more detailed analysis. 2. Requirements elicitation and analysis: This is the process of deriving the system requirements through observation of existing systems, discussions with potential users and procurers, task analysis, and so on. This may involve the development of one or more system models and prototypes. These help you understand the system to be specified. 3. Requirements specification: Requirements specification is the activity of translating the information gathered during the analysis activity into a document that defines a set of requirements. Two types of requirements may be 32  included in this document. User requirements are abstract statements of the system requirements for the customer and end-user of the system; system requirements are a more detailed description of the functionality to be provided. 4. Requirements validation: This activity checks the requirements for realism, consistency, and completeness. During this process, errors in the requirements document are inevitably discovered. It must then be modified to correct these problems. Figure 3.10: The requirements engineering process 3.4.2 Software design and implementation (development) The implementation stage of software development is the process of converting a system specification into an executable system. It always involves processes of software design and programming but, if an incremental approach to development is used, may also involve refinement of the software specification. A software design is a description of the structure of the software to be implemented, the data models and structures used by the system, the interfaces between system components and, sometimes, the algorithms used. Figure 3.11 is an abstract model of this process showing the inputs to the design process, process activities, and the documents produced as outputs from this process. 33  Figure 3.11: A general model of the design process The diagram suggests that the stages of the design process are sequential. In fact, design process activities are interleaved. Feedback from one stage to another and consequent design rework is inevitable in all design processes. Figure 3.11 shows four activities that may be part of the design process for information systems: 1. Architectural design: where you identify the overall structure of the system, the principal components (sometimes called sub-systems or modules), their relationships, and how they are distributed. 2. Interface design: where you define the interfaces between system components. This interface specification must be unambiguous. With a precise interface, a component can be used without other components having to know how it is implemented. Once interface specifications are agreed, the components can be designed and developed concurrently. 3. Component design: where you take each system component and design how it will operate. This may be a simple statement of the expected functionality to be implemented, with the specific design left to the programmer. Alternatively, it may be a list of changes to be made to a reusable component or a detailed design model. The design model may be used to automatically generate an implementation. 4. Database design: where you design the system data structures and how these are to be represented in a database. Again, the work here depends on whether an existing database is to be reused or a new database is to be created. 34 3.4.3 Software Validation Software validation or, more generally, verification and validation (V&V) is intended to show that a system both conforms to its specification and that it meets the expectations of the system customer. Program testing, where the system is executed using simulated test data, is the principal validation technique. Validation may also involve checking processes, such as inspections and reviews, at each stage of the software process from user requirements definition to program development. Because of the predominance of testing, the majority of validation costs are incurred during and after implementation. Except for small programs, systems should not be tested as a single, monolithic unit. Figure 2.6 shows a three-stage testing process in which system components are tested then the integrated system is tested and, finally, the system is tested with the customer’s data. Ideally, component defects are discovered early in the process, and interface problems are found when the system is integrated. However, as defects are discovered, the program must be debugged and this may require other stages in the testing process to be repeated. Errors in program components, say, may come to light during system testing. The process is therefore an iterative one with information being fed back from later stages to earlier parts of the process. The stages in the testing process are: 1. Development testing: The components making up the system are tested by the people developing the system. Each component is tested independently, without other system components. Components may be simple entities such as functions or object classes, or may be coherent groupings of these entities. Test automation tools, such as JUnit that can re-run component tests when new versions of the component are created, are commonly used. 2. System testing: System components are integrated to create a complete system. This process is concerned with finding errors that result from unanticipated interactions between components and component interface problems. It is also concerned with showing that the system meets its functional and non-functional requirements, and testing the emergent system properties. For large systems, this may be a multi-stage process where components are integrated to form subsystems that are individually tested before these sub-systems are themselves integrated to form the final system. 3. Acceptance testing: This is the final stage in the testing process before the system is accepted for operational use. The system is tested with data supplied by the system customer rather than with simulated test data. Acceptance testing may reveal errors and omissions in the system requirements definition, because the real data exercise the system in different ways from the test data. Acceptance testing may also reveal requirements problems where the system’s facilities do not really meet the user’s needs or the system performance is unacceptable. 35 Figure 3.12: Testing phases in a plan-driven software process 3.4.4 Software evolution The flexibility of software systems is one of the main reasons why more and more software is being incorporated in large, complex systems. Once a decision has been made to manufacture hardware, it is very expensive to make changes to the hardware design. However, changes can be made to software at any time during or after the system development. Even extensive changes are still much cheaper than corresponding changes to system hardware. 3.4.5 Software Metrics and Measures Software metrics is a standard of measure that contains many activities which involve some degree of measurement. It can be classified into three categories: product metrics, process metrics, and project metrics. 1. Product metrics: It describe the characteristics of the product such as size, complexity, design features, performance, and quality level. 2. Process metrics: It can be used to improve software development and maintenance. Examples include the effectiveness of defect removal during development, the pattern of testing defect arrival, and the response time of the fix process. 3. Project metrics: This describes the project characteristics and execution. Examples include the number of software developers, the staffing pattern over the life cycle of the software, cost, schedule, and productivity. Some metrics belong to multiple categories. For example, the in-process quality metrics of a project are both process metrics and project metrics. 36 Advantages of Software Metrics 1. Reduction in cost or budget. 2. It helps to identify the particular area for improvising. 3. It helps to increase the product quality. 4. Managing the workloads and teams. 5. Reduction in overall time to produce the product,. 6. It helps to determine the complexity of the code and to test the code with resources. 7. It helps in providing effective planning, controlling and managing of the entire product. Disadvantages of Software Metrics 1. It is expensive and difficult to implement the metrics in some cases. 2. Performance of the entire team or an individual from the team can’t be determined. Only the performance of the product is determined. 3. Sometimes the quality of the product is not met with the expectation. 4. It leads to measure the unwanted data which is wastage of time. 5. Measuring the incorrect data leads to make wrong decision making. 3.4.6 Software Metrics: The metrics used to measure the efficiency of a software are of the following: i Size Metrics: LOC (Lines of Code), mostly calculated in thousands of delivered source code lines, denoted as KLOC. ii Function Point Count: It is measure of the functionality provided by the software. Function Point count defines the size of functional aspect of software. iii Complexity Metrics: McCabe’s Cyclomatic complexity quantifies the upper bound of the number of independent paths in a program, which is perceived as complexity of the program or its modules. It is represented in terms of graph theory concepts by using control flow graph. iv Quality Metrics: Defects, their types and causes, consequence, intensity of severity and their implications define the quality of product. The number of defects found in development process and number of defects reported by the client after the product is installed or delivered at client-end, define quality of product. v Process Metrics: In various phases of SDLC, the methods and tools used, the company standards and the performance of development are software process metrics. 37 vi Resource Metrics: Effort, time and various resources used, represents metrics for resource measurement. 38  MODULE FOUR REQUIREMENTS ENGINEERING The requirements for a system are the descriptions of what the system should do, the services that it provides and the constraints on its operation. These requirements reflect the needs of customers for a system that serves a certain purpose such as controlling a device, placing an order, or finding information. The process of finding out, analyzing, documenting and checking these services and constraints is called requirements engineering (RE). The term ‘requirement’ is not used consistently in the software industry. In some cases, a requirement is simply a high-level, abstract statement of a service that a system should provide or a constraint on a system. 4.1 Levels of Requirements Engineering The different levels of requirements engineering are user requirements (meaning the high-level abstract requirements) and system requirements (meaning the detailed description of what the system should do. User requirements and system requirements may be defined as follows: 1. User requirements: These are statements, in a natural language plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate. 2. System requirements: They are more detailed descriptions of the software system’s functions, services, and operational constraints. The system requirements document (sometimes called a functional specification) should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers. 4.2 Functional and Non-functional requirements Software system requirements are often classified as functional requirements or non- functional requirements: 1. Functional requirements: The functional requirements for a system describe what the system should do. These requirements depend on the type of software being developed, the expected users of the software, how the system should react to particular inputs, and how the system should behave in particular situations. When expressed as user requirements, functional requirements are usually described in an abstract way that can be understood by system users. In some cases, the functional requirements may also explicitly state what the system should not do. 39 2. Non-functional requirements: Non-functional requirements, as the name suggests, are requirements that are not directly concerned with the specific services delivered by the system to its users. They may relate to emergent system properties such as reliability, response time, and store occupancy. Alternatively, they may define constraints on the system implementation such as the capabilities of I/O devices or the data representations used in interfaces with other systems. Non-functional requirements, such as performance, security, or availability, usually specify or constrain characteristics of the system as a whole. Non- functional requirements are often more critical than individual functional requirements. Figure 4.1: Types of requirements specification Table 4.1 shows metrics that you can use to specify non-functional system properties. You can measure these characteristics when the system is being tested to check whether or not the system has met its nonfunctional requirements. Table 4.1: Metrics for specifying non-functional requirements 40 4.3 Requirements specification Requirements specification is the process of writing down the user and system requirements in a requirements document. Ideally, the user and system requirements should be clear, unambiguous, easy to understand, complete, and consistent. There are two ways of specifying requirements, namely: 1. Natural language specification: Natural language has been used to write requirements for software since the beginning of software engineering. It is expressive, intuitive, and universal. It is also potentially vague, ambiguous, and its meaning depends on the background of the reader. 2. Structured specifications: Structured natural language is a way of writing system requirements where the freedom of the requirements writer is limited and all requirements are written in a standard way. This approach maintains most of the expressiveness and understandability of natural language but ensures that some uniformity is imposed on the specification. 4.4 Requirement Elicitation Process Requirement elicitation process can be depicted using the following diagram: Figure 4.2: Requirement elicitation process  Requirements gathering: The developers discuss with the client and the end users and know their expectations from the software.  Requirements Organization: The developers prioritize and arrange the requirements in order of importance, urgency and convenience.  Negotiation & discussion: If the requirements are ambiguous or there are some conflicts in the requirements of various stakeholders, it is then negotiated and discussed with the stakeholders. Requirements may then be prioritized and reasonably compromised. The requirements come from various stakeholders. To remove the ambiguity and conflicts, they are discussed for clarity and correctness. Unrealistic requirements are compromised reasonably.  Requirements specification: All formal and informal, functional and non- functional requirements are documented and made available for next phase processing. 4.5 Requirement Elicitation Techniques Requirements Elicitation is the process to find out the requirements for an intended software system by communicating with client, end users, system users and others 41 who have a stake in the software system development. There are various ways to discover requirements: 1. Interviews: Interviews are strong medium to collect requirements. Organization may conduct several types of interviews such as: Structured (closed) interviews, where every single information to be gathered, is decided in advance, they follow the pattern and matter of discussion firmly. Non-structured (open) interviews, where information to gather is not decided in advance, more flexible and less biased. Oral interviews Written interviews One-to-one interviews: which are held between two persons across the table. Group interviews: which are held between groups of participants. They help to uncover any missing requirement as numerous people are involved. 2. Surveys: Organization may conduct surveys among various stakeholders by querying about their expectation and requirements from the upcoming system. 3. Questionnaires: A document with pre-defined set of objective questions and respective options is handed over to all stakeholders to answer, which are collected and compiled. A shortcoming of this technique is, if an option for some issue is not mentioned in the questionnaire, the issue might be left unattended. 4. Task analysis: Team of engineers and developers may analyze the operation for which the new system is required. If the client already has some software to perform certain operation, it is studied and requirements of proposed system are collected. 5. Domain Analysis: Every software falls into some domain category. The expert people in the domain can be a great help to analyze general and specific requirements. 6. Brainstorming: An informal debate is held among various stakeholders and all their inputs are recorded for further requirements analysis. 7. Observation: Team of experts visits the client’s organization or workplace. They observe the actual working of the existing installed systems. They observe the workflow at client’s end and how execution problems are dealt. The team itself draws some conclusions which aid to form requirements expected from the software. 42  MODULE FIVE SYSTEM MODELING System modeling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system. System modelling has generally come to mean representing the system using some kind of graphical notation, which is now almost always based on notations in the Unified Modeling Language (UML). However, it is also possible to develop formal (mathematical) models of a system, usually as a detailed system specification. Models are used during the requirements engineering process to help derive the requirements for a system, during the design process to describe the system to engineers implementing the system and after implementation to document the system’s structure and operation. You may develop models of both the existing system and the system to be developed: 1. Models of the existing system are used during requirements engineering. They help clarify what the existing system does and can be used as a basis for discussing its strengths and weaknesses. These then lead to requirements for the new system. 2. Models of the new system are used during requirements engineering to help explain the proposed requirements to other system stakeholders. Engineers use these models to discuss design proposals and to document the system for implementation. In a model-driven engineering process, it is possible to generate a complete or partial system implementation from the system model. The most important aspect of a system model is that it leaves out detail. A model is an abstraction of the system being studied rather than an alternative representation of that system. Ideally, a representation of a system should maintain all the information about the entity being represented. You may develop different models to represent the system from different perspectives. For example: 1. An external perspective, where you model the context or environment of the system. 2. An interaction perspective where you model the interactions between a system and its environment or between the components of a system. 3. A structural perspective, where you model the organization of a system or the structure of the data that is processed by the system. 4. A behavioral perspective, where you model the dynamic behavior of the system and how it responds to events. Diagrams defined in UML has become a standard modeling language for object- oriented modeling. The UML has many diagram types and so supports the creation of many different types of system model. However, it was noted that thses five diagram types could represent the essentials of a system: 43  1. Activity diagrams, which show the activities involved in a process or in data processing. 2. Use case diagrams, which show the interactions between a system and its environment. 3. Sequence diagrams, which show interactions between actors and the system and between system components. 4. Class diagrams, which show the object classes in the system and the associations between these classes. 5. State diagrams, which show how the system reacts to internal and external events. When developing system models, you can often be flexible in the way that the graphical notation is used. You do not always need to stick rigidly to the details of a notation. The detail and rigor of a model depends on how you intend to use it. There are three ways in which graphical models are commonly used: 1. As a means of facilitating discussion about an existing or proposed system. 2. As a way of documenting an existing system. 3. As a detailed system description that can be used to generate a system implementation. 5.1 Use case modeling Use case modeling is widely used to support requirements elicitation. A use case can be taken as a simple scenario that describes what a user expects from a system. Each use case represents a discrete task that involves external interaction with a system. In its simplest form, a use case is shown as an ellipse with the actors involved in the use case represented as stick figures. A use case is a step-by-step description of how a user will use the system-to-be to accomplish business goals. Three key elements of use cases: i Environmental agents or actors that will cooperate with the system ii Use case diagram shows relations of the actors and use cases iii Use case scenarios are plans for realization of user goals or handling contingencies 5.1.1 Types of Actors 1. Initiating actor (also called primary actor or simply “user”): initiates the use case to achieve a goal 2. Participating actor (also called secondary actor): participates in the use case but does not initiate it. Subtypes of participating actors: i Supporting actor: helps the system-to-be to complete the use case 44  ii Offstage actor: passively participates in the use case, i.e., neither initiates nor helps complete the use case, but may be notified about some aspect of it (e.g., for keeping records) Figure 5.1: Use Case Diagram; High-level goal: ARRIVE Figure 5.2: Use cases involving the role ‘medical receptionist’ 5.2 Sequence diagrams Sequence diagrams in the UML are primarily used to model the interactions between 45 the actors and the objects in a system and the interactions between the objects themselves. The UML has a rich syntax for sequence diagrams, which allows many different kinds of interaction to be modeled. As the name implies, a sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance. Figure 5.3 is an example of a sequence diagram that illustrates the basics of the notation. This diagram models the interactions involved in the View patient information use case, where a medical receptionist can see some patient information. The objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these. Interactions between objects are indicated by annotated arrows. The rectangle on the dotted lines indicates the lifeline of the object concerned (i.e., the time that object instance is involved in the computation). You read the sequence of interactions from top to bottom. The annotations on the arrows indicate the calls to the objects, their parameters, and the return values. In this example, I also show the notation used to denote alternatives. A box named alt is used with the conditions indicated in square brackets. Figure 5.3: Sequence diagram for View patient information 46