Effective Requirements Management – an overview Kristian Persson Field Product Manager, Telelogic Asia/Pacific.

Slides:



Advertisements
Similar presentations
© Telelogic AB Modeling DoDAF Compliant Architectures Operational Systems Technical.
Advertisements

EuSEC Tool Vendors Challenge Adie Ditchburn Jon Chard 19 Sep 2006.
Beyond “The System Shall...” A Journey from Good to Great Requirements.
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 1 Software Engineering September 12, 2001 Capturing.
HP Quality Center Overview.
Chapter 2 – Software Processes
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
1 Requirements Engineering – a brief review by Andy Gillies.
Development Processes UML just is a modeling technique, yet for using it we need to know: »what do we model in an analysis model? »what do we model in.
WKES 3202 SOFTWARE REQUIREMENTS ENGINEERING SEMESTER 1 SESSION 2004/2005.
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
Software Requirements
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
Business Area Analysis Focus: Domain View (selected business area) Goals: –Isolate functions and procedures that allow the area to meet its goals –Define.
Overview of Software Requirements
SE 555 – Software Requirements & Specifications Introduction
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Course Instructor: Aisha Azeem
Systems Engineering of Software-Intensive Systems 1.
Enterprise Architecture
Romaric GUILLERM Hamid DEMMOU LAAS-CNRS Nabil SADOU SUPELEC/IETR ESM'2009, October 26-28, 2009, Holiday Inn Leicester, Leicester, United Kingdom.
What is Business Analysis Planning & Monitoring?
Romaric GUILLERM Hamid DEMMOU LAAS-CNRS Nabil SADOU SUPELEC/IETR.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
المحاضرة الثالثة. 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.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Business Analysis and Essential Competencies
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Software Requirements Presented By Dr. Shazzad Hosain.
Software Requirements Engineering CSE 305 Lecture-2.
A GENERIC PROCESS FOR REQUIREMENTS ENGINEERING Chapter 2 1 These slides are prepared by Enas Naffar to be used in Software requirements course - Philadelphia.
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.
IT Requirements Management Balancing Needs and Expectations.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 4, Requirements Elicitation.
Approaching a Problem Where do we start? How do we proceed?
Lecture 7: Requirements Engineering
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Rational Requirements Management with Use Cases v5.5 Copyright © Rational Software, all rights reserved 1 Requirements Management with Use Cases.
SOFTWARE REQUIREMENTS Chapter 1 1 These slides are prepared by Enas Naffar to be used in Software requirements course - Philadelphia university based on.
1 ECCF Training 2.0 Introduction ECCF Training Working Group January 2011.
CSC480 Software Engineering Lecture 8-9 September 20, 2002.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
ICT EMMSAD’05 13/ Assessing Business Process Modeling Languages Using a Generic Quality Framework Anna Gunhild Nysetvold* John Krogstie *, § IDI,
Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Requirement Engineering Virtusa Training Group 2004 Trainer: Ojitha Kumanayaka Duration : 1 hour.
1 Chapter 8 Building the Analysis Model (1) Analysis Concepts and Principles.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
Ivar Jacobson, Grady Booch, and James Rumbaugh The Unified Software Development Process Addison Wesley, : James Rumbaugh's OOMD 1992: Ivar Jacobson's.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Requirements Analysis
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
 CMMI  REQUIREMENT DEVELOPMENT  SPECIFIC AND GENERIC GOALS  SG1: Develop CUSTOMER Requirement  SG2: Develop Product Requirement  SG3: Analyze.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Product Design Alternative Generation, Evaluation, and Selection.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
Software Engineering, COMP201 Slide 1 Software Requirements BY M D ACHARYA Dept of Computer Science.
Software Engineering Lecture 10: System Engineering.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity,
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
1 Software Requirements Descriptions and specifications of a system.
 System Requirement Specification and System Planning.
Systems Engineering Concept Model (SECM) Update
Object-Oriented Software Engineering Using UML, Patterns, and Java,
The Systems Engineering Context
Software Quality Engineering
Software Requirements
From Use Cases to Implementation
Presentation transcript:

Effective Requirements Management – an overview Kristian Persson Field Product Manager, Telelogic Asia/Pacific

© Telelogic AB 2 Agenda What is Requirements Management? Why Requirements Management? Key concepts –Quality and Requirements –Systems –Problem and Solution domain –Information traceability –Requirements and Modeling –Requirements Driven Development

© Telelogic AB 3 Requirements are Vital Requirements are a clear statement of objectives. Requirements state the initial problem and the need that is to be satisfied Requirements define the characteristics of the set of acceptable solutions Requirements also provide guidance in the selection of the most appropriate solution Therefore, requirements provide the map and compass

© Telelogic AB 4 Requirements Management NOT just a front-end activity Forms the back-bone of the WHOLE lifecycle –Cradle-to-grave, not just development activity Helps you focus on the most important objectives –Not all requirements are equal in cost, risk, benefit Saves money through EARLY defect identification –“Quality is free” (Philip Crosby) The more complex the system, the greater the need for requirements to be well managed (RMB-43)

© Telelogic AB 5 Requirements Management: Project Success Source: “Chaos Chronicles, III, 2003”.

© Telelogic AB 6 The Benefits of Requirements Management Satisfaction: real stakeholder needs met Integration: the pieces work together Testability: know what to test the product against Communication: developers have consistent ideas of what the product is for Visibility: managers can take a global view Change control: the impact of change can be assessed Quality: we know what quality means for the stakeholder Optimization: we build only what is wanted

© Telelogic AB 7 Quality and Requirements Quality: conformance to requirements Requirements management: delivering quality throughout the life-cycle

© Telelogic AB 8 What is a system? A collection of components (people or machine) – which co-operate in an organized way – to achieve some desired result. A system is more than the sum of its parts –it has emergent properties A system is always part of an enclosing system –systems of systems

© Telelogic AB 9 Simple System: a Cup Component: handleComponent: bowl Interface: to hand Interface: to table Interface: to mouth

© Telelogic AB 10 Enclosing system Environment : gravity

© Telelogic AB 11 Emergent Properties Properties not located in any particular component of a system, e.g. –Ability to float, or to fly Properties that depend on the way components interact, e.g. –Journey time from London to Glasgow –Reliability What about: –Weight? Question: what are the emergent properties of the cup?

© Telelogic AB 12 Problem and Solution Problem definition Specific solution Abstract solution Stakeholder Requirements System Requirements Design Risk of defining the wrong problem Risk of not meeting the requirements Changing design may not mean changing requirements Risk of unnecessarily constraining the solution

© Telelogic AB 13 Stakeholder requirements A description of the problem and its context Results that stakeholders want from the system Do not define the solution, other than for environment Quality of results Owned by stakeholders or their representatives (e.g. marketing) System requirements An abstract representation of the solution What the system does Do not define the design How well it does it Owned by systems engineers “The user shall be able to....”“The system shall do ….” Differentiating Problem and Solution ProblemSolution

© Telelogic AB 14 Results of mixing Problem and Solution Don’t understand the problem Can’t decide on functions Developers dominate Can’t do acceptance User and system constraints muddled Unclear ownership Disaster!

© Telelogic AB 15 Acceptance test validating the product Stakeholder Requirements The V-Model Statement of need Operational use satisfies Component Requirements Component test qualifying components Subsystem Requirements Subsystem test qualifying the subsystems satisfies System Requirements System test verifying the system satisfies

© Telelogic AB 16 Requirements at every level System Requirements Subsystem Requirements Component Requirements System test Subsystem test Component test Acceptance test validating the product verifying the system qualifying the subsystems qualifying components Stakeholder Requirements satisfies Statement of need Operational use

© Telelogic AB 17 Definition of Traceability INFORMATION TRACEABILITY: Understanding how information at a high-level is transformed into low-level. Understanding how needs are satisfied and qualified Principle underpinning: Programme management Accountability Audit trails Risk management Safety management

© Telelogic AB 18 Traceability allows analysis impact impact coverage derivation derivation coverage completeness relevance

© Telelogic AB 19 Acceptance test Stakeholder Requirements Impact Analysis Statement of need Operational use satisfies Component Requirements Component test Subsystem Requirements Subsystem test satisfies System Requirements System test satisfies validates What if … ?

© Telelogic AB 20 Acceptance test Stakeholder Requirements Coverage Analysis Statement of need Operational use satisfies Component Requirements Component test Subsystem Requirements Subsystem test satisfies System Requirements System test satisfies validates Complete … ?

© Telelogic AB 21 Life of a requirement statement Y Impacted? Drafted Proposed Approved –By customer –By supplier –By validation and test team Traced Reviewed –Accepted –Rejected Baselined

© Telelogic AB 22 Traceability view End-to-end visual validation in a single view User ReqtsTechnical ReqtsTest CasesDesign

© Telelogic AB 23 Systems Modeling Introduces formality into the definition of systems Specification and design visualized in diagrams Uses diagrams, not just pictures Definition of precise vocabulary across the system Means of reasoning about a problem and its potential solutions Multiple (interacting) aspects of a system are modeled Progressive refinement towards more detailed design Validation of some aspects of design through animation Encourages communication between different organizations through the use of common standard notations (UML2.0)

© Telelogic AB 24 Functional modeling Functional modeling Models Bridge Layers of Requirements Requirements layer Modeling layer Requirements layer Modeling layer Requirements layer Modeling layer Requirements layer e.g Goal / Usage modeling e.g. Functional modeling Stakeholder requirements Architectural design System requirements Statement of need Functional modeling e.g. Performance modeling

© Telelogic AB 25 Models and Requirements Models and Requirements complement each other Diagrams help clarify understanding of requirements Modeling can help identify gaps and misunderstandings A formalized but flexible graphical notation enables expressive, ‘people friendly’ diagrams DOORS/Analyst: integrated modeling with requirement management

© Telelogic AB 26 Requirements Driven Development Requirements must be captured and communicated to development. Design and functional requirements must be managed and linked to user requirements. Development activities must be driven from design and functional requirements. Relationship between requirements and development artefacts must be established and automatically updated.

© Telelogic AB 27 Requirements Driven Development Integrated Defect Management Requirements Driven Testing Optimizing Business Value of Development User Requirements Specification Functional Specification Design System Build Integration testing System testing Acceptance testing

© Telelogic AB 28 QUESTIONS?