SE-Unit II.pdf
- 2. Requirement Engineering Requirements engineering (RE) refers to the process of defining, documenting, and maintaining requirements in the engineering design process. Requirement engineering provides the appropriate mechanism to understand what the customer desires, analyzing the need, and assessing feasibility, negotiating a reasonable solution, specifying the solution clearly, validating the specifications and managing the requirements as they are transformed into a working system. Thus, requirement engineering is the disciplined application of proven principles, methods, tools, and notation to describe a proposed system's intended behavior and its associated constraints.
- 3. Requirement Engineering Process It is a five-step process, which includes - 1. Feasibility Study 2. Requirement Elicitation and Analysis 3. Software Requirement Specification 4. Software Requirement Validation 5. Software Requirement Management
- 4. 1. Feasibility Study: The objective behind the feasibility study is to create the reasons for developing the software that is acceptable to users, flexible to change and conformable to established standards. Types of Feasibility: • Technical Feasibility - Technical feasibility evaluates the current technologies, which are needed to accomplish customer requirements within the time and budget. • Operational Feasibility - Operational feasibility assesses the range in which the required software performs a series of levels to solve business problems and customer requirements. • Economic Feasibility - Economic feasibility decides whether the necessary software can generate financial profits for an organization.
- 5. 2. Requirement Elicitation and Analysis: This is also known as the gathering of requirements. Here, requirements are identified with the help of customers and existing systems processes, if available. Analysis of requirements starts with requirement elicitation. The requirements are analyzed to identify inconsistencies, defects, omission, etc. We describe requirements in terms of relationships and also resolve conflicts if any. Problems of Elicitation and Analysis • Getting all, and only, the right people involved. • Stakeholders often don't know what they want • Stakeholders express requirements in their terms. • Stakeholders may have conflicting requirements. • Requirement change during the analysis process. • Organizational and political factors may influence system requirements.
- 6. 3. Software Requirement Specification: Software requirement specification is a kind of document which is created by a software analyst after the requirements collected from the various sources - the requirement received by the customer written in ordinary language. It is the job of the analyst to write the requirement in technical language so that they can be understood and beneficial by the development team. The models used at this stage include ER diagrams, data flow diagrams (DFDs), function decomposition diagrams (FDDs), data dictionaries, etc. • Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the requirements. DFD shows the flow of data through a system. The system may be a company, an organization, a set of procedures, a computer hardware system, a software system, or any combination of the preceding. The DFD is also known as a data flow graph or bubble chart. • Data Dictionaries: Data Dictionaries are simply repositories to store information about all data items defined in DFDs. At the requirements stage, the data dictionary should at least define customer data items, to ensure that the customer and developers use the same definition and terminologies. • Entity-Relationship Diagrams: Another tool for requirement specification is the entity-relationship diagram, often called an "E-R diagram." It is a detailed logical representation of the data for the organization and uses three main constructs i.e. data entities, relationships, and their associated attributes .
- 7. 4. Software Requirement Validation: After requirement specifications developed, the requirements discussed in this document are validated. The user might demand illegal, impossible solution or experts may misinterpret the needs. Requirements can be the check against the following conditions - • If they can practically implement • If they are correct and as per the functionality and specially of software • If there are any ambiguities • If they are full • If they can describe Requirements ValidationTechniques • Requirements reviews/inspections: systematic manual analysis of the requirements. • Prototyping: Using an executable model of the system to check requirements. • Test-case generation:Developing tests for requirements to check testability. • Automated consistency analysis: checking for the consistency of structured requirements descriptions.
- 8. 5. Software Requirement Management: Requirement management is the process of managing changing requirements during the requirements engineering process and system development. New requirements emerge during the process as business needs a change, and a better understanding of the system is developed. The priority of requirements from different viewpoints changes during development process. The business and technical environment of the system changes during the development.
- 9. Use of Requirement Engineering Process 1. Determining the feasibility of producing a particular product as part of the product line. 2. Determining the production, testing, and deployment of the particular product. 3. Determining the evolution of the product line that results from that product development.
- 10. Classification of Software Requirements According to IEEE standard 729, a requirement is defined as follows: 1. A condition or capability needed by a user to solve a problem or achieve an objective 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documents 3. A documented representation of a condition or capability as in 1 and 2.
- 11. A software requirement can be of 3 types: 1. Functional requirements 2. Non-functional requirements 3. Domain requirements
- 12. 1. Functional Requirements: These are the requirements that the end user specifically demands as basic facilities that the system should offer.All these functionalities need to be necessarily incorporated into the system as a part of the contract. These are represented or stated in the form of input to be given to the system, the operation performed and the output expected. They are basically the requirements stated by the user which one can see directly in the final product, unlike the non-functional requirements. For example, in a hospital management system, a doctor should be able to retrieve the information of his patients. Each high-level functional requirement may involve several interactions or dialogues between the system and the outside world. In order to accurately describe the functional requirements, all scenarios must be enumerated. There are many ways of expressing functional requirements e.g., natural language, a structured or formatted language with no rigorous syntax and formal specification language with proper syntax.
- 13. 2. Non-functional requirements: These are basically the quality constraints that the system must satisfy according to the project contract. The priority or extent to which these factors are implemented varies from one project to other. They are also called non-behavioral requirements. They basically deal with issues like: • Portability • Security • Maintainability • Reliability • Scalability • Performance • Reusability • Flexibility NFR’s are classified into following types: • Interface constraints • Performance constraints: response time, security, storage space, etc. • Operating constraints • Life cycle constraints: maintainability, portability, etc. • Economic constraints The process of specifying non-functional requirements requires the knowledge of the functionality of the system, as well as the knowledge of the context within which the system will operate.
- 14. 3. Domain requirements: Domain requirements are the requirements which are characteristic of a particular category or domain of projects. The basic functions that a system of a specific domain must necessarily exhibit come under this category. For instance, in an academic software that maintains records of a school or college, the functionality of being able to access the list of faculty and list of students of each grade is a domain requirement. These requirements are therefore identified from that domain model and are not user specific
- 15. Software Quality Assurance What is Quality? Quality defines to any measurable characteristics such as correctness, maintainability, portability, testability, usability, reliability, efficiency, integrity, reusability, and interoperability. There are two kinds of Quality:
- 16. • Quality of Design: Quality of Design refers to the characteristics that designers specify for an item. The grade of materials, tolerances, and performance specifications that all contribute to the quality of design. • Quality of conformance: Quality of conformance is the degree to which the design specifications are followed during manufacturing. Greater the degree of conformance, the higher is the level of quality of conformance. Software Quality: Software Quality is defined as the conformance to explicitly state functional and performance requirements, explicitly documented development standards, and inherent characteristics that are expected of all professionally developed software.
- 17. Software Quality Assurance (SQA) is simply a way to assure quality in the software. It is the set of activities which ensure processes, procedures as well as standards are suitable for the project and implemented correctly. Software Quality Assurance is a process which works parallel to development of software. It focuses on improving the process of development of software so that problems can be prevented before they become a major issue. Software Quality Assurance is a kind of Umbrella activity that is applied throughout the software process. Software Quality Assurance has: • A quality management approach • Formal technical reviews • Multi testing strategy • Effective software engineering technology • Measurement and reporting mechanism
- 18. Major Software Quality Assurance Activities: • SQA Management Plan: Make a plan for how you will carry out the SQA through out the project. Think about which set of software engineering activities are the best for project. check level of SQA team skills. • Set The Check Points: SQA team should set checkpoints. Evaluate the performance of the project on the basis of collected data on different check points. • Multi testing Strategy: Do not depend on a single testing approach. When you have a lot of testing approaches available use them. • Measure Change Impact: The changes for making the correction of an error sometimes re introduces more errors keep the measure of impact of change on project. Reset the new change to change check the compatibility of this fix with whole project. • Manage Good Relations: In the working environment managing good relations with other teams involved in the project development is mandatory. Bad relation ofSQA team with programmers team will impact directly and badly on project. Don’t play politics.
- 19. Benefits of Software Quality Assurance (SQA): • SQA produces high quality software. • High quality application saves time and cost. • SQA is beneficial for better reliability. • SQA is beneficial in the condition of no maintenance for a long time. • High quality commercial software increase market share of company. • Improving the process of creating software. • Improves the quality of the software. Disadvantage of SQA: There are a number of disadvantages of quality assurance. Some of them include adding more resources, employing more workers to help maintain quality and so much more.
- 20. Quality Assurance Quality Control Quality Assurance (QA) is the set of actions including facilitation, training, measurement, and analysis needed to provide adequate confidence that processes are established and continuously improved to produce products or services that conform to specifications and are fit for use. Quality Control (QC) is described as the processes and methods used to compare product quality to requirements and applicable standards, and the actions are taken when a nonconformance is detected. QA is an activity that establishes and calculates the processes that produce the product. If there is no process, there is no role for QA. QC is an activity that demonstrates whether or not the product produced met standards. QA helps establish process QC relates to a particular product or service QA sets up a measurement program to evaluate processes QC verified whether particular attributes exist, or do not exist, in a explicit product or service. QA identifies weakness in processes and improves them QC identifies defects for the primary goals of correcting errors. Quality Assurance is a managerial tool. Quality Control is a corrective tool. Verification is an example of QA. Validation is an example of QC. Quality Assurance v/s Quality control
- 22. Software Quality Framework Software Quality Framework is a model for software quality by connecting and integrating the different views of software quality. This framework connects the customer view with the developer view of software quality and it treats software as a product. The software product view describes the characteristics of a product that bear on its ability to satisfy stated and implied needs. This is a framework that describes all the different concepts relating to quality in a common way measured by qualitative scale that can be understood and interpreted in a common way. Therefore the most influential factor for the developers is the customer perception. This framework connects the developer with the customer to derive a common interpretation for quality. 1. Developers View: Validation and verification are two independent methods used together for checking that a software product meets the requirements and that it fulfills its intended purpose. Validation checks that the product design satisfies the purposeful usage and verification checks for errors in the software. The primary concern for developers is in the design and engineering processes involved in producing software. Quality can be measured by the degree of conformance to predetermined requirement and standards, and deviations from these standards can lead to poor quality and low reliability. While validation and verification are used by the developers to improve the software, the two methods don’t represent a quantifiable quality measurement. The developer view of software quality and customer view of software quality are both different things. For example the customer understands or describes the quality of operation as meeting the requirement while the developers use different factors to describe the software quality.
- 23. The developer view of quality in the software is influenced by many factors. This model stresses on 3 primary ones: • The code: It is measured by its correctness and reliability. • The data: It is measured by the application integrity. • Maintainability: It has different measures the simplest is the mean time to change. 2. Users View: When the user acquires software, he/she always expect a high-quality software. When end users develop their software then quality is different. End-user programming, a phrase popularized by which is programming to achieve the result of a program primarily for personal, rather than public use. The important distinction here is that software itself is not primarily intended for use by a large number of users with varying needs. For example, a teacher may write a spreadsheet to track students’test scores. In these end-user programming situations, the program is a means to an end that could be used to accomplish a goal. In contradiction to end-user programming, professional programming has the goal of producing software for others to use. For example, the moment a novice Web developer moves from designing a web page for himself to designing a Web page for others, the nature of this activity has changed. Users find software quality as a fit between their goals and software’s functionality. The better the quality, the more likely the user will be satisfied with the soft-ware. When the quality is bad, developers must meet user needs or face a diminishing demand for their software. Therefore, the user understands quality as fitness for purpose. Avoiding complexity and keeping software simple, considerably lessens the implementation risk of software. In some instances, users abandoned the implementation of a complex software because the software developers were expecting the users to change their business and to go with the way the software works.
- 24. 3. Product View: The product view describes quality as correlated to inherent characteristics of the product. Product quality is defined as the set of characteristics and features of a product that gives contribution to its ability to fulfill given requirements. Product quality can be measured by the value-based view which sees the quality as dependent on the amount a customer is willing to pay for it. According the users, a high-quality product is one that satisfies their expectations and preferences while meeting their requirement. Satisfaction of end users of the product represents craft to learn, use, upgrade the product and when asked to participate in rating the product, a positive rating is given.
- 25. ISO 9000 Certification ISO (International Standards Organization) is a group or consortium of 63 countries established to plan and fosters standardization. ISO declared its 9000 series of standards in 1987. It serves as a reference for the contract between independent parties. The ISO 9000 standard determines the guidelines for maintaining a quality system. The ISO standard mainly addresses operational methods and organizational methods such as responsibilities, reporting, etc. ISO 9000 defines a set of guidelines for the production process and is not directly concerned about the product itself.
- 26. Types of ISO 9000 Quality Standards The ISO 9000 series of standards is based on the assumption that if a proper stage is followed for production, then good quality products are bound to follow automatically. The types of industries to which the various ISO standards apply are as follows. 1. ISO 9001: This standard applies to the organizations engaged in design, development, production, and servicing of goods. This is the standard that applies to most software development organizations. 2. ISO 9002: This standard applies to those organizations which do not design products but are only involved in the production. Examples of these category industries contain steel and car manufacturing industries that buy the product and plants designs from external sources and are engaged in only manufacturing those products. Therefore, ISO 9002 does not apply to software development organizations. 3. ISO 9003: This standard applies to organizations that are involved only in the installation and testing of the products. For example, Gas companies.
- 27. How to get ISO 9000 Certification? An organization determines to obtain ISO 9000 certification applies to ISO registrar office for registration. The process consists of the following stages: • Application: Once an organization decided to go for ISO certification, it applies to the registrar for registration. • Pre-Assessment: During this stage, the registrar makes a rough assessment of the organization. • Document review and Adequacy of Audit: During this stage, the registrar reviews the document submitted by the organization and suggest an improvement. • Compliance Audit: During this stage, the registrar checks whether the organization has compiled the suggestion made by it during the review or not. • Registration: The Registrar awards the ISO certification after the successful completion of all the phases. • Continued Inspection: The registrar continued to monitor the organization time by time.
- 28. Software Engineering Institute Capability Maturity Model (SEICMM) The Capability Maturity Model (CMM) is a procedure used to develop and refine an organization's software development process. The model defines a five-level evolutionary stage of increasingly organized and consistently more mature processes. CMM was developed and is promoted by the Software Engineering Institute (SEI), a research and development center promote by the U.S. Department of Defense (DOD). Capability Maturity Model is used as a benchmark to measure the maturity of an organization's software process.
- 29. Methods of SEICMM There are two methods of SEICMM: • Capability Evaluation: Capability evaluation provides a way to assess the software process capability of an organization. The results of capability evaluation indicate the likely contractor performance if the contractor is awarded a work. Therefore, the results of the software process capability assessment can be used to select a contractor. • Software Process Assessment: Software process assessment is used by an organization to improve its process capability. Thus, this type of evaluation is for purely internal use. SEI CMM categorized software development industries into the following five maturity levels. The various levels of SEI CMM have been designed so that it is easy for an organization to build its quality system starting from scratch slowly.
- 30. Level 1: Initial Ad hoc activities characterize a software development organization at this level. Very few or no processes are described and followed. Since software production processes are not limited, different engineers follow their process and as a result, development efforts become chaotic. Therefore, it is also called a chaotic level. Level 2: Repeatable At this level, the fundamental project management practices like tracking cost and schedule are established. Size and cost estimation methods, like function point analysis, COCOMO, etc. are used. Level 3: Defined At this level, the methods for both management and development activities are defined and documented. There is a common organization-wide understanding of operations, roles, and responsibilities. The ways through defined, the process and product qualities are not measured. ISO 9000 goals at achieving this level.
- 31. Level 4: Managed At this level, the focus is on software metrics. Two kinds of metrics are composed. • Product metrics measure the features of the product being developed, such as its size, reliability, time complexity, understandability, etc. • Process metrics follow the effectiveness of the process being used, such as average defect correction time, productivity, the average number of defects found per hour inspection, the average number of failures detected during testing per LOC, etc. The software process and product quality are measured, and quantitative quality requirements for the product are met. Various tools like Pareto charts, fishbone diagrams, etc. are used to measure the product and process quality. The process metrics are used to analyze if a project performed satisfactorily. Thus, the outcome of process measurements is used to calculate project performance rather than improve the process. Level 5: Optimizing At this phase, process and product metrics are collected. Process and product measurement data are evaluated for continuous process improvement.
- 32. Key Process Areas (KPA) of a software organization Except for SEI CMM level 1, each maturity level is featured by several Key Process Areas (KPAs) that contains the areas an organization should focus on improving its software process to the next level. The focus of each level and the corresponding key process areas are shown in the fig. SEI CMM provides a series of key areas on which to focus to take an organization from one level of maturity to the next. Thus, it provides a method for gradual quality improvement over various stages. Each step has been carefully designed such that one step enhances the capability already built up.