Week 1. The goal of software development To develop quality software – on time on budget – that meets customers’ need However, our customer are quite.

Slides:



Advertisements
Similar presentations
Software Quality David Jones, Director. 2 Agenda What is it and why is it important? How do we deliver it? Conclusions.
Advertisements

1 Requirements and the Software Lifecycle The traditional software process models Waterfall model Spiral model The iterative approach Chapter 3.
Systems Analysis, Prototyping and Iteration Systems Analysis.
Project management Project manager must;
Using UML, Patterns, and Java Object-Oriented Software Engineering Royce’s Methodology Chapter 16, Royce’ Methodology.
Project Plans CSCI102 - Systems ITCS905 - Systems MCS Systems.
9-Jun-15 GCIS 504/GENG 580- The requirements problem1.
Introduction to Requirements (Chapters 1-3 of the requirements text) CSSE 371, Software Requirements and Specification Don Bagert, Rose-Hulman Institute.
R R R CSE870: Advanced Software Engineering (Cheng): Intro to Software Engineering1 Advanced Software Engineering Dr. Cheng Overview of Software Engineering.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
1 Chapter 5: The F1ive Steps in Problem Analysis The five steps in problem analysis. Team Skill 1.
Requirements - Why What and How? Sriram Mohan. Outline Why ? What ? How ?
Chapter 1 Software Development. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-2 Chapter Objectives Discuss the goals of software development.
Major Exam II Reschedule 5:30 – 7:30 pm in Tue Dec 5 th.
SE 555 – Software Requirements & Specifications Introduction
Software Life Cycle Model
Change Request Management
Chapter 9 – Software Evolution and Maintenance
The Software Development Life Cycle: An Overview
S T A M © 2000, KPA Ltd. Software Trouble Assessment Matrix Software Trouble Assessment Matrix *This presentation is extracted from SOFTWARE PROCESS QUALITY:
Chapter 2 Introduction to Requirements Management
Term 2, 2011 Week 3. CONTENTS The physical design of a network Network diagrams People who develop and support networks Developing a network Supporting.
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
Software Testing Life Cycle
Name Hometown Program Employer/Student Fun Fact 1.
Chapter 10 Contemporary Project Management Kloppenborg
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Software System Engineering: A tutorial
Requirements Engineering How do we keep straight what we are supposed to be building?
Writing Quality Requirements Karl E. Wiegers Presented by: Ricardo Carlos.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Software Requirements Presented By Dr. Shazzad Hosain.
Requirements Management with Use Cases Module 2: Introduction to RMUC Requirements Management with Use Cases Module 2: Introduction to RMUC.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software 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.
Chapter 11. Intro  What is Project Management?  Project Manager  Project Failures & Successes Managing Projects  PMBOK  SDLC Core Process 1 – Project.
1 Requirements Management - General concepts - Noureddine Abbadeni King Saud University College of Computer and Information Sciences Based on “Software.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Applied Software Project Management
Rational Requirements Management with Use Cases v5.5 Copyright © Rational Software, all rights reserved 1 Requirements Management with Use Cases.
REQUIREMENTS - WHY WHAT AND HOW? Steve Chenoweth & Chandan Rupakheti CSSE 371 Chapters Requirements Text. Question 6.
12/10/15.  It is a Cross Life Cycle Activity (CLCA) that may be performed at any stage ◦ In fact, some part of it (e.g. risk analysis and management)
Software Requirements and Design Khalid Ishaq
Software Life Cycle The software life cycle is the sequence of activities that occur during software development and maintenance.
Software Requirements: A More Rigorous Look 1. Features and Use Cases at a High Level of Abstraction  Helps to better understand the main characteristics.
Chapter 6 CASE Tools Software Engineering Chapter 6-- CASE TOOLS
Project Management Cross lifecycle Activity
1-1 Software Development Objectives: Discuss the goals of software development Identify various aspects of software quality Examine two development life.
MADALINA CROITORU Software Engineering week 3 Madalina Croitoru IUT Montpellier.
Software Engineering Lecture # 1.
Click to add text Systems Analysis, Prototyping and Iteration.
CSC 480 Software Engineering Test Planning. Test Cases and Test Plans A test case is an explicit set of instructions designed to detect a particular class.
Chapter 1 The Requirements Problem
Software Engineering REQUIREMENT ENGINEERING. Software Engineering Phases.
Lecture 4: Requirements Engineering COSI 120b, Principles of Software Engineering.
1 The Requirements Problem Chapter 1. 2 Standish Group Research Research paper at:  php (1994)
IS2210: Systems Analysis and Systems Design and Change Twitter:
Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates.
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
Requirements Management with Use Cases Module 2: Introduction to RMUC Requirements Management with Use Cases Module 2: Introduction to RMUC.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
1 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Analyzing the Problem.
Software Maintenance1 Software Maintenance.
Introduction to Software Requirement Engineering Nisa’ul Hafidhoh Teknik Informatika
 System Requirement Specification and System Planning.
Advanced Software Engineering Dr. Cheng
Change Request Management
Software Engineering (CSI 321)
KEY PROCESS AREAS (KPAs)
Introduction to Requirements Management
Presentation transcript:

Week 1

The goal of software development To develop quality software – on time on budget – that meets customers’ need However, our customer are quite different… the customer is an external entity The customer is a company that has hired us to develop its software The customer is someone who waiting anxiously for that new application

A look at the data Of course some systems work well… Its also true that there is a wide spectrum of possibilities between perfection and failure In many cases, the results are far more serious.

Study by Standish group. In the USA, we spend > $250 billion/year on IT app dev of appox. 175,000 projects Large company $ Medium –$ Small – $ A staggering 31% of projects will be cancelled before they ever get completed 52.7% projects will cost 189% of their original estimates $81 billion for cancelled projects $59 billion s/w projects that will be completed but will exceed their original time estimates

