[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"detail-sidebar-cat-1-en-105":3,"doc-detail-242056-en":53,"doc-seo-242056-105":76},{"code":4,"msg":5,"data":6},0,"success",[7,14,19,24,29,34,39,44,49],{"id":8,"doc_module":9,"doc_module_name":10,"category_name":11,"show_sort_weight":12,"slug":13},11,1,"Template","Presentations",90,"presentations",{"id":15,"doc_module":9,"doc_module_name":10,"category_name":16,"show_sort_weight":17,"slug":18},12,"Resumes",80,"resumes",{"id":20,"doc_module":9,"doc_module_name":10,"category_name":21,"show_sort_weight":22,"slug":23},14,"Invoices",70,"invoices",{"id":25,"doc_module":9,"doc_module_name":10,"category_name":26,"show_sort_weight":27,"slug":28},15,"Posters",60,"posters",{"id":30,"doc_module":9,"doc_module_name":10,"category_name":31,"show_sort_weight":32,"slug":33},16,"Social Media",50,"social-media",{"id":35,"doc_module":9,"doc_module_name":10,"category_name":36,"show_sort_weight":37,"slug":38},17,"Forms",40,"forms",{"id":40,"doc_module":9,"doc_module_name":10,"category_name":41,"show_sort_weight":42,"slug":43},18,"Letters",30,"letters",{"id":45,"doc_module":9,"doc_module_name":10,"category_name":46,"show_sort_weight":47,"slug":48},21,"Paper Templates",5,"papers-templates",{"id":50,"doc_module":9,"doc_module_name":10,"category_name":51,"show_sort_weight":4,"slug":52},158,"General","general-158",{"code":4,"msg":5,"data":54},{"doc_id":55,"user_id":56,"nickname":57,"user_avatar":58,"doc_module":9,"category_id":8,"category_name":11,"doc_title":59,"doc_description":60,"doc_content":61,"file_id":62,"file_url":63,"file_type":64,"file_size":65,"view_count":66,"is_deleted":4,"is_public":9,"is_downloadable":9,"audit_status":9,"page_count":67,"language":68,"language_code":69,"site_id":70,"html_lang":69,"table_of_contents":71,"faqs":72,"seo_title":73,"seo_description":60,"update_tm":74,"read_time":75},242056,137454149569,"Lute","https://ap-avatar.wpscdn.com/davatar_29158cc5080c5b710cf443261637dec0","Defining the System - Software Requirements Engineering Lecture #8","Lecture 8 focuses on defining the system within the software requirements engineering process. It explains why requirements must be captured in an agreed, reviewable form despite stakeholder diversity, budgets, and schedules. The lecture outlines how to organize requirements into sets, distinguishes vision documents from software requirements specifications, and describes parent versus software-only requirement documents. It also covers handling requirements intended for future releases and the purpose of the vision document to align teams toward shared objectives.","1  \nSOFTWARE REQUIREMENTS ENGINEERING  \nLECTURE \\# 8  \nDEFINING THE SYSTEM  \n19th June, 2013  \nEngr. Ali Javed  \nInstructor Information  \n2  \n􀂉 Course Instructor: Engr. Ali Javed  \nAssistant Professor  \nDepartment of Software Engineering  \nU. E.T Taxila  \n􀀳 Email: [ali.javed@uettaxila.edu.pk](ali.javed@uettaxila.edu.pk)  \n􀀳 Website: [http://web.uettaxila.edu.pk/uet/UETsub/perSites/mySite.asp?frmEmail=ali.javed@uettaxila.edu.pk](http://web.uettaxila.edu.pk/uet/UETsub/perSites/mySite.asp?frmEmail=ali.javed@uettaxila.edu.pk)  \n􀀳 Contact No: +92-51-9047747  \n􀀳 Office hours:  \n􀂄 Monday, 09:00-11:00, Office \\# 7 S. E.D  \n􀂉 Lab Instructor: Engr. Asra, Engr. Sobia  \nEngr. Ali Javed  \n3 Presentation Outline  \n• Organizing Requirements Information  \n• Future Requirements  \n• Vision Document  \n• Components of Vision Document  \n• Delta Vision Document  \n• Vision Document Template  \nEngr. Ali Javed  \nOrganizing Requirements Information  \n4  \n􀂉 Whether expressed as user needs, a list of features, a set of use cases, or another format, requirements must be captured and documented.  \n􀂉 If you were the only developer as well as maintainer or user of the system, you might consider designing and coding it immediately after identifying your needs.  \n􀂉 However, few system developments have such simplicity. More likely, developers and users are mutually exclusive, and many stakeholders are involved in software development. All parties must reach agreement about what system is being built.  \n􀂉 Realities of budgets and schedules make it unlikely that all user needs are going to be satisfied in any  \nparticular release.  \nEngr. Ali Javed  \nOrganizing Requirements Information  \n5  \n􀂉 Unavoidable communication problems among the stakeholders demand that requirements be captured in a way that they can be reviewed and approved and to which all parties can agree.  \n􀂉 You will need to maintain requirements organized into multiple requirements sets, each set reflecting the requirements for a particular system, a subsystem, or a number of subsystems together, as in the examples below.  \n􀀹 One / set defines the features of the system in general terms, and another defines requirements in more specific terms. Often, the former is called the Vision document, whereas the latter is called the Software Requirements Specification  \n􀀹 One \"parent\" document defines requirements for the overall\"system,“ including hardware, software, people, and procedures, and another defines requirements for just the software piece. Often the former document is called a System Requirements Specification, whereas the latter is known as Software Requirements Specification  \nEngr. Ali Javed  \nOrganizing Requirements Information  \n6  \n􀀹 One set defines the full set of requirements for a family of products, and is called Product family requirements document or Product family vision document  \n􀀹 One set describes the overall business requirements and business environment in which the  \nproduct will belong to, this document is called business requirements document  \nEngr. Ali Javed  \nOrganizing Requirements of Complex Hardware & Software Systems  \n7  \n􀂉 Some systems are sufficiently complex that the only reasonable way to visualize and to build them is as a system of subsystems, which in turn are visualized as systems of subsystems, containing hardware as well as software components, depicted in Figure 1  \n􀂉 In these cases, a system-level requirements set is created that describes the system, as well as the system-level use cases that describe functional behavior of the system.  \nEngr. Ali Javed Figure 1:: A system of subsystems  \nOrganizing Requirements of Complex Hardware & Software Systems  \n8  \n􀂉 Next, requirements are developed for each subsystem. These should describe the external behavior of the subsystem completely, without reference to any of its subsystems , as shown in Figure 2.  \nFigure 2:: Hierarchy of requirements resulting from system design  \nEngr. Ali Javed  \nFuture Requireme","cbCaisBpEFcupOwk","https://ap.wps.com/l/cbCaisBpEFcupOwk","pdf",1114431,7,25,"English","en",105,"# Presentation Outline\n## Organizing Requirements Information\n## Future Requirements\n## The Vision Document\n## Components of Vision Document\n## Delta Vision Document\n## Vision Document Template","[{\"question\":\"How should requirements for the next release be handled?\",\"answer\":\"They should be recorded, but clearly identified as planned for future releases to avoid confusion about what will be implemented in the current release. Avoid discarding them because they represent value-added work products.\"}]","Defining the System - Software Requirements Engineering Lecture #8 | PDF",1789185107,9,{"code":4,"msg":77,"data":78},"ok",{"site_id":70,"language":69,"slug":79,"title":59,"keywords":80,"description":60,"schema_data":81,"social_meta":129,"head_meta":131,"extra_data":133,"updated_unix":134},"defining-the-system-software-requirements-engineering-lecture-8","",{"@graph":82,"@context":128},[83,99,119],{"@type":84,"itemListElement":85},"BreadcrumbList",[86,90,93,96],{"item":87,"name":88,"@type":89,"position":9},"https://docshare.wps.com","Home","ListItem",{"item":91,"name":10,"@type":89,"position":92},"https://docshare.wps.com/template/",2,{"item":94,"name":11,"@type":89,"position":95},"https://docshare.wps.com/template/presentations/",3,{"item":97,"name":59,"@type":89,"position":98},"https://docshare.wps.com/template/defining-the-system-software-requirements-engineering-lecture-8/242056/",4,{"url":97,"name":59,"@type":100,"image":101,"author":106,"headline":59,"publisher":108,"fileFormat":111,"inLanguage":69,"description":60,"dateModified":112,"datePublished":113,"encodingFormat":111,"isAccessibleForFree":114,"interactionStatistic":115},"DigitalDocument",{"url":102,"@type":103,"width":104,"height":105},"https://docshare.wps.com/thumbnails/defining-the-system-software-requirements-engineering-lecture-8/242056.png","ImageObject",442,249,{"name":57,"@type":107},"Person",{"url":87,"name":109,"@type":110},"DocShare","Organization","application/pdf","2026-10-14","2026-09-12",true,{"@type":116,"interactionType":117,"userInteractionCount":66},"InteractionCounter",{"@type":118},"ViewAction",{"@type":120,"mainEntity":121},"FAQPage",[122],{"name":123,"@type":124,"acceptedAnswer":125},"How should requirements for the next release be handled?","Question",{"text":126,"@type":127},"They should be recorded, but clearly identified as planned for future releases to avoid confusion about what will be implemented in the current release. Avoid discarding them because they represent value-added work products.","Answer","https://schema.org",{"og:url":97,"og:type":130,"og:title":59,"og:site_name":109,"og:description":60},"article",{"robots":132,"canonical":97},"index,follow",{"doc_id":55,"site_id":70},1791748577]