Requirements Engineering. Materials: Pressman (chapters 8,9, 10, 11) Sommerville (Chapters 4, 5)

Similar documents
REQUIREMENTS. Michael Weintraub Spring, 2016

Rekayasa Perangkat Lunak

Lecture 8 Requirements Engineering

SE351a: Software Project & Process Management. 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa

MTAT Software Engineering

Requirements Management Made Simple - 5 Easy Steps

Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm. Rao Casturi 09/17/2015

Chapter 4 Objectives

LECTURE 6: Domain Modeling. Ivan Marsic Rutgers University

Requirements. Requirements. Types of Requirement. What Is a Requirement?

Ch 4: Requirements Engineering. What are requirements?

Reducing the costs of rework. Coping with change. Software prototyping. Ways to Cope with change. Benefits of prototyping

Requirements Engineering. Establishing what the customer requires from a software system. Requirements Engineering. What is a Requirement?

Lecture 7: Software Processes. Refresher: Software Always Evolves

Best Practices for Collecting User Requirements

MTAT Software Engineering

copyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc.

The software lifecycle and its documents

Systems Analysis & Design

Objectives. Connecting with Computer Science 2

Structured Analysis and Design

Chapter 8: SDLC Reviews and Audit Learning objectives Introduction Role of IS Auditor in SDLC

Requirements Analysis. Requirement analysis. Requirements analysis 3/11/14. Advanced Programming

Lecture 9 Requirements Engineering II

LTAT Software Engineering

Requirements. Chapter Learning objectives of this chapter. 2.2 Definition and syntax

CMSC 447: Software Engineering I

Requirements engineering

Requirements Analysis

Identify the guidelines for system development. Discuss the purpose of the activities performed in the analysis phase

3/25/2015 Virtual Keypad Android App Help Guide - Rooms SCHEDULES

Standard Glossary of Terms used in Software Testing. Version 3.2. Foundation Extension - Usability Terms

Kanban One-Day Workshop

Marking Guidelines for MVK Projects. MVK11. Version 6.2 (PPD, URD, ADD, revised URD+ADD, and software demo)

Administrivia. Wednesday: Requirements and Specification. CS169 Lecture 4. We assign teams and you start on Monday. Determining Stakeholders and Needs

Requirements and User-Centered Design in an Agile Context

Evolutionary Architecture and Design

Requirements Gathering

Lesson 06. Requirement Engineering Processes

Architecture and Design Evolution

Use Guide STANDARD JIRA CLIENT. (Practical Case)

Requirements Validation and Negotiation

Requirement Analysis

Software Processes. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 4 Slide 1

Software Verification and Validation (VIMMD052) Introduction. Istvan Majzik Budapest University of Technology and Economics

Dilbert Scott Adams. CSc 233 Spring 2012

Requirements Engineering Process

350 Index 2005 GOAL/QPC

Introduction to Software Engineering

The requirements engineering process

AGILE. Getting Started on Your Team. Davisbase. Copyright 2011 Davisbase LLC. Licensed for Classroom Use to ASPE for Webinar Use Only

Marking Guidelines for MVK Projects. MVK12. Version 6.2 (PPD, URD, RURD, ADD and software demo)

Case Management Digital Service Sprint Review Sprint 5.1: 11/16/17 11/29/17. CWDS / Child Welfare Digital Services

INSTITUTE OF AERONAUTICAL ENGINEERING (Autonomous) Dundigal, Hyderabad

Requirement Engineering within an Agile Environment BY KEJI GIWA. Digital Bananas Technology

(Traditional) Software Development Activities

Software Requirements Specification. <Project> for. Version 1.0 approved. Prepared by <author(s)> <Organization> <Date created>

User-centered design and the requirement process

Discovering Computers Living in a Digital World

May 14, :30PM to 2:30PM CST. In Plain English: Cybersecurity and IT Exam Expectations

Fundamentals: Software Engineering. Objectives. Last lectures. Unit 2: Light Introduction to Requirements Engineering

CIS 890: Safety Critical Systems

MTAT Software Engineering. Written Exam 10 January Start: 9:15 End: 11:45

Agile Accessibility. Presenters: Ensuring accessibility throughout the Agile development process

Story Refinement How to write and refine your stories so that your team can reach DONE by the end of your sprint!

Managing Change and Complexity

Introduction to User Stories. CSCI 5828: Foundations of Software Engineering Lecture 05 09/09/2014

Connecting with Computer Science Chapter 13 Review: Chapter Summary:

BCS Level 3 Certificate in Programming Syllabus QAN 603/1192/7

Software architecture in ASPICE and Even-André Karlsson

Incremental development A.Y. 2018/2019

Business Analysis for Practitioners - Requirements Elicitation and Analysis (Domain 3)

JIRA Studio Use Cases and Tutorial basis

CONFERENCE PROCEEDINGS QUALITY CONFERENCE. Conference Paper Excerpt from the 28TH ANNUAL SOFTWARE. October 18th 19th, 2010

CMSC 435: Software Engineering Section 0201

1: Specifying Requirements with Use Case Diagrams

Adopting Agile Practices

Creating an Intranet using Lotus Web Content Management. Part 2 Project Planning

CS3500: Object-Oriented Design Fall 2013

Operator s Guide. Table of Contents

Requirements Engineering: Specification & Validation. Software Requirements and Design CITS 4401 Lecture 18

Systems Analysis and Design in a Changing World, Fourth Edition

Testing in an Agile Environment Understanding Testing role and techniques in an Agile development environment. Just enough, just in time!

Software Documentation

Atlas 2.0. Atlas Help

Rules of Writing Software Requirement Specifications

SAFe Reports Last Update: Thursday, July 23, 2015

Introduction to Software Specifications and Data Flow Diagrams. Neelam Gupta The University of Arizona

User Stories Overrated (Farlig) Lyntale

A Proposal to Develop a Testing Framework for Agile Software Process

System 800xA Public Address System User Manual

Requirements Analysis. SE 555 Software Requirements & Specification

Software Life Cycle. Main issues: Discussion of different life cycle models Maintenance or evolution

(Objective-CS605 Software Engeenring-II)

User Stories Applied, Mike Cohn

Software specification and modelling. Requirements engineering

Introduction to Extreme Programming

PK0-003 Q&As. Project+ (2009) Pass CompTIA PK0-003 Exam with 100% Guarantee. Free Download Real Questions & Answers PDF and VCE file from:

Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm. Rao Casturi 08/27/2015

Software Project Management, 9th Sep.

Transcription:

Requirements Engineering Materials: Pressman (chapters 8,9, 10, 11) Sommerville (Chapters 4, 5)

Definition What is Requirement Engineering? Requirement: A function, constraint or other property that the system must provide to fill the needs of the system s intended user(s) Engineering: implies that systematic and repeatable techniques should be used Requirement engineering: a process by which requirements for a product are defined, managed and tested systematically

Definition What is Requirement Engineering? User Requirements: English statements of what the system is expected to provide to users (all users) and the constraints under which the system must operate System Requirements: detailed descriptions of system functions, services, and operational constraints (WHAT not the HOW)

Definition What is Requirement Engineering? Functional Requirements: Describes what the system should do (Function) Non-Functional Requirements: Describes everything that is not function related: Performance Reliability Cost/Resources Scaling Organizational aspects Environmental Regulatory Safety Security

Definition What is Requirement Engineering? Identifier Priority Requirement REQ1 5 The system shall keep the door locked at all times, unless commanded otherwise by authorized user. When the lock is disarmed, a countdown shall be initiated at the end of which the lock shall be automatically armed (if still disarmed). REQ2 2 The system shall lock the door when commanded by pressing a dedicated button. REQ3 5 The system shall, given a valid key code, unlock the door and activate other devices. REQ4 4 The system should allow mistakes while entering the key code. However, to resist dictionary attacks, the number of allowed failed attempts shall be small, say three, after which the system will block and the alarm bell shall be sounded. REQ5 2 The system shall maintain a history log of all attempted accesses for later review. REQ6 2 The system should allow adding new authorized persons at runtime or removing existing ones. REQ7 2 REQ8 1 REQ9 1 The system shall allow configuring the preferences for device activation when the user provides a valid key code, as well as when a burglary attempt is detected. The system should allow searching the history log by specifying one or more of these parameters: the time frame, the actor role, the door location, or the event type (unlock, lock, power failure, etc.). This function shall be available over the Web by pointing a browser to a specified URL. The system should allow filing inquiries about suspicious accesses. This function shall be available over the Web.

Why is Requirements Engineering hard?

Why is it Important? Use Defines the commitment between the clients and the delivery organiza8on, along with budget and schedule May be set upfront or evolve incrementally 60% of projects face complex domains Defines the acceptance criteria ~45% of project failures involve requirements phase issues (Chaos Study) Incomplete requirements (13%) Lack of user involvement (12%) Changing specificakons (9%) UnrealisKc expectakons (10%) Risks Each individual understands the same statement differently Clear idenkficakon of Minimal Required FuncKonality Perceived versus Actual Agreements Don t lose sight that at the end of the day, it s about what gets delivered. But if you don t know where you are going, it s hard to aim right.

Where does it fit in the Process? System Requirements SpecificaKon and Modeling Specifica8on User Requirements SpecificaKon Business Requirements SpecificaKon Start Elicita8on User Requirements ElicitaKon System Requirements ElicitaKon Feasibility Study Prototypes and Models Valida8on Source: Sommerville, So#ware Engineering, 10 th Ed, Fig 4.6

How do you do it? Process? Aspect- Oriented Requirements Object- Oriented Analysis & Design Requirements gathering Requirements analysis Requirements specificakon Structured Analysis & Design Agile Development User Stories

How do you do it? Process? Source; h]p://old.sigchi.org/bullekn/ 1997.1/h- johnson1.gif

How do you do it? Document it? Ad hoc Diagrams and Models Formal Specifications Math Notations Well Defined Modeling Paradigms UML (Unified Modeling Language) Finite State Machines Petri-Nets

Example Requirements Identifier Priority Requirement REQ1 5 The system shall keep the door locked at all times, unless commanded otherwise by authorized user. When the lock is disarmed, a countdown shall be initiated at the end of which the lock shall be automatically armed (if still disarmed). REQ2 2 The system shall lock the door when commanded by pressing a dedicated button. REQ3 5 The system shall, given a valid key code, unlock the door and activate other devices. REQ4 4 The system should allow mistakes while entering the key code. However, to resist dictionary attacks, the number of allowed failed attempts shall be small, say three, after which the system will block and the alarm bell shall be sounded. REQ5 2 The system shall maintain a history log of all attempted accesses for later review. REQ6 2 The system should allow adding new authorized persons at runtime or removing existing ones. REQ7 2 REQ8 1 REQ9 1 The system shall allow configuring the preferences for device activation when the user provides a valid key code, as well as when a burglary attempt is detected. The system should allow searching the history log by specifying one or more of these parameters: the time frame, the actor role, the door location, or the event type (unlock, lock, power failure, etc.). This function shall be available over the Web by pointing a browser to a specified URL. The system should allow filing inquiries about suspicious accesses. This function shall be available over the Web.

What are User Stories? Similar to system requirements but focus on user. Preferred tool for agile methods As a tenant, I can unlock the doors to enter my apartment. user-role (benefactor) capability business-value

User Stories Identifier User Story Size ST-1 As an authorized person (tenant or landlord), I can keep the doors locked at all times. 4 points ST-2 As an authorized person (tenant or landlord), I can lock the doors on demand. 3 pts ST-3 The lock should be automatically locked after a defined period of time. 6 pts ST-4 As an authorized person (tenant or landlord), I can unlock the doors. (Test: Allow a small number of mistakes, say three.) 9 points ST-5 As a landlord, I can at runtime manage authorized persons. 10 pts ST-6 As an authorized person (tenant or landlord), I can view past accesses. 6 pts ST-7 As a tenant, I can configure the preferences for activation of various devices. 6 pts ST-8 As a tenant, I can file complaint about suspicious accesses. 6 pts

How do you know you have a correct requirement set? How to Validate/Verify? Clear and Unambiguous standard structure has only one possible interpretation Correct: contributes to a real need Understandable: A reader can easily understand the meaning of the requirement Verifiable: can be tested Complete Flaty PowetPoint Presentation www.flaty.com

How do you do it? Process Management? Work backlog Estimated work duration 1) ST-4: Unlock 15 days (9pts) 2) ST-2: Lock 5 days (3pts) 3) ST-5: Manage Users 16 days (10pts) Items pulled by the team into an iteration 4) ST-7: Preferences 10 days (6pts) 5) ST-6: View History 10 days (6pts) 6) ST- Work items 21 days 1st iteration 2nd iteration n-th iteration List prioritized by the customer 5 days Estimated completion date Time

Class Assignment: Requirement Engineering Group: agree on a tool for requirement engineering. We recommend, Confluence Individual: Create an account or log into Confluence make sure you have an account setup for communication and team Group (sub-groups): create list of requirements based on your meetings and notes Group (project manager): Chart out the requirements Group (usability): Chart out a plan for usability testing of the different requirements Deliverables per group on canvas: account info link to requirements in the tool Gantt chart (project manager) plan for usability (usability)