The root cause of project success and failure The first step in resolving problem is to understand the root causes Standish Group study Lack of user input13 % of all projects Incomplete requirements and specification 12% Changing requirements and specifications 12% At least a third dev projects run into trouble for reasons that are directly related to requirements gathering

Standish group also found that 9% of the projects in large companies were delivered on time and on budget 16% - in small companies also enjoyed similar success What were the primary success factors? Of all successful projects User involvement16% Executive management support14% Clear statement of requirements12%)

Other results ESPITI 1995 – based on 3800 responses The two largest problems

what is the conclusion based on those surveys?

The frequency of requirements errors Defect originsDefect potentials Removal efficiency Delivered defects Requirements Design Coding Documentation Bad fixes Total Both studies indicate that respondents feel that requirements problems appear to transcend other issues ---Delivered code Study by Capers Jones -- the likely number of potential defects in a dev project and the typical efficiency in removing those defects Requirements errors are the most common category of system development errors

The high cost of requirements errors (Davis, 1993).1-.2 requirements time.5 design 1 coding 2 unit test 5 acceptance test 20 maintenance Stages

If a unit cost of ONE is assigned to the effort required to detect and repair an error during the coding stage The cost to detect ad repair an error during the requirements stage is between times less The cost to detect and repair an error during the maintenance stage is 20 times more

The relative costs of various categories of errors and the cost of fixing them at different stages in the software lifecycle Requirements time Totally requirements errors Design time Errors occurred during development Requirements error somehow leaked into the design phase More expensive The design will probably have to be thrown away or reworked The true nature of the error may be disguised… they have got the wrong requirements

Tracking the details of the requirements errors The person may not be readily available May have forgotten May just had change of mind May have moved Leakage defect (Hughes Aircraft- study by Synder and Shumate) 74% discovered during requirements analyst 4% leak into the preliminary design 7% detailed design 4% maintenance

Depending on when and where a defect is discovered, times cost Respecification Redesign Recoding Retesting Change orders Corrective action Scrap Recall of defective versions of shrink-wrapped software and associated manual from users Warranty costs Product liability Service costs for a company rep to visit a customer’s field location to reinstall the new s/w documentation

Data presented demonstrates Requirements errors are likely to be the most common class of error Requirements errors are likely to be the most expensive errors to fix

Key points The goal of software development is to develop quality software – on time and on budget – that meets customers’ real needs Project success depends on effective requirements management Requirements errors are the most common type of systems development error and the most costly to fix A few key skills can significantly reduce requirements errors and thus improve software quality

Definitions What is a software requirement A software capability needed by the user to solve a problem to achieve an objective A software capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documentation

What is requirements management A systematic approach to eliciting, organizing, and documenting the requirements of the system, and a process that establishes and maintains agreements between the customer and the project team on the changings of the system

Anyone who has ever been involved with complex systems – knows that a crucial skill is to elicit the requirements from users and stakeholders Many requirements are likely to be associated with a system, it’s importance to organize Documenting the requirements is necessary – effective communication among the various stakeholders

What do these elements have to do with managing requirements Small project vs big project Two-person project 10 requirements 1000 requirements 300K requirements – a Boeing 777

Questions Which project team members are responsible for the wind speed requirements (#278), which ones are allowed to modify it or delete it? If requirements #278 is modified, what other requirements will be affected? How can be sure that someone has written the code in a software system to fulfill requirements #278, and which test cases in the overall test suite are intended to verify that the requirements have indeed been fulfilled?

Application of requirements management techniques Types of software applications IS and other applications developed for use within a company System developed and sold as commercial products Software that runs on computers embedded in other devices, machines or complex systems Systems applications Requirements management can also be applied to systems development consisting many subsystems and its interrelated pieces and parts

The road map Embarking on a journey to develop quality software - Many questions will arise Is this a need or a requirement? Is this a nice-to-have or a must-have? Is this a statement of the problem or a statement of the solution? Is this a goal of the system or a contractual requirement? Do we have to program in Java, says who? Who doesn’t like the new system, and where was that person when we visited here before?

We’ll need to understand where we are at any point in time Whom we are meeting What language they are speaking And what information we need from them to complete our journey successfully

The problem domain THE HOME OF REAL USERS AND OTHER STAKHOLDERS Different technical and economic background On rare occasion, they are just like us. Might be easier, might be difficult to handle They have business and technical problems Our problem to understand their problem in their culture, their language and to build systems that meet their needs

Stakeholder needs Our responsibility to understand the needs of users and other stakeholders whose lives will be affected by our solution As we elicit those needs, we’ll stack them in a little pile called stakeholder needs needs

Moving towards the solution domain Provide a solution to the problem at hand Focus on defining a solution to the user’s problem Computers, programming, OS, networks, processing nodes Apply all the skills we have learned

Features of the system State what you have learned in the problem domain and how we intend to resolve those issues via the solution Eg The car will have power windows Defect-trending charts will provide a visual means of assessing progress Simple descriptions, in the user’s language Feature is a service provided by the system that fulfills one or more stakeholder needs features

Software requirements Once feature set have been established and agreed with the customer Define the more specific requirements to be imposed on the solution Specific requirements is software requirements Software requirements

Subtle transition in our thinking in this process needs features Software requirements Problem domain Solution domain

Key points A requirement is a capability that is imposed on the system Requirements management is a process of systematically eliciting, organizing and documenting requirements for a complex system Our challenge is to understand users’ problem in their culture and their language and to build systems that meet their needs A feature is a service that the system provides to fulfill one pr more stakeholder needs A use case describes a sequence of actions, performed by a system, that yields a result of value to a user