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 byBlaise Lyddon
Modified about 1 year ago
Requirements Engineering © NC State Software Engineering Faculty L01 - 1
Scope of Software Project Failures WHY PROJECTS FAIL % 1. Incomplete Requirements Lack of user involvement Lack of resources Unrealistic Expectations Lack of executive support Changing requirements Lack of planning Didn’t need it any longer Lack of IT management Technology illiteracy 4.3 Jim Johnson, The Standish Group International Project Leadership Conference, May 1995, Chicago © NC State Software Engineering Faculty L01 - 2
Relative Cost to Fix an Error Boehm’s analysis of 63 s/w development projects (IBM, GTE, TRW, etc.) to Determine ranges in cost for errors created by false assumptions in req’ts phase But not detected till later phases © NC State Software Engineering Faculty L01 - 3
Requirements Software Requirement: condition or capability needed by a user to solve a problem or achieve an objective that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document –Description of what the customers wants –May be buried beneath layers of assumptions, misconceptions, and politics © NC State Software Engineering Faculty L01 - 4
Requirements Engineering Systematic way of developing requirements through an iterative process –Iteration may involve traditional requirements and use cases Results in a specification of the system that stakeholders understand –natural language –easy to understand pictures (UML Diagrams) A stakeholder is a key representative of the groups who have a vested interest in your system and direct or indirect influence on its requirements. © NC State Software Engineering Faculty L01 - 5
Requirements Engineering (2) Analysis: studying user needs to generate system definition that users understand –Fact-finding –Communication –Fact-validation Modeling: translating requirements the user understands to a form that software engineers understand –Representation –Organization © NC State Software Engineering Faculty L01 - 6
Requirements Elicitation Need to understand why not just what –The “why” is the business case and provides context Techniques –Interviews –Observation –Examining Documents and Artifacts –Join Application Design Sessions (JAD) –Groupware –Questionnaires –Prototypes –Focus Groups –On-Site Customer © NC State Software Engineering Faculty L01 - 7
Requirements Validation Critical step in the development process, –Usually after requirements engineering. Also at delivery Requirements validation criteria: –Correctness: The requirements represent the client’s view. –Completeness: All possible scenarios through the system are described, including exceptional behavior by the user or the system –Consistency: There are no functional or nonfunctional requirements that contradict each other –Clarity: There are no ambiguities in the requirements. © NC State Software Engineering Faculty L01 - 8
Requirements Validation Criteria (2) –Concise Don’t “boil the ocean” or extend beyond what is in current release –Feasible: Requirements can be implemented and delivered –Traceability: Each system function can be traced to a corresponding set of functional requirements –Understandable Understandable to stakeholders –Non-prescriptive Everything about what the customer wants and nothing about how the programmer(s) will do it. –Consistent language Shall, should, may “the physician” vs. “the doctor” –Testable Functional requirements should be exercised © NC State Software Engineering Faculty L01 - 9
Types of Requirements Functional requirements: requirements that specify a function that a system or system component must be able to perform –The watch shall display the time. Non-functional requirements: not specifically concerned with the functionality of a system but place restrictions on the product being developed –User visible aspects of the system not directly related to functional behavior –Usability; reliability; privacy; security; availability; performance –Best to translate non-functional to measurable. The response time must be less than 1 second Constraints (“Pseudo requirements”): not user-visible; imposed by the client that restricts the implementation of the system or the development process –The implementation language must be Java. –Unit tests must be written in JUnit. © NC State Software Engineering Faculty L
Expression of Functional Requirements Traditional –“The system shall…” –From the perspective of the system –Contractual –At least one acceptance test per requirement Use cases –Related scenarios of functionality –From the perspective of the user –Cover a high percentage of scenarios © NC State Software Engineering Faculty L
Traditional Functional Requirements Shall (== is required to): used to indicate mandatory requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted: must or will is obsolete Should (== is recommended that): used to indicate –among several possibilities one is recommended as particularly suitable, without mentioning or excluding others –or that a certain course of action is preferred but not necessarily required; –or that (in the negative form) a certain course of action is deprecated but not prohibited May (== is permitted to): used to indicate a course of action permissible within the limits of the standard Can (== is able to): used for statements of possibility and capability, whether material, physical, or causal https://development.standards.ieee.org/myproject/Public/mytools/draft/styleman.pdf See Section © NC State Software Engineering Faculty L
Traditional Functional Requirements FR51.1: The system shall require that a Health Care Provider records a patient’s length (in inches), weight (in pounds), and head circumference (in centimeters) for an office visit where the patient is younger than three calendar years of age. FR51.2: The system shall require that a Health Care Provider records a patient’s height (in inches), weight (in pounds), and blood pressure for an office visit where the patient is between the ages of three calendar years of age or older and under 12 calendar years of age. © NC State Software Engineering Faculty L
Constraints 1.The system shall be implemented as a Java Server Page web application. 2.The implementation shall adhere to Java coding standards. 3.All non-GUI classes must have at least 80% statement coverage of passing JUnit test cases. 4.To control open connections to the database, all database access should be done through an object that uses the Singleton pattern. © NC State Software Engineering Faculty L
Use Case-Based Requirement Elicitation Use cases describe functional aspects of the system –Another way of modeling functional requirements UML focuses on scenario-based requirements elicitation Scenario: –Sequence of actions that illustrates behavior through the system. –A scenario may be used to illustrate an interaction or the execution of a use case instance © NC State Software Engineering Faculty L
External System Behavior: Use Case Model Complete course of events in the system, from the user’s perspective Use Cases Model: Illustrates –(use cases) the system’s intended functions –(actors) surroundings – external to the system –(use case diagrams) relationships between use cases and actors The collection of all use cases is everything that can be done to/with the system © NC State Software Engineering Faculty L
Actors Are NOT part of the system – they represent anyone or anything that must interact with the system –Only input information to the system –Only receive information from the system –Both input to and receive information from the system Represented in UML as a stickman, even when they are not “people”, such as a billing system © NC State Software Engineering Faculty L
Use Case A sequence of transactions performed by a system that yields a measurable result of values for a particular actor A use case typically represents a major piece of functionality that is complete from beginning to end. A use case must deliver something of value to an actor. Multiple scenarios in one use case Use cases that an actor “wants” begin with verbs. © NC State Software Engineering Faculty L
Template for Flow of Events X Flow of Events for the Use Case X.1 Preconditions What needs to happen (in another use case) before this use case can start? X.2 Main Flow X.3 Subflows Break “normal” flow into pieces “called” by Main Flow or another subflow X.4 Alternative Flows Things that happen outside of the “normal” flow “called” by Main Flow or a subflow Covers multiple related scenarios!!! © NC State Software Engineering Faculty L
Flow of Events vs Scenario Flow of events enumerates all subflows and exception flows. Scenario is one path through your flow of events When you’re testing, make sure you cover a reasonable (80%??) set of scenarios. © NC State Software Engineering Faculty L
UC51 Enter/Edit Basic Health Metrics 51.1 Preconditions: An HCP is a registered user of the iTrust Medical Records system (UC2). The HCP has authenticated himself or herself in the iTrust Medical Records system (UC3). The HCP has started documenting an office visit for the patient (UC11).(UC2)(UC3)(UC11) 51.2 Main Flow: The HCP enters health metrics appropriate for the age of the patient: under 3 years [S1], between 3 years and under 12 years [S2], and 12 and over [S3] (Data Format 6.4.5) [E1]. All ages are calculated as calendar years between the date of the office visit date and the patient’s birthdate.Data Format Sub-flows: [S1] If the patient is under three calendar years of age, the HCP enters the length, weight, head circumference, and household smoking status [S4]. [S2] If the patient is three calendar years of age or older and under 12 calendar years of age, the HCP enters the height, weight, blood pressure, and household smoking status [S4]. © NC State Software Engineering Faculty L
UC51: Enter/Edit Basic Health Metrics [S3] If the patient is 12 calendar years of age or older, the HCP enters the height, weight, blood pressure, household smoking status [S4], patient smoking status [S5], high density lipoproteins (HDL) cholesterol, low density lipoproteins (LDL) cholesterol, and Triglycerides. [S4] The HCP selects one of the following menu options to specify the smoking status of household members: 1 - non-smoking household, 2 - outdoor smokers, 3 - indoor smokers. [S5] The HCP selects one of the following menu options to specify the smoking status of the patient: 1 - Current every day smoker; 2 - Current some day smoker; 3 - Former smoker; 4 - Never smoker; 5 - Smoker, current status unknown; 9 - unknown if ever smoked Alternative Flows: [E1] An error message is displayed describing what entries do not conform to appropriate data formats. © NC State Software Engineering Faculty L
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Topics covered l Functional and non-functional requirements l User requirements.
Chapter - 5 Understanding Requirements Unit II. Introduction Definition : “The broad spectrum of tasks and techniques that lead to an understanding of.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 4, Requirements Elicitation.
Methods for Software Specification Jan Kožusznik. Dept. of Computer Science Technical University of Ostrava
October DMV Team members: Lin Fry, Heather Goulet, Nancy Trefzger.
An Introduction to Object Modeling An Introduction to Object Modeling The approach of using object modeling during systems analysis and design is called.
© Gerald Kotonya and Ian Sommerville 2010 Requirements Validation.
Chapter 4 Requirements Engineering Slide 1 Chapter 4 Requirements Engineering.
Software Requirements Elicitation and Specifications - Fundamentals.
Requirements Elicitation and Use Case Diagrams Prof. Hany Ammar, CSEE Dept., WVU.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java L6 (Adapted For ISE 2005/6 By Ananda Amatya, University.
Requirements (selected from Ian Sommerville slides for “Software Engineering”)
Chapter 6 Use Cases. What is a Use Case? A Use Case is a text story of some actor using a system to meet one or more goals (or not).
1 GREY BOX TESTING Web Apps & Networking Session 10 Boris Grinberg
PLANNING THE AUDIT Individual audits must be properly planned to ensure: Appropriate and sufficient evidence is obtained to support the auditors opinion;
CII Saxion Hogeschool Enschede 1 Object georiënteerd Ontwerpen met UML Saxion Hogeschool Enschede, januari 2005.
Project Management Dr. Anbang Qi Prof. of International Business School of Nankai University.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
Lecture 5: Requirements Engineering Dr Valentina Plekhanova University of Sunderland, UK
Unit-V -SOFTWARE QUALITY. To develop and deliver robust system, we need a high level of confidence that Each component will behave correctly Collective.
תהליך הפיתוח האחוד (The Unified Process) 1. Motivation: Analysis and Design Should Be Done Iteratively! Presented 1981, this is one of the most famous.
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 4 Slide 1 Requirements Engineering u Establishing what the customer requires from a software.
Page 1 R Copyright © 1997 by Rational Software Corporation Analysis and Design with UML.
Operational Concepts and the Case for Use Cases Unifying UML with Systems Engineering Raymond W Jorgensen Rockwell Collins, Inc.
Testing Relational Database. Overview Once the design of a database system has been completed, the developers are ready to move into the implementation.
March 2011 P00801: E-Business Information Systems 1 Lecture 6 E-Business Modelling with UML Prof. Hong Zhu Department of Computing and Electronics Module.
Testing the Workflows of a System Vasil Chimev Junior QA Engineer Centaur Team Centaur Team Telerik QA Academy Telerik QA Academy.
Software Development QA Best Practices May 20, 2010 Suzette Hackl, CSM Senior Project Manager Skyline Technologies, Inc.
CSDP Preparation Course Module II: Software Requirements.
1 Test documentation and Test case design Iana Mourza QA Lead/Release Lead VMware, Inc
© 2016 SlidePlayer.com Inc. All rights reserved.