[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"doc-seo-240852-105":3,"detail-sidebar-cat-1-en-105":81,"doc-detail-240852-en":126},{"code":4,"msg":5,"data":6},0,"ok",{"site_id":7,"language":8,"slug":9,"title":10,"keywords":11,"description":12,"schema_data":13,"social_meta":74,"head_meta":76,"extra_data":78,"updated_unix":80},105,"en","unit-2-software-engineering-requirements-analysis-and-specification","Unit 2 - Software Engineering - Requirements Analysis and Speciﬁcation","","Unit 2 covers requirements analysis and specification within a plan-driven software engineering lifecycle. It explains why requirements must be understood and documented before development to prevent costly iterative changes, and how a Software Requirements Specification (SRS) is produced after feasibility approval and ends upon review of the SRS document. The unit distinguishes requirements gathering (elicitation) from requirements analysis and describes key methods such as studying documentation, interviews, task analysis, scenario analysis, and form analysis, including common problems like anomalies.",{"@graph":14,"@context":73},[15,34,56],{"@type":16,"itemListElement":17},"BreadcrumbList",[18,23,27,31],{"item":19,"name":20,"@type":21,"position":22},"https://docshare.wps.com","Home","ListItem",1,{"item":24,"name":25,"@type":21,"position":26},"https://docshare.wps.com/template/","Template",2,{"item":28,"name":29,"@type":21,"position":30},"https://docshare.wps.com/template/presentations/","Presentations",3,{"item":32,"name":10,"@type":21,"position":33},"https://docshare.wps.com/template/unit-2-software-engineering-requirements-analysis-and-specification/240852/",4,{"url":32,"name":10,"@type":35,"image":36,"author":41,"headline":10,"publisher":44,"fileFormat":47,"inLanguage":8,"description":12,"dateModified":48,"datePublished":49,"encodingFormat":47,"isAccessibleForFree":50,"interactionStatistic":51},"DigitalDocument",{"url":37,"@type":38,"width":39,"height":40},"https://docshare.wps.com/thumbnails/unit-2-software-engineering-requirements-analysis-and-specification/240852.png","ImageObject",442,249,{"name":42,"@type":43},"Aran","Person",{"url":19,"name":45,"@type":46},"DocShare","Organization","application/pdf","2026-10-30","2026-09-11",true,{"@type":52,"interactionType":53,"userInteractionCount":55},"InteractionCounter",{"@type":54},"ViewAction",16,{"@type":57,"mainEntity":58},"FAQPage",[59,65,69],{"name":60,"@type":61,"acceptedAnswer":62},"Why must customer requirements be documented before starting software development?","Question",{"text":63,"@type":64},"Plan-driven life cycle models require exact customer requirements to be understood and documented first. Skipping this increases iterative changes later and significantly raises development costs.","Answer",{"name":66,"@type":61,"acceptedAnswer":67},"When does the requirements analysis and specification phase start and end?",{"text":68,"@type":64},"It starts after the feasibility study confirms financial and technical viability. It ends when the Software Requirements Specification (SRS) document is developed and reviewed.",{"name":70,"@type":61,"acceptedAnswer":71},"What is the purpose of the SRS document?",{"text":72,"@type":64},"The SRS document helps clearly understand customer requirements and systematically organize them for later activities in subsequent lifecycle phases.","https://schema.org",{"og:url":32,"og:type":75,"og:title":10,"og:site_name":45,"og:description":12},"article",{"robots":77,"canonical":32},"index,follow",{"doc_id":79,"site_id":7},240852,1791525623,{"code":4,"msg":82,"data":83},"success",[84,88,93,98,103,107,112,117,122],{"id":85,"doc_module":22,"doc_module_name":25,"category_name":29,"show_sort_weight":86,"slug":87},11,90,"presentations",{"id":89,"doc_module":22,"doc_module_name":25,"category_name":90,"show_sort_weight":91,"slug":92},12,"Resumes",80,"resumes",{"id":94,"doc_module":22,"doc_module_name":25,"category_name":95,"show_sort_weight":96,"slug":97},14,"Invoices",70,"invoices",{"id":99,"doc_module":22,"doc_module_name":25,"category_name":100,"show_sort_weight":101,"slug":102},15,"Posters",60,"posters",{"id":55,"doc_module":22,"doc_module_name":25,"category_name":104,"show_sort_weight":105,"slug":106},"Social Media",50,"social-media",{"id":108,"doc_module":22,"doc_module_name":25,"category_name":109,"show_sort_weight":110,"slug":111},17,"Forms",40,"forms",{"id":113,"doc_module":22,"doc_module_name":25,"category_name":114,"show_sort_weight":115,"slug":116},18,"Letters",30,"letters",{"id":118,"doc_module":22,"doc_module_name":25,"category_name":119,"show_sort_weight":120,"slug":121},21,"Paper Templates",5,"papers-templates",{"id":123,"doc_module":22,"doc_module_name":25,"category_name":124,"show_sort_weight":4,"slug":125},158,"General","general-158",{"code":4,"msg":82,"data":127},{"doc_id":79,"user_id":128,"nickname":42,"user_avatar":129,"doc_module":22,"category_id":85,"category_name":29,"doc_title":10,"doc_description":12,"doc_content":130,"file_id":131,"file_url":132,"file_type":133,"file_size":134,"view_count":55,"is_deleted":4,"is_public":22,"is_downloadable":22,"audit_status":22,"page_count":94,"language":135,"language_code":8,"site_id":7,"html_lang":8,"table_of_contents":136,"faqs":137,"seo_title":138,"seo_description":12,"update_tm":139,"read_time":120},137455076865,"https://ap-avatar.wpscdn.com/davatar_29158cc5080c5b710cf443261637dec0","UNIT 2  \nContents:  \nRequirements Analysis and Speciﬁcation: Requirements Gathering and Analysis, Software Requirement Speciﬁcation (SRS): Characteristics of good SRS, Functional Requirements, Organization of SRS.  \nSoftware Design: Overview of the Design Process, How to Characterize a Design? Cohesion and Coupling, Approaches to Software Design.  \nRequirements Analysis and Speciﬁcation  \n● All plan-driven life cycle models prescribe that before starting to develop a software, the exact requirements of the customer must be understood and documented.  \n● Starting development work without properly understanding and documenting the requirements increases the number of iterative changes in the later life cycle phases, and thereby alarmingly pushes up the development costs.  \n● A good requirements document not only helps to form a clear understanding of various features required from the software, but also serves as the basis for various activities carried out during later life cycle phases.  \nOverview of requirements analysis and speciﬁcation:  \n● The requirements analysis and speciﬁcation phase starts after the feasibility study stage is complete and the project has been found to be ﬁ nancially viable and technically feasible.  \n● The requirements analysis and speciﬁcation phase ends when the requirements speciﬁcation document has been developed and reviewed.  \n● The requirements speciﬁcation document is usually called the software requirements speciﬁcation (SRS) document.  \n● The goal of the requirements analysis and speciﬁcation phase is to clearly understand the customer requirements and to systematically organize the requirements into a document called the Software Requirements Speciﬁcation (SRS) document.  \nWho performs requirements analysis  \n● Requirements analysis and speciﬁcation activity is usually carried out by a few experienced members of the development team.  \n● It normally requires them to spend some time at the customer site.  \n● The engineers who gather and analyze customer requirements and then write the requirements speciﬁcation document are known as system analysts.  \nRequirements analysis and speciﬁcation phase mainly involves carrying out the following two important activities:  \n● Requirements gathering and analysis.  \n● Requirements speciﬁcation.  \nUnit 2 : Software Engineering [20 IT3302] PVP20  \nRequirements gathering and analysis:  \n● The complete set of requirements are almost never available in the form of a single document from the customer.  \n● Complete requirements are rarely obtainable from any single customer representative.  \n● We can conceptually divide the requirements gathering and analysis activity into two separate tasks: Requirements gathering and Requirements Analysis  \nRequirements gathering.  \n● Requirements gathering is also popularly known as requirements elicitation.  \n● The primary objective of the requirements gathering task is to collect the requirements from the stakeholders.  \n● A stake holder is a source of the requirements and is usually a person, or a group of persons who either directly or indirectly are concerned with the software.  \n● It is very diﬃcult to gather all the necessary information from a large number of stakeholders and from information scattered across several pieces of documents.  \n● Gathering requirements turns out to be especially challenging if there is no working model of the software being developed.  \n● Important ways in which an experienced analyst gathers requirements:  \n● Studying existing documentation:  \n○ The analyst usually studies all the available documents regarding the system tobe developed before visiting the customer site.  \n○ Customers usually provide a statement of purpose (SoP) document to the developers.  \n● Interview:  \n○ Typically, there are many different categories of users of a software.  \n○ Each category of users typically requires a different set of features from the software.  \n○ Therefore, it is important for the analyst to ﬁ ","cbCaijUuTl73dIrA","https://ap.wps.com/l/cbCaijUuTl73dIrA","pdf",531613,"English","# Requirements Analysis and Speciﬁcation\n## Overview and Phase Goals\n## Who Performs Requirements Analysis\n## Requirements Gathering and Analysis\n### Requirements Gathering (Elicitation)\n### Requirements Analysis\n## Key Techniques: Documentation, Interview, Task and Scenario Analysis, Form Analysis","[{\"question\":\"Why must customer requirements be documented before starting software development?\",\"answer\":\"Plan-driven life cycle models require exact customer requirements to be understood and documented first. Skipping this increases iterative changes later and significantly raises development costs.\"},{\"question\":\"When does the requirements analysis and specification phase start and end?\",\"answer\":\"It starts after the feasibility study confirms financial and technical viability. It ends when the Software Requirements Specification (SRS) document is developed and reviewed.\"},{\"question\":\"What is the purpose of the SRS document?\",\"answer\":\"The SRS document helps clearly understand customer requirements and systematically organize them for later activities in subsequent lifecycle phases.\"}]","Unit 2 - Software Engineering - Requirements Analysis and Speciﬁcation | PDF",1789166526]