We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byJulissa Maslyn
Modified over 2 years ago
© 2014 Systems and Proposal Engineering Company. All Rights Reserved Using Natural Language Parsing (NLP) for Automated Requirements Quality Analysis Chris Ritter, Daniel Hettema, Steven H. Dam, Ph.D., ESEP, SPEC Innovations April 2014
© 2014 Systems and Proposal Engineering Company. All Rights Reserved 1 Requirement Levels The Requirements Hierarchy Number of Requirements, Level of Detail Increases User Needs Conceptual Requirements System Requirements Application/Component Specifications A capability or feature identified by a User as being needed to perform his mission A high-level requirement generated during the concept development phase. Contained in ORD, CONOPS A requirement that describes in technical language the desired capabilities of a system. Requirement that is at the level of detail needed for actually designing a new capability. Contained in System Requirements Specification (SRD)
© 2014 Systems and Proposal Engineering Company. All Rights Reserved 2 Characteristics of Good Requirements Each individual requirement should be: –Correct: Describes the users true intent and is legally possible –Complete: Express a whole idea –Clear: Unambiguous and not confusing –Consistent: Not in conflict with other requirements –Verifiable: Provable (within realistic cost and schedule) that the system meets the requirement –Traceable: Uniquely identified, and able to be tracked to predecessor and successor lifecycle items/objects –Feasible: Able to be implemented with existing technology, and within cost and schedule –Modular: Can be changed without excessive impact on other requirements –Design: Does not impose a specific solution on design; says what, Independent not how
© 2014 Systems and Proposal Engineering Company. All Rights Reserved 3 Avoid these Pitfalls DONT use ambiguous language DONT use bullet lists; use numbered lists instead DONT use jargon DONT use language that provides an escape clause –Ex: The user shall be able to access the Internet as often as is practicable DONT write long, rambling sentences DONT put two requirements in one sentence; e.g., The system shall … and … DONT use vague terms -- Ex: user-friendly DONT include suggestions or possibilities – Ex: may, should, ought DONT include wishful thinking – Ex: The system shall be 100% reliable
© 2014 Systems and Proposal Engineering Company. All Rights Reserved How Do We Ensure Quality Requirements? Follow the rules for what makes a good requirement Enforce the rule requires significant training and discipline Most tools help manage the requirements, but do not help you track the quality of the requirements 4
© 2014 Systems and Proposal Engineering Company. All Rights Reserved Solution 1: Identify Requirements on Import Innoslates one button Import Analyzer identifies requirements vs. statements (context for a requirements) by using a key word search (will, shall, should, or requirement) Requirements entities have quality attributes associated with them The user can transform a statement to a requirement and vice versa 5
© 2014 Systems and Proposal Engineering Company. All Rights Reserved Requirement Entities Each quality factor has a Yes/No value to determine if it meets the requirement Uncertain what attributes means? –Hover over name and definitions appear 6
© 2014 Systems and Proposal Engineering Company. All Rights Reserved Solution 2: Innoslates Quality Check 7 Run quality checker to automatically analyze the quality attributes of the requirements
© 2014 Systems and Proposal Engineering Company. All Rights Reserved Quality Check Uses NLP Technology Natural Language Processing: –a field of computer science, artificial intelligence, and linguistics concerned with the interactions between computers and human (natural) languages Innoslate uses this technology to break down sentences into nouns, verbs and adjectives to identify when conjunctions are used (clear), specific types of hardware/software specified (design), and other parameters that affect the requirements quality 8 Wikipedia
© 2014 Systems and Proposal Engineering Company. All Rights Reserved Solution 3: Roll-up Quality Score Change values from No to Yes to adjust score upward 9
© 2014 Systems and Proposal Engineering Company. All Rights Reserved Solution 4: Add Comments Authors and reviewers can add comments and describe changes in more detail 10
© 2014 Systems and Proposal Engineering Company. All Rights Reserved Summary We need to do more than just manage requirements Innoslate brings new technology (NLP) into the automation of requirements analysis However, it does not substitute for good engineering judgment – it is meant as a way to cue the analyst to potential problems 11
M. Elowitz 4/11/07 1 REQUIREMENTS FOR PROJECT SUCCESS A Paper by Ralph Young in Crosstalk December, 2006
An Introduction to Object Modeling An Introduction to Object Modeling The approach of using object modeling during systems analysis and design is called.
Requirements (selected from Ian Sommerville slides for “Software Engineering”)
Of An Expert System. Introduction What is AI? Intelligent in Human & Machine? What is Expert System? How are Expert System used? Elements of ES Who are.
ISBN Prentice-Hall, 2006 Chapter 1 What is Software Engineering? Copyright 2006 Pearson/Prentice Hall. All rights reserved.
Data Analysis 1 Chapter 2.1 V3.1 Napier University Dr Gordon Russell.
Chapter 4 Operations and Transactions The Strategic Management of Information Systems.
Using Learning Outcomes and Assessment Criteria Peter Noakes Department of Electronic Systems Engineering University of Essex.
October DMV Team members: Lin Fry, Heather Goulet, Nancy Trefzger.
Software Development QA Best Practices May 20, 2010 Suzette Hackl, CSM Senior Project Manager Skyline Technologies, Inc.
2 Welcome To Defect Management Training Objective: The objective of this course is to learn about standards that emphasize a best practice approach for.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
McGraw-Hill/Irwin © The McGraw-Hill Companies, All Rights Reserved BUSINESS PLUG-IN B14 Systems Development.
Systems Analysis and Design 8 th Edition Chapter 7 Development Strategies.
1419 West Main Street Richmond, Virginia ©2010 CapTech Ventures The Business End of Data Modeling Bob Lambert.
CSDP Preparation Course Module II: Software Requirements.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Topics covered l Functional and non-functional requirements l User requirements.
Testing Relational Database. Overview Once the design of a database system has been completed, the developers are ready to move into the implementation.
Introduction to knowledge management. What is knowledge management Knowledge management can be difficult to define, because it encompasses a wide range.
1 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved. Requirements Engineering Processes.
Software Reuse and Component-Based Software Engineering CIS 376 Bruce R. Maxim UM-Dearborn.
Chapter - 5 Understanding Requirements Unit II. Introduction Definition : “The broad spectrum of tasks and techniques that lead to an understanding of.
Unit-V -SOFTWARE QUALITY. To develop and deliver robust system, we need a high level of confidence that Each component will behave correctly Collective.
Copyright © 2006 Quest Software Best Practices for Web Content Eric Myers, Director, Internet Marketing Ed Mauss, Manager, Marketing Communications Chris.
Chapter 4 Requirements Engineering Slide 1 Chapter 4 Requirements Engineering.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Chapter 5 Software Requirements.
1 Note content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved. Quality Management IS301 – Software.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24Slide 1 Chapter 24 Quality Management.
© Gerald Kotonya and Ian Sommerville 2010 Requirements Validation.
Software Quality Management CIS 376 Bruce R. Maxim UM-Dearborn.
© 2016 SlidePlayer.com Inc. All rights reserved.