Requirement Engineering Chapter 4 PDF

Requirement Engineering Chapter 4 1 Requirement Engineering Requirement: A function, constraint or other property that the system must provide to fill the needs of the system’s intended user(s) Requirement Engineering means that requirements for a product are defined...

Requirement Engineering Chapter 4 1 Requirement Engineering Requirement: A function, constraint or other property that the system must provide to fill the needs of the system’s intended user(s) Requirement Engineering means that requirements for a product are defined, (describe) managed and tested systematically 2 Why is Getting Good Requirements Hard? Stakeholders don’t know what they really want. Stakeholders express requirements in their own terms. Different stakeholders may have conflicting requirements. Organisational and political factors may influence the system requirements. The requirements change during the RE process. New stakeholders may emerge and the business environment change. 3 Initiating Requirements Engineering Process Identify stakeholders Stakeholder can be “anyone who benefits in a direct or indirect way from the system which is being developed” Internal stakeholders may include top management, project team members, your manager, peers, resource manager, and internal customers. External stakeholders may include external customers, government, contractors and subcontractors, and suppliers. Ex. Business manager, project manager, marketing people, software engineer, support engineer, end-users, internal-external customers, consultants, maintenance engineer. Each one of them has different view of the system. 4 Initiating Requirements Engineering Process Recognize multiple points of view Marketing group concern about feature and function to excite potential market. To sell easily in the market. Business manager concern about feature built within budget and will be ready to meet market. End user – Easy to learn and use. SE – product functioning at various infrastructure support. Support engineer – Maintainability of software. Role of RE is to categorize all stakeholder information in a way that there could be no inconsistent or conflict requirement with one another 5  Work toward collaboration RE identify areas of commonality (i.e. Agreed requirement) and areas of conflict or inconsistency. Business manager or senior technologist may make final decision. Asking the first questions Who is behind the request for this work? Who will use the solution? What will be the economic benefit of a successful solution Is there another source for the solution that you need? These questions will help – stakeholder interest in the software & measurable benefit of successful implementation. 6 Asking the question Next set of questions – better understanding of the problem. What business problem (s) will this solution address? Describe business environment in which the solution will be used? will performance or productivity issues affect the solution is approached? Final set of questions – Effectiveness of communication Are my questions relevant to the problem? Am I asking too many questions? Can anyone else provide additional information? should I be asking you anything else? 7  Requirement Engineering Process It is a four-step process, which includes - Feasibility Study Requirement Elicitation and Analysis Software Requirement Specification Software Requirement Validation Software Requirement Management 8 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: 1. Technical Feasibility - Technical feasibility evaluates the current technologies, which are needed to accomplish customer requirements within the time and budget. 2. Operational Feasibility - Operational feasibility assesses the range in which the required software performs a series of levels to solve business problems and customer requirements. 3. Economic Feasibility - Economic feasibility decides whether the necessary software can generate financial profits for an organization. 9  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. 10 3. Software Requirement Specification: Software requirement specification (SRS ) 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. (SRS )Let client and developers agree that they understand each The models used at this stage include ER diagrams, data flow diagrams (DFDs), function decomposition diagrams (FDDs), data dictionaries, etc. 11 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 12 4. Software Requirement Validation: Requirements Validation Techniques 1. Requirements reviews/inspections: systematic manual analysis of the requirements. 2. Prototyping: Using an executable model of the system to check requirements. 3. Test-case generation: Developing tests for requirements to check testability. 4. Automated consistency analysis: checking for the consistency of structured requirements descriptions. 13  Classification of requirements Business requirements :include high-level statements of goals, objectives, and needs of your project. User requirements :help to find what you expect from a particular solution. System(Solution ) requirements :describe the product characteristics that will meet your expectations and business needs. They include: Functional requirements. Nonfunctional requirements. 14 15 Classification of requirements Software Requirements: Largely software requirements must be categorized into two categories: 1.Functional Requirements: Functional requirements define a function that a system or system element must be qualified to perform and must be documented in different forms. The functional requirements are describing the behavior of the system as it correlates to the system's functionality. 2.Non-functional Requirements: This can be the necessities that specify the criteria that can be used to decide the operation instead of specific behaviors of the system. Non-functional requirements are divided into two main categories: 1. Execution qualities like security and usability, which are observable at run time. 2. Evolution qualities like testability, maintainability, extensibility, and scalability that embodied in the static structure of the software system. 16 Functional Vs Non-Functional Requirements: (extra reading) 17 Other Sources of Requirement Knowledge transfer from colleagues or employees already working on that project Talk about project to business analyst, product manager, project lead and developers Analyze previous system version that is already implemented into the system Analyze the older requirement document of the project Look into the past Bug reports, some of the bug reports are turned into enhancement request which may be implemented into current version Look into installation guide if it is available to see what are the installation required Analyze the domain or industry knowledge that team is trying to implement Whatever source of requirement you get make sure to document them in some form, get them reviewed from other experienced and knowledgeable team members. 18 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. 19  How to Analyze Requirements Lets study how to analyze the requirements. The requirements must maintain a standard quality of its requirement, different types of requirement quality includes Atomic Uniquely identified Complete Consistent and unambiguous Traceable Prioritized Testable 20 How to Analyze Requirements Let understand this with an example, there are three columns in the table shown here, 1.The first column indicates- “requirement quality” 2.The second column indicates- “bad requirement with some problem” 3.The third column is same as second column but – “converted into a good requirement”. 21 How to Analyze Requirements Atomic So each and every requirement you have should be atomic, which means it should be at very low level of details it should not be possible to separated out into components. Here we will see the two examples for requirements, at Atomic and uniquely identified requirements levels. So let us continue with example of system build for education domain. Here, the bad requirement is “Students will be able to enroll to undergraduate and post graduate courses”. This is a bad requirement because it is not atomic because it talks about two different entities undergraduates and post- graduates courses. So obviously it is not a good requirement but bad requirement, so correspondence good requirement would be to separate it out into two requirements. So one talks about the enrolment to undergraduate courses while the other talks about the enrolment to the post-graduate courses. 22  How to Analyze Requirements Uniquely Identified Similarly the next requirement quality is to check for uniquely identified, here we have two separate requirement but they both have same ID#1. So, if we are referring our requirement with reference to ID#, but it is not clear which exact requirement we are referring to document or other part of the system as both have same ID#1. So separating out with unique id’s, so good requirement will be re-return as section 1- course enrolments, and it has two requirements 1.1 id is enrolment to undergraduate courses while 1.2 id is enrolment to postgraduate courses. 23 How to Analyze Requirements Complete Also, each and every requirement should be complete. For example, here the bad requirement says a “professor user will log into the system by providing his username, password and other relevant information”. Here the other relevant information is not clear, so the other relevant information should be spelt out in good requirement to make the requirement complete. 24  How to Analyze Requirements Consistent and Unambiguous Next each and every requirement should be consistent and unambiguous, so here for instance we have requirements “A student will have either undergraduate courses or post-graduate courses but not both” this is one requirement there is some other requirement that says “Some courses will be open to both under-graduate and post- graduate students”. The problem in this requirement is that from the first requirement it seems that the courses are divided into two categories under graduate courses and post graduate courses and student can opt either of two but not both. But when you read other requirement it conflicts with the first requirement and it tells that some courses will open to both post-graduate and under-graduate. So it is obvious to convert this bad requirement into good requirement which is “A student will have either under-graduate courses or post-graduate courses but not both”. Which means that every course will be marked either being as under-graduate course or post-graduate course 25  How to Analyze Requirements Traceable Each and every requirement should be traceable because there are already different levels of requirement, we already saw that at the top we had business requirements, and then we have an architectural and design requirements followed by system integration requirements. Now when we convert business requirement into architectural and design requirements or we convert architectural and design requirements to system integration requirements there has to be traceability. Which means that we should be able to take each and every business requirements and map it to the corresponding one or more software architectural and design requirement. So here is an example of bad requirement that says “Maintain student information – mapped to BRD req ID?” the requirement id is not given over here. So converting it to a good requirement it says same thing but it is mapped with the requirement id 4.1. So mapping should be there for each and every requirement. Same way we have high level and low level mapping requirement, the mapping is also there between system and integration requirement to the code that implements that requirement and also there is a mapping between the system and integration requirement to the test case which test that particular requirement. So this traceability is all across entire project 26 How to Analyze Requirements Prioritized Then each and every requirement must be prioritized, so the team has guideline so which requirement that able to implement first and which can be done later on. Here you can see the bad priority has register student, maintain user information and each and every requirement has given priority-1. Everything cannot be at same priority, so requirement can be prioritized. So the example of good requirement over here is the register student and enroll courses is given the highest priority 1, while maintain user information comes below at priority 2 and then we have view report card at priority-3 27 How to Analyze Requirements Testable Each and every requirement should be testable, here the bad requirement is “each page of the system will load in an acceptable time frame”. Now there are two problems with this requirement first is that each page meaning that there can be many pages, which going to blow up the testing efforts. The other problem is that it say the page is going to load in acceptable time frame, now what is acceptable time frame? Acceptable to whom. So we have to convert the non-testable argument into a testable argument, which specifically tells about which page we are talking about “register student and enroll courses pages” and the acceptable time frame is also given which is 5 seconds. 28 REFERENCES Software Engineering, 9th edition, Ian Sommerville, Addison-Wesley, ISBN 0-201-39815- X. CHAPTER 4 29  Thank you 30