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
SEG 3300 W RITING B ETTER R EQUIREMENTS Supplement to Chapter 4 Source: Ian Zimmerman, Daniel Amyot Telelogic, July 9, 2001.
Systems Analysis – Analyzing Requirements. Analyzing requirement stage identifies user information needs and new systems requirements IS dev team.
Tarkvaranõuded ja nende vormistamise tehnikad Enn Õunapuu
The Software Development Life Cycle: An Overview Presented by Maxwell Drew and Dan Kaiser Southwest State University Computer Science Program.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
Unit 211 Requirements Phase The objective of this section is to introduce software system requirements and to explain different ways of expressing these.
System Requirement Specification and System Planning.
Smart Home Technologies System Engineering. System Engineering in Intelligent Environments Intelligent Environments are complex systems consisting of.
1 Requirements Analysis Lecture # Recap of Requirements Elicitation - 1 Requirements elicitation deals with discovering requirements for a software.
CS 411W - Notes Product Development Documentation.
Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity,
1 Quality Attributes of Requirements Documents Lecture # 25.
Approaching a Problem Where do we start? How do we proceed?
Definition Importance of SRS Characteristics of SRS Format of SRS- e.g.
Unit 241 Requirements and Design Requirements Phase Design Phase Architectural Design Detailed Design.
What colour is the house on the hill? Waterloo – Wellington IIBA Chapter presentation April 11, 2007 David Milne.
Designing a Product Product design is usually a problem that requires a creative Design and/or manufacturing solution.
CT1404 Lecture 2 Requirement Engineering 1 1. Today's Lecture Definition of a Software Requirement Definition of Software Requirements Management Characteristics.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Capturing the requirements Requirement: a feature of the system or a description of something the system is capable of doing in order to fulfill the.
1 Software Requirements Specification Lecture 14.
Systems Development Life Cycle SDLC: A simplified introduction.
Chapter 6,and 7 in textbook 1 1. Objectives To understand the concept of software requirements To understand the difference between functional and non.
1/16/2016Engr. Ali Ahmed1 Software Requirements Specification (SRS) Engr. Ali Ahmed C&SE Department BUKC.
6/6/01 1 Copyright 2001 by Ralph R. Young Effective Requirements Practices Designed to improve individual, project, and organizational effectiveness. Based.
Software Requirements By: Eshcar Hilel Michael Beder.
1 The Requirements Problem Chapter 1. 2 Standish Group Research Research paper at: php (1994)
CPSC 873 John D. McGregor Session 2 Preparing for Requirements V & V.
Algorithms and Problem Solving-1 Algorithms and Problem Solving.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
S/W Project Management Software Project Planning.
Requirements Analysis Outline –Requirement engineering Feasibility study Requirement elicitation and analysis Requirements specification –Types of requirements.
9 1 Chapter 9 Database Design Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel.
Page 1W4D1 Requirements (recap) Requirements = desired behaviour Process –Elicitation (extracting requirements from stakeholders) –Analysis Everything.
INTRODUCTION TO SYSTEM ANALYSIS AND DESIGN 1. WHAT IS AN INFORMATION SYSTEM? An information system is a collection of interrelated components that collect,
Lecture 7: Requirements Engineering. Waterfall Model.
1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.
1 Chapter 8 Building the Analysis Model (1) Analysis Concepts and Principles.
Certification and Accreditation CS Phase-1: Definition Atif Sultanuddin Raja Chawat Raja Chawat.
Dr. Tom WayCSC Software Requirements CSC 4700 Software Engineering Lecture 2 Based on Sommerville, Chapter 6.
Better Specifications. What is a Specification? A Statement of the Customers Needs In the Form of Required Characteristics of a Product A Component of.
System Development Life Cycle (SDLC). Activities Common to Software Projects Planning : Principles Principle #1. Understand the scope of the project.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
Properties of Good Requirements Chapter 8. Understandable by end users End-users are not often software engineers. Terminology used must agree with end-
Requirements Management with Use Cases Module 2: Introduction to RMUC Requirements Management with Use Cases Module 2: Introduction to RMUC.
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
Algorithms and Problem Solving. Learn about problem solving skills Explore the algorithmic approach for problem solving Learn about algorithm development.
© 2017 SlidePlayer.com Inc. All rights reserved.