Requirements Engineering ments_analysis.

Slides:



Advertisements
Similar presentations
Software Testing 3 Damian Gordon.
Advertisements

Software Engineering 1. Software development – the grand view 2. Requirements engineering.
Alternate Software Development Methodologies
Acquiring Information Systems and Applications
Software Requirements Analysis and Specification C.Eng 491 Fall
軟工一 吳彥諄. * Scrum overview * What happened to the software * What is the quality attribute * ACRUM * Q&A.
Unit 251 Implementation and Integration Implementation Unit Testing Integration Integration Approaches.
WKES 3202 SOFTWARE REQUIREMENTS ENGINEERING SEMESTER 1 SESSION 2004/2005.
8/28/2005ECEN5543 Req Elicitation1 Targets of Requirements Engineering ECEN 5543 SW Engineering of Standalone Programs University of Colorado, Boulder.
Software engineering Module 1 -Introduction to software process Teaching unit 1 - Requirements engineering Ernesto Damiani Free University of Bozen-Bolzano.
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
SE 555 – Software Requirements & Specifications Introduction
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
1 Software Testing and Quality Assurance Lecture 1 Software Verification & Validation.
S R S S ystem R equirements S pecification Specifying the Specifications.
Requirement engineering for an online bookstore system
Software Requirement Specification(SRS)
Software Process Activities. Process activities Real software processes are inter-leaved sequences of technical, collaborative and managerial activities.
Chapter 4 Capturing the Requirements 4th Edition Shari L. Pfleeger
Requirements Engineering
Problems in handling NFR Term Paper (as-is) problem statement BY AJAYKUMAR ASWATHAPPA CS/SE 6361 EXECUTIVE.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Context of Software Product Design.
Requirements Elicitation. Requirement: a feature or constraint that the system must satisfy Requirements Elicitation: specification of the system that.
Product Quality, Testing, Reviews and Standards
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
Topics Covered: Software requirement specification(SRS) Software requirement specification(SRS) Authors of SRS Authors of SRS Need of SRS Need of SRS.
Based on D. Galin, and R. Patton.  According to D. Galin  Software quality assurance is:  A systematic, planned set of actions necessary to provide.
Software System Engineering: A tutorial
Requirements Engineering How do we keep straight what we are supposed to be building?
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 8 Slide 1 Software Prototyping l Animating and.
Instructor: Peter Clarke
BMAN Integrative Team Project Week 2 Professor Linda A Macaulay.
Software Requirements Engineering CSE 305 Lecture-2.
Requirements Engineering ments_analysis.
1 CS 426 Senior Projects Chapter 3: The Requirements Workflow [Arlow & Neustadt, 2005] January 31, 2012.
Slide 1V&V 10/2002 Software Quality Assurance Dr. Linda H. Rosenberg Assistant Director For Information Sciences Goddard Space Flight Center, NASA
Other Quality Attributes Other Important Quality attributes Variability: a special form of modifiability. The ability of a system and its supporting artifacts.
Lecture 7: Requirements Engineering
1 15 quality goals for requirements  Justified  Correct  Complete  Consistent  Unambiguous  Feasible  Abstract  Traceable  Delimited  Interfaced.
Software Requirements: A More Rigorous Look 1. Features and Use Cases at a High Level of Abstraction  Helps to better understand the main characteristics.
Requirements Engineering Lesson 2. Terminologies:  Software Acquisition is where requirement engineering significantly meets business strategy.  Software.
Systems Development Life Cycle
1 Quality Attributes of Requirements Documents Lecture # 25.
Scenario-Based Analysis of Software Architecture Rick Kazman, Gregory Abowd, Len Bass, and Paul Clements Presented by Cuauhtémoc Muñoz.
OHTO -01 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
CSE 303 – Software Design and Architecture
Software Testing Mehwish Shafiq. Testing Testing is carried out to validate and verify the piece developed in order to give user a confidence to use reliable.
Software Requirements Specification Document (SRS)
 CMMI  REQUIREMENT DEVELOPMENT  SPECIFIC AND GENERIC GOALS  SG1: Develop CUSTOMER Requirement  SG2: Develop Product Requirement  SG3: Analyze.
Chapter 3: The Requirements Workflow [Arlow and Neustadt, 2005] CS 426 Senior Projects in Computer Science University of Nevada, Reno Department of Computer.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 1 Slide 1 6/6/2016 1/25 IT076IU Software Engineering Project Review 2.
© NALO Solutions Limited NALO Solutions, presents the – Revenue Collector App Using Mobile Phones to gather Revenue SOFTWARE ENGINEERING.
 System Requirement Specification and System Planning.
Software Requirements Engineering Session: 1 Topics: Chapters 1 – 3.
System Design, Implementation and Review
Software Process Activities.
Requirements Engineering
SYSTEM ANALYSIS AND DESIGN
Software Prototyping Animating and demonstrating system requirements.
UNIT II.
The Design Process.
Introduction to Software Testing
Introduction to Software Process Models
Software Engineering Lecture #14.
Requirements Engineering Introduction
Software Requirements Specification (SRS) Template.
CEN 5035, Software Engineering
Requirements Document
Presentation transcript:

Requirements Engineering ments_analysis

Stakeholders Anyone who: – interacts with the system – benefits from the system – purchases the system Regulators (financial, safety etc.) Anyone opposed to building the system Anyone who interfaces with the system Organizations that integrate with the system

Requirement analysis Stakeholder interviews Joint requirements development sessions Contract-style requirement lists (strengths, weaknesses) User stories (agile development) Measurable goals Prototypes Use cases

Requirements analysis issues Misunderstandings between stakeholders and developers – Stakeholder issues – Engineer/developer issues Attempted solutions – Prototyping – Application simulation

Software requirements specification ements_Specification ements_Specification A complete description of the behavior of a system to be developed It may include: – Use cases – Non-functional requirements (performance constraints, quality standards, design constraints)

Software Requirements Specification (SRS) example Introduction – Overall description – Interfaces – Constraints (e.g. memory, disk) Specific requirements – Functional and performance requirements – Design constraints (e.g. standards compliance) – System attributes (reliability, availabilty, security, maintainability, portability)

Types of Requirements: Customer requirements Where will be used? How it will accomplish its mission? How are its components used? How effective / efficient it is? How long it will be used? In what environments it is expected to operate?

Other types of requirements Architectural Structural Behavioral Functional: ent Non-functional: functional_requirement Performance Design Derived/Allocated

Verification and validation w.r.t requirements Validation: the process of checking that a software system it satisfies its specified requirements and that it achieves its intended goals Verification: whether the results of a given development phase satisfy the requirements Validation: Are we building the right product? Verification: Are we building the product right?