SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 1 Requirements Engineering T-76.4115 Software Development Project.

Slides:



Advertisements
Similar presentations
Testing through user observations User Observation: Guidelines for Apple Developers, Kathleen Gomoll & Anne Nicol, January 1990 Notes based on:
Advertisements

MIS 2000 Class 20 System Development Process Updated 2014.
Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Determining systems requirements Updated: September 2014.
Introduction to Software Engineering Dr. Basem Alkazemi
Ch 4 The Process page 1CS 368 Building Software is Difficult often delivered late often over budget always with errors must be a custom solution complexity.
SWE Introduction to Software Engineering
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
7M701 1 Software Engineering Software Requirements Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 5
Identifying needs and establishing requirements Chapter 7b.
Overview of Software Requirements
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Verification and Validation.
Requirements Gathering : Determining the scope of the system 1. Elicitiation – fact finding 2. Specification 3. Validation.
7M822 Software Requirements Introduction 7 September 2010.
Requirements Engineering Process – 1
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Requirements engineering l The process of establishing the services that the.
Chapter 4 Capturing the Requirements 4th Edition Shari L. Pfleeger
Verification and Validation
Requirements Engineering
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes 1.
Systems Life Cycle A summary of what needs to be done.
SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY The current state of stakeholder-driven requirements engineering.
Requirements Elicitation. Requirement: a feature or constraint that the system must satisfy Requirements Elicitation: specification of the system that.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Verification and Validation.
Chapter 4 – Requirements Engineering
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
1 REQUIREMENT ENGINEERING Chapter 7. 2 REQUIREMENT ENGINEERING Definition Establishing what the customer requires from a software system. OR It helps.
Chapter 5: Requirement Engineering Process Omar Meqdadi SE 2730 Lecture 5 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY User Studies Basic principles, methods, and examples Sari.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
Chapter 4 Requirements engineering Chapter 4 – Requirements Engineering Lecture 1 1.
System Analysis and Design Dr. Taysir Hassan Abdel Hamid Lecture 5: Analysis Chapter 3: Requirements Determination November 10, 2013.
Adaptive Processes © Adaptive Processes Simpler, Faster, Better Software Requirements.
Requirements Elicitation. Who are the stakeholders in determining system requirements, and how does their viewpoint influence the process? How are non-technical.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering.
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.
1 CS 426 Senior Projects Chapter 3: The Requirements Workflow [Arlow & Neustadt, 2005] January 31, 2012.
Lecture 7: Requirements Engineering
Requirements Engineering Overview Senior Design Don Evans.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
Software Life Cycle The software life cycle is the sequence of activities that occur during software development and maintenance.
Requirements Engineering Lesson 2. Terminologies:  Software Acquisition is where requirement engineering significantly meets business strategy.  Software.
Systems Development Life Cycle
SWE 513: Software Engineering
Software Requirements Specification (SRS)
Requirements Engineering Processes. Syllabus l Definition of Requirement engineering process (REP) l Phases of Requirements Engineering Process: Requirements.
1 The Requirements Problem Chapter 1. 2 Standish Group Research Research paper at:  php (1994)
1 Week 8 - Life cycle vs Methodology IT2005 System Analysis & Design.
Requirements Analysis
Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates.
CS223: Software Engineering Lecture 8: Requirement Engineering.
Chapter 3: The Requirements Workflow [Arlow and Neustadt, 2005] CS 426 Senior Projects in Computer Science University of Nevada, Reno Department of Computer.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
Cooper Goal-Directed Design: Practice Session Dr. Cindy Corritore Creighton University ITM 734 Fall 2005.
Software Engineering Developing Requirements. © Lethbridge/Laganière 2001 Chapter 4: Developing requirements2 4.1 Domain Analysis The process by which.
 System Requirement Specification and System Planning.
Classifications of Software Requirements
CSC 480 Software Engineering
The Systems Engineering Context
EKT 421 SOFTWARE ENGINEERING
CS 790M Project preparation (I)
Chapter 3: The Requirements Workflow
Requirements Engineering Process – 1
User Studies Basic principles, methods, and examples
Lecture # 7 System Requirements
Requirements Document
Subject Name: SOFTWARE ENGINEERING Subject Code:10IS51
CS 426 CS 791z Topics on Software Engineering
CS 426 CS 791z Topics on Software Engineering
Presentation transcript:

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 1 Requirements Engineering T Software Development Project I Sari Kujala

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 2 Outline  Requirements engineering  Requirements gathering: interviewing  Requirements analysis

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 3 What is Requirements Engineering (RE)?  The earliest phase of the software development life cycle  The goal is assure that a correct and good product is defined and developed from the stakeholders’ point of view  Possible stakeholders are customers, users, engineers responsible for system development and maintenance

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 4 Why RE is important?  Detecting and correcting errors can be up to 200 times more expensive in the maintenance phase compared to the RE phase (Davis, 1993).  More time and effort invested in the early stages of a software project yields faster cycle times and higher productivity (Blackburn et al., 2000).

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 5 Requirements in the Software Process Requirements definition Analysis & design & implementation & testing Acceptance testing Requirements management

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 6 RE process (Kotonya & Sommerville, 1998)

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 7 User Requirements  User requirements describe any function, constraint, or other property that must be provided to satisfy the user needs.  User requirements are written from user point of view (vs. technical requirements).

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 8 User Requirements User requirements tell WHAT the system shall do from user’s point of view. Users are not interested in technical details. The system is seen as a black box. user group Auser group B

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 9 Classification of requirements  Functional requirements define system functions  HERE: “the name of the high-level use case”  Non-functional requirements describe system qualities  User requirements describe the tasks that the user or another system will accomplish using the system  HERE: use cases

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 10 Non-Functional Requirements  Look and Feel Requirements  Usability Requirements  Performance Requirements  Operational Requirements  Maintainability and Portability Requirements  Security Requirements  Cultural and Political Requirements  Legal Requirements

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 11 Use cases (1/2) IDNimiPrioriteetti UC1SisäänkirjautuminenPakollinen UC2UloskirjautuminenPakollinen UC3Testausprojektin luominenPakollinen

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 12 IDUse Case 1 NimiSisäänkirjautuminen TiivistelmäRekisteröityneen käyttäjän sisäänkirjautuminen ToimijatKaikki käyttäjät pois lukien asiakas Alkuehdot - Perussekvenssi 1.Järjestelmä kysyy identifiointia (käyttäjätunnus, salasana 2.Käyttäjä syöttää käyttäjätunnuksen ja salasanan 3.Järjestelmä tarkistaa käyttäjätunnuksen ja salasanan 4.Järjestelmä päästää käyttäjän sisään kirjautuvan käyttäjän oikeuksilla Poikkeukset 4a. Jos käyttäjätunnus ja salasana pari ei täsmää, järjestelmä tulostaa virheilmoituksen Jälkiehdot Käyttäjä on sisäänkirjautunut järjestelmään kyseisen käyttäjän oikeuksilla Viittaukset testitapauksiin ST-1, ST-2, ST-3

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 13 Requirement gathering (or elicitation)  The goal is to understand  the domain area  the problem to be solved  the needs of the stakeholders

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 14 Why customers and users are involved?  The goal of a new product is to solve a problem in the real world and users are experts in  problems to be solved  tasks to be supported  context and domain area  Involving users and customers as the source of information is related to project success and lower costs (Kujala et al., 2005).

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 15 Requirements gathering in practice  Gather and check the existing material  Identify users and other stakeholders  Describe the main user groups  Gather customer and user needs by interviewing and observing  Document customer and user needs e.g. as a list  Record the source where the needs were gathered

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 16 How to gather user needs? (1/2)  Select different users from different user groups: typical and advanced lead users  Watch, listen to, and talk with users in their own environment  Try to understand their goals and values, present ways of doing the tasks, underlying reasons for the behavior or wants

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 17 How to gather user needs? (2/2)  Treat users as experts  Keep the conversation concrete  Ask users to show how they do things  Gather critical incidents (how it happened last time, yesterday)  Look at used notes, paper and pencil tasks, forms, modifications users have made

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 18 Interviewing: questioning  Listen to interviewee, don’t be too quick in offering an interpretation  Ask one question at a time  Avoid leading and complex questions  Let user freely express himself, let a moment to think about

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 19 Interviewing: information gathering  Ask the user first to tell about his/her work or situation generally  Try to understand the activities of the user  Use information that users provide as the basis for further questioning

SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 20 The language of customers and users  Remember that all kind of information is not easy to tell (e.g. skills)  Collect users terminology and use them (be careful not to use technical terms)  Make minimal assumptions about users and the information that they are giving  Also familiar terms can have different meaning for users