Pub Date : 2001-08-27DOI: 10.1109/ISRE.2001.948579
L. Rosenburg
Summary form only given, as follows. Requirements have always been acknowledged as the backbone of any system. However, in many past development efforts, requirements were paid little heed. At NASA, in recent years, the hue and cry for project development has been "Faster, Better, Cheaper and Safer." This has impacted the way we develop software; it has increased the risks to quality, safety and reliability. At NASA, the Software Assurance Technology Center (SATC) is working with projects to emphasize the criticality of requirements throughout development, not just in the initial phases. This emphasis is on requirements relationship to all aspects of quality, including reliability and safety. In this presentation, we will look at some of these relationships through the eyes of quality.
{"title":"Requirements Management at NASA","authors":"L. Rosenburg","doi":"10.1109/ISRE.2001.948579","DOIUrl":"https://doi.org/10.1109/ISRE.2001.948579","url":null,"abstract":"Summary form only given, as follows. Requirements have always been acknowledged as the backbone of any system. However, in many past development efforts, requirements were paid little heed. At NASA, in recent years, the hue and cry for project development has been \"Faster, Better, Cheaper and Safer.\" This has impacted the way we develop software; it has increased the risks to quality, safety and reliability. At NASA, the Software Assurance Technology Center (SATC) is working with projects to emphasize the criticality of requirements throughout development, not just in the initial phases. This emphasis is on requirements relationship to all aspects of quality, including reliability and safety. In this presentation, we will look at some of these relationships through the eyes of quality.","PeriodicalId":90955,"journal":{"name":"Proceedings. IEEE International Requirements Engineering Conference","volume":"34 1","pages":"275"},"PeriodicalIF":0.0,"publicationDate":"2001-08-27","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"79357878","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2001-08-27DOI: 10.1109/ISRE.2001.948570
D. C. Gause, Savile Row
Summary form only given, as follows. Over the past ten years, we have seen many useful developments in software specification tools, languages, processes, and practices as well as the creation of a number of excellent requirements management tools. Numerous books and articles have been produced on requirements elicitation and development. We have leamed to explicitly specify complex synchronous and asynchronous processes using Petri nets, state diagrams, and structured decision tables. We are exploring the use of fuzzy logic and imprecise probabilities to improve our management of uncertainty in the design process. But, WAIT JUST A MINUTE! Where is the industry with respect to all of this? In spite of this dramatic progress, are there remaining holes and/or opportunities in our practice of Requirements Engineering? We find the industry to be all over the map as the answer to the former and an emphatic YES as an answer to the latter. We take a friendly look at the industry in terms of 1) requirements practices already in place - from none to some to plenty, 2) what the industry means by "requirements," and 3) what companies say to their stockholders and customers versus what their end products reflect. We will suggest a few simple ideas for enhancing the value of requirements over the full life cycle of the product. We will propose a more moderate strategy for realizing, in a practical way, greater opportunity through requirements engineering. We feel that, with modest but consistent effort, we can experience relatively large benefits. We suggest charming the alligators.
{"title":"Where Are We on the \"Fend off the Alligators - Drain the Swamp\" Continuum?","authors":"D. C. Gause, Savile Row","doi":"10.1109/ISRE.2001.948570","DOIUrl":"https://doi.org/10.1109/ISRE.2001.948570","url":null,"abstract":"Summary form only given, as follows. Over the past ten years, we have seen many useful developments in software specification tools, languages, processes, and practices as well as the creation of a number of excellent requirements management tools. Numerous books and articles have been produced on requirements elicitation and development. We have leamed to explicitly specify complex synchronous and asynchronous processes using Petri nets, state diagrams, and structured decision tables. We are exploring the use of fuzzy logic and imprecise probabilities to improve our management of uncertainty in the design process. But, WAIT JUST A MINUTE! Where is the industry with respect to all of this? In spite of this dramatic progress, are there remaining holes and/or opportunities in our practice of Requirements Engineering? We find the industry to be all over the map as the answer to the former and an emphatic YES as an answer to the latter. We take a friendly look at the industry in terms of 1) requirements practices already in place - from none to some to plenty, 2) what the industry means by \"requirements,\" and 3) what companies say to their stockholders and customers versus what their end products reflect. We will suggest a few simple ideas for enhancing the value of requirements over the full life cycle of the product. We will propose a more moderate strategy for realizing, in a practical way, greater opportunity through requirements engineering. We feel that, with modest but consistent effort, we can experience relatively large benefits. We suggest charming the alligators.","PeriodicalId":90955,"journal":{"name":"Proceedings. IEEE International Requirements Engineering Conference","volume":"73 1","pages":"266"},"PeriodicalIF":0.0,"publicationDate":"2001-08-27","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"80037605","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2001-08-27DOI: 10.1109/ISRE.2001.948580
R. Stevens
Summary form only given, as follows. The principles of systems and software engineering can be re-applied beyond the range of the individual project. Traditional enterprise-wide tasks such as technology management, decision-making, organizational objectives, reuse, innovation and outsourcing are amenable to systems engineering. Examples of all of these areas will be presented. The rewards from a disciplined approach are clearly higher when applied at this level. Indeed some aspects (such as re-use) are only possible across projects. The problem of introducing this change is primarily cultural, because of the wide range of skills (including non-technical areas) involved in this coordination. Moreover the time-scales and commitment needed are higher than for individual projects. Shaping systems processes around traditional tasks and terminology helps convince management of the need for system engineering.
{"title":"Systems Engineering at the Enterprise Level","authors":"R. Stevens","doi":"10.1109/ISRE.2001.948580","DOIUrl":"https://doi.org/10.1109/ISRE.2001.948580","url":null,"abstract":"Summary form only given, as follows. The principles of systems and software engineering can be re-applied beyond the range of the individual project. Traditional enterprise-wide tasks such as technology management, decision-making, organizational objectives, reuse, innovation and outsourcing are amenable to systems engineering. Examples of all of these areas will be presented. The rewards from a disciplined approach are clearly higher when applied at this level. Indeed some aspects (such as re-use) are only possible across projects. The problem of introducing this change is primarily cultural, because of the wide range of skills (including non-technical areas) involved in this coordination. Moreover the time-scales and commitment needed are higher than for individual projects. Shaping systems processes around traditional tasks and terminology helps convince management of the need for system engineering.","PeriodicalId":90955,"journal":{"name":"Proceedings. IEEE International Requirements Engineering Conference","volume":"66 1","pages":"276"},"PeriodicalIF":0.0,"publicationDate":"2001-08-27","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"85171251","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2001-01-01DOI: 10.1109/ISRE.2001.948572
I. Hooks
Summary form only given, as follows. We?ve heard of the problems with bad requirements. We all have horror stories about the things that go wrong, the cost overruns, the schedule slips, the lost opportunities. What happens when you do it right. Some companies and government organizations are making requirement process changes and seeing some wonderful results. We will look at what has been done and what has resulted from several real programs. We?ll talk about the things that have worked best, things that did not get the expected results and things that have yet to be tried.
{"title":"What Happens With Good Requirements Practices","authors":"I. Hooks","doi":"10.1109/ISRE.2001.948572","DOIUrl":"https://doi.org/10.1109/ISRE.2001.948572","url":null,"abstract":"Summary form only given, as follows. We?ve heard of the problems with bad requirements. We all have horror stories about the things that go wrong, the cost overruns, the schedule slips, the lost opportunities. What happens when you do it right. Some companies and government organizations are making requirement process changes and seeing some wonderful results. We will look at what has been done and what has resulted from several real programs. We?ll talk about the things that have worked best, things that did not get the expected results and things that have yet to be tried.","PeriodicalId":90955,"journal":{"name":"Proceedings. IEEE International Requirements Engineering Conference","volume":"35 1","pages":"268"},"PeriodicalIF":0.0,"publicationDate":"2001-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"73591337","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Karen Holtzblatt is the inventor of Contextual Inquiry, the customer involvement process adopted by many of the industry’s leaders. In this talk she discusses the issues facing designer, marketers and analysts when they try to define what to build for their market or user population. She describes Contextual Inquiry and the design process based on it, Contextual Design illustrating each point with examples drawn from Karen’s wide experience coaching development teams across the industry. She makes the approach and techniques accessible to people struggling with real projects and real design problems. Dr. Karen Holtzblatt has been designing products and processes in the computer industry for twelve years. As the originator of Contextual Inquiry and Contextual Design, she has pioneered the use of field research methods for requirements gathering in engineering and information technology organizations throughout the world. She has led teams in using these customer-centered techniques to design software, hardware, business processes, and product strategies. She is co-founder of InContext Enterprises Inc., a firm specializing in introducing customer-centered front-end design process into organizations. She holds a
{"title":"Contextual Design: From Customer Data to Implementation","authors":"K. Holtzblatt","doi":"10.1109/RE.1999.10000","DOIUrl":"https://doi.org/10.1109/RE.1999.10000","url":null,"abstract":"Karen Holtzblatt is the inventor of Contextual Inquiry, the customer involvement process adopted by many of the industry’s leaders. In this talk she discusses the issues facing designer, marketers and analysts when they try to define what to build for their market or user population. She describes Contextual Inquiry and the design process based on it, Contextual Design illustrating each point with examples drawn from Karen’s wide experience coaching development teams across the industry. She makes the approach and techniques accessible to people struggling with real projects and real design problems. Dr. Karen Holtzblatt has been designing products and processes in the computer industry for twelve years. As the originator of Contextual Inquiry and Contextual Design, she has pioneered the use of field research methods for requirements gathering in engineering and information technology organizations throughout the world. She has led teams in using these customer-centered techniques to design software, hardware, business processes, and product strategies. She is co-founder of InContext Enterprises Inc., a firm specializing in introducing customer-centered front-end design process into organizations. She holds a","PeriodicalId":90955,"journal":{"name":"Proceedings. IEEE International Requirements Engineering Conference","volume":"9 1","pages":"1-"},"PeriodicalIF":0.0,"publicationDate":"1999-06-07","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"87566016","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Requirements, Use Cases, the UML and The Rational Unified Process","authors":"Ian Spence","doi":"10.1109/RE.1999.10002","DOIUrl":"https://doi.org/10.1109/RE.1999.10002","url":null,"abstract":"","PeriodicalId":90955,"journal":{"name":"Proceedings. IEEE International Requirements Engineering Conference","volume":"52 1","pages":"3-"},"PeriodicalIF":0.0,"publicationDate":"1999-06-07","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"89647124","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Increasing the Role of RE in the Development of Dependable Systems","authors":"C. Heitmeyer, Philip Morris","doi":"10.1109/RE.1999.10010","DOIUrl":"https://doi.org/10.1109/RE.1999.10010","url":null,"abstract":"","PeriodicalId":90955,"journal":{"name":"Proceedings. IEEE International Requirements Engineering Conference","volume":"08 1","pages":"191-"},"PeriodicalIF":0.0,"publicationDate":"1999-06-07","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"86082856","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"From \"Requirements Engineering\" to \"Design for Usefulness\"","authors":"C. Potts","doi":"10.1109/RE.1999.10007","DOIUrl":"https://doi.org/10.1109/RE.1999.10007","url":null,"abstract":"","PeriodicalId":90955,"journal":{"name":"Proceedings. IEEE International Requirements Engineering Conference","volume":"2006 1","pages":"189-"},"PeriodicalIF":0.0,"publicationDate":"1999-06-07","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"89696206","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：