Chapter3_CS-1131_1st_2024-2025 (1).pdf

CS 1131 SOFTWARE ENGINEERING 1 1 st Semester, SY 2024-2025 BELEN M. TAPADO, DIT Professor VI  CHAPTER 3 Software Requirements Lesson Outline REQUIREMENTS REQUIREMENTS REQUIREMENTS REQUIREMENTS SOFTWARE SOFTWARE ENGINEERING ENGINEERING ELICITAT...

CS 1131 SOFTWARE ENGINEERING 1 1 st Semester, SY 2024-2025 BELEN M. TAPADO, DIT Professor VI  CHAPTER 3 Software Requirements Lesson Outline REQUIREMENTS REQUIREMENTS REQUIREMENTS REQUIREMENTS SOFTWARE SOFTWARE ENGINEERING ENGINEERING ELICITATION PROCESS ELICITATION REQUIREMENTS REQUIREMENTS PROCESS TECHNIQUES CHARACTERISTICS SOFTWARE KEY SOFTWARE USER SYSTEM METRICS AND INTERFACE ANALYST MEASURES REQUIREMENTS Lesson Objectives Identify and discuss the different software requirements and how these requirements are gathered Identify the different software requirements techniques, tools and methods write a software requirements specification document Key Concepts and Terms What does this picture connote?  LESSON 1 REQUIREMENTS ENGINEERING Requirements Engineering, Defined It is the process to gather the software requirements from client, analyze and document them. The goal of requirement engineering is to develop and maintain sophisticated and descriptive ‘System Requirements Specification’ document.  LESSON 2 REQUIREMENTS ENGINEERING PROCESS  Feasibility Study Requirements Requirement Gathering Software Requirement Engineering Specification Process Software Requirement Validation When the client approaches the organization for getting the desired product developed, it comes up with rough idea about what all functions the software must perform and which all features are expected from the software. Feasibility Study Referencing to this information, the analysts does a detailed study about whether the desired system and its functionality are feasible to develop. This feasibility study is focused towards goal of the organization. This study analyzes whether the software product can be practically materialized in terms of implementation, contribution of project to organization, cost constraints and as per values and objectives of the organization. It explores technical aspects of the project and product such as usability, maintainability, productivity and integration ability. The output of this phase should be a feasibility study report that should contain adequate comments and recommendations for management about whether or not the project should be undertaken.  Requirements If the feasibility report is positive towards Gathering undertaking the project, next phase starts with gathering requirements from the user. Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide, and which features they want the software to include. SRS is a document created by system analyst after the Software requirements are collected from various stakeholders. Requirement Specification SRS defines how the intended software will interact with (SRS) hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc. The requirements received from client are written in natural language. It is the responsibility of system analyst to document the requirements in technical language so that they can be comprehended and useful by the software development team.  Software Requirement Specification (SRS) Features Technical requirements User Design Conditional are expressed Requirements description Format of and in structured are expressed should be Forms and GUI mathematical language, in natural written in screen prints. notations for which is used language. Pseudo code. DFDs etc. inside the organization.  Software Requirements After requirement specifications are developed, the Validation requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. If they can be practically implemented Checking and If they are valid and as per functionality Validating and domain of software Requirements Conditions If there are any ambiguities If they are complete If they can be demonstrated  LESSON 3 REQUIREMENTS ELICITATION PROCESS Requirements Elicitation Process Requirements Elicitation Process (2) Negotiation & discussion - If requirements are The requirements come ambiguous or there are from various Organizing Documentation - All Requirements gathering some conflicts in stakeholders. To Requirements - The formal & informal, - The developers requirements of various remove the ambiguity developers prioritize functional and non- discuss with the client stakeholders, if they and conflicts, they are and arrange the functional requirements and end users and are, it is then negotiated discussed for clarity requirements in order of are documented and know their expectations and discussed with and correctness. importance, urgency made available for next from the software. stakeholders. Unrealistic requirements and convenience. phase processing. Requirements may then are compromised be prioritized and reasonably. reasonably compromised.  LESSON 4 REQUIREMENTS ELICITATION TECHNIQUES Requirements 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 who have a stake in the software system development. ◦ Interviews are strong medium to collect requirements. ◦ Organization may conduct several types of interviews such as: Interviews Structured (closed) interviews, where every single information to gather is decided in advance, they follow 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.  Surveys Organization may conduct surveys among various stakeholders by querying about their expectation and requirements from the upcoming system. A document with pre-defined set of objective questions and respective options Questionnaires 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.  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.  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.  Brainstorming An informal debate is held among various stakeholders and all their inputs are recorded for further requirements analysis. Prototyping is building user interface without adding detail functionality for user to interpret the features of intended software product. Prototyping It helps giving better idea of requirements. If there is no software installed at client’s end for developer’s reference and the client is not aware of its own requirements, the developer creates a prototype based on initially mentioned requirements. The prototype is shown to the client and the feedback is noted. The client feedback serves as an input for requirement gathering Team of experts visit the client’s Observation 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  LESSON 5 SOFTWARE REQUIREMENTS CHARACTERISTICS Software Requirements Characteristics ◦ Gathering software requirements is the foundation of the entire software development project. Hence, they must be clear, correct and well-defined. ◦ A complete Software Requirement Specifications must be: Comprehensi Clear Correct Consistent Coherent ble Modifiable Verifiable Prioritized Unambiguous Traceable Credible source  LESSON 6 SOFTWARE REQUIREMENTS  Categories of Software Requirements Non- Functional Functional Logical Requirements requirements Functional Requirements Requirements, which are related to functional aspect of software fall into this category. They define functions and functionality within and from the software system. Examples of Functional Requirements Search option given to user to search from various invoices. User should be able to mail any report to management. Users can be divided into groups and groups can be given separate rights. Should comply business rules and administrative functions. Software is developed keeping downward compatibility intact. Non-Functional Requirements Requirements, which are not related to functional aspect of software, fall into this category. They are implicit or expected characteristics of software, which users make assumption of Examples of Non-Functional Requirements Security Logging Storage Configuration Performance Cost Interoperability Flexibility Disaster Accessibility recovery Logical Requirements Must have: Software cannot be said operational without them. Should have: Enhancing the functionality of software. Could have: Software can still properly function with these requirements. Wish list: These requirements do not map to any objectives of software. While developing software, ‘Must have’ must be implemented, ‘Should have’ is a matter of debate with stakeholders and negation, whereas ‘could have’ and ‘wish list’ can be kept for software updates.  LESSON 7 USER INTERFACE REQUIREMENTS User Interface Requirements ◦ User Interface (UI) is an important part of any software or hardware or hybrid system. ◦ A software is widely accepted if it is - effectively providing simple easy to operate quick in response handling yet consistent user operational errors interface User acceptance majorly depends upon how user can use the software. UI is the only way for users to perceive the system. A well performing software system must also be equipped with attractive, clear, consistent and responsive user interface. Otherwise the functionalities of software system can not be used in convenient way. A system is said be good if it provides means to use it efficiently. User Interface Requirements (2) Content Easy Simple Responsive presentation Navigation interface Consistent UI Feedback Default Purposeful elements mechanism settings layout Strategical Group Provide help User centric use of color based view information approach and texture. settings.  LESSON 8 SOFTWARE SYSTEM ANALYST Software System Analyst System analyst in an IT organization is a person, who It is the responsibility of analyst analyzes the requirement of Role of an analyst starts during to make sure that the proposed system and ensures Software Analysis Phase of developed software meets the that requirements are SDLC. requirements of the client. conceived and documented properly & correctly. Responsibilities of System Analyst Analyzing and understanding requirements of intended software Understanding how the project will contribute in the organization objectives Identify sources of requirement Validation of requirement Develop and implement requirement management plan  LESSON 9 SOFTWARE METRICS AND MEASURES Software Metrics and Measures Software Measures can be understood as a process of quantifying and symbolizing various attributes and aspects of software. Software Metrics provide measures for various aspects of software process and software product. Software measures are fundamental requirement of software engineering. They not only help to control the software development process but also aid to keep quality of ultimate product excellent. According to Tom DeMarco, a (Software Engineer), “You cannot control what you cannot measure.” By his saying, it is very clear how important software measures are. Software Metrics Complexity Size Metrics Quality Metrics Metrics Resources Process Metrics Metrics Size Metrics LOC (Lines of Code), mostly calculated in thousands of delivered source code lines, denoted as KLOC. Function Point Count is measure of the functionality provided by the software. Function Point count defines the size of functional aspect of software. 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 Quality Metrics The number of defects found in Quality Metrics Defects, their development process and types and causes, number of defects reported by consequence, intensity of the client after the product is severity and their implications installed or delivered at client- define the quality of product. end, define quality of product. Process Metrics In various phases of SDLC, the methods and tools used, the company standards and the performance of development are software process metrics. Resources Metrics Effort Time Various Resources Used Learning Activities (Self-Assessment Questions(SAQs)) What is Requirements Engineering? What are the Requirements Engineering Processes & Sub-Processes? What are the Functional and Non-Functional Requirements? What are the contents of Software Requirements Specifications (SRS) Document? Suggested Readings Lodhi, F. (n.d.). CS504-Software Engineering – I Lecture Notes. Retrieved from genrica.com › vustuff › CS504: Behera, H. S., & Sahu, K. K. (n.d.). Lecture Notes on Software Engineering - Course Code: BCS-306. Retrieved from www.vssut.ac.in › lecture_notes › lecture1428551142: https://www.vssut.ac.in/lecture_notes/lecture1428551142.pdf Software Engineering Course Lecture Slides. (2018, January 18). Retrieved from Software Engineering Textbook. Software Engineering Tutorial. https://www.tutorialspoint.com/software_engineering/index.htm