1 Requirement Engineering Carsten Schmoll & Horst Rechner Fraunhofer FOKUS - FOKUSforum - Best Practices May 6., 2008
2 Requirement A requirement is " a singular documented need of what a particular product or service should be or do. It is most commonly used in a formal sense in systems engineering or software engineering. It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user." -[Wikipedia] Sets of requirements are used as inputs into the design, implementation and test stages of product development.
3 What is Requirement Engineering? Can be seen as transformation of the requirements of the client for his product (e.g. software) to requirements for the system development. see [Man04] p.54 Requirements engineering includes the analysis and management of the requirements using engineering techniques.
5 Why not just talk and start a cool product? "When we had lost our goal completely from sight, we doubled our efforts." -- Mark Twain. without an effective RE the developers will implement an imcomplete or wrong solution for the customer even with the most successful development techniques the customer will not want what you made extra work, hassles, complaints and other effects (loss of money, future projects) will probably be the result written facts are the key ("Worte sind Schall und Rauch")
6 Why Requirement Engineering? Projects are defined by the following criteria: clearly defined goal / result limited in money human ressources content individual high complexity system boundaries Dedicated requirement engineering helps to clearly define those criteria in their variant for the project. see also [Man04] p.22
7 Position of You in this Presentation Let's assume the following position: you shall make a FOKUS customer happy you need to find out what shall be made you need to tell the developers what to do you need to make sure the customer says: "cool, that's what I wanted!" in the end we will focus on Software as the product here presented hints can also work vice versa basic rules also applicable to generic (non-it) RE
8 The "Three" Sides of the Medal Engineering - what to do, how to do it Technical - what tools can support us Human - communication & politics not all can be learned from books only all three together make up very successful RE
10 Project Phases (Requirement engineering helps us here: ) Analysis Requirement Specification Software Design Implementation Test Maintenance see [Man04] p.47
11 Which documents should be created in every IT development project? (Requirement engineering helps us here: ) Calculation of costs Offer to the client Assignment by the client Requirement documentation Design documentation Testspecification Instruction manual Bill of delivery Acceptance protocol see [Man04] p.37
12 Phases of Requirements Engineering These phases are part of the RE process: (not necessarily one by one - they do overlap) Elicitation - gathering the requirements from stakeholders Analysis - checking for consistency and completeness Documentation / Specification Verification - making sure the specified requirements are correct Management - of the requirements. This includes: Technical documentation, Change Management Make it stick! - present it to customer Sync sync synchronize - as "close" as possible!
13 Kinds of Requirements Functional defines a the targeted behavior of the system based on black-box view of the system may also have pre- and post-conditions Non-functional = required constraints that "limit" the system design categories: technical - e.g. hwrdaware, OS, devices (screen) interface - e.g. color, text size quality - security or performance (e.g. reaction time) other delivery "parts" - e.g. training, support legal requirements - e.g. insurance, standards
15 Requirements Elicitation 1 Make and circulate a questions document only the right questions can yield useful answers don't expect everyone to read it though before you read it out aloud (see below) Get together with the customer if possible in any way do it in real life get the right stakeholders "on board" (note them down) be prepared about the project (learn about environment) bring the right questions with you (above doc) make current situation analysis there if not a new system define clearly the roles of involved "partners" + show them also check whom you don't need to ask/satisfy
16 Requirements Elicitation 2 Organise a workshop organiser brings the coffee ("feel good environment") keep the number of stakeholders limited be prepared for some level of conflicts among them too limit the number of your contacts afterwards even more
17 Requirements Elicitation 3 the "deepness" (= detail level) depends on many things level of the project (prototype, demo, 24/7 application) size of the project "closeness" of the customer style of development (waterfall, V-Model, UP, XP) less agile - more complete spec needed prioritize during workshop into: MUST / MAY / OPTIONAL tell participants which documents will be the output beware of implicit requirements ("such buttons should of course have been big, round and red")
18 Sophist Template For interfaces: Component A shall / should provide component B the ability to For functionality: Component A shall / should / will be able to shall - mandatory should - desirable functionality will - desirable functionality implemented in version Y see [Soph08]
19 Analysis Part of Workshop wrapup back at home summarize and cleanup answers and minutes taken note unclear points, missing items and risks in separate list or even separate document put the many tiny details into annexes circulate results openly, sync soon e.g. via telco clearly state system boundaries and non-goals boundaries will yield the system interfaces if needed make a glossar (sparsingly, not: complete) to fix the common terminology
20 Reviews of Requirement Documents By the customer to avoid situations like "You never asked us!" "Why didn't you inform us in time?" "We thought of this in a different way." To cover all feature aspects By the technical staff to avoid situations like "That is how I thought it would be right." "We never talked about this!" "This is not possible with our system design." To ensure that requirements and design are aligned Goal: Distribution of the resposibility see also [Man04] p.40
21 Documentation of Requirements Starting with an informal description doc/xls/odf templates available most companies have their own ones Later convert to formal description e.g. UML use cases, UML activity diagrams database systems help a lot to keep track for each requirement state the same attributes: identifier, short text, long text, author, initial date, latest change date, relation to other requirements, priority, riscs, release, status, questions, source allow the traceability of project progress - project mgmt.
22 Maintenance of Requirements Important during the complete RE lifetime reflect changes in your (office) documents make stakeholders aware of the latest version use simple to follow versioning scheme make documents easily available (svn) keeping track even more important during design and implementation phase (trac) many more tiny requirements visible here practice shows that 3% of all requirements change each month keep list of open questions and to-be-clarified items
24 Tools in Use (mostly open source) depends on the type, style and size of the project whatever makes both parties happy will do usually will be some office solution for the informal part don't use systems like trac to communicate with your customer use trac to track project progress for the 500+ tiny requirements which your developers crunch down one by one (see lecture "Best Practices For Java Projects") you will want to have "at hand": text processor, spread sheet, graphics app or flow charter, database, report generator, UML tools, groupware, a file repository, a ticket system (trac), Wiki
25 Test Director
26 Test Director - Requirement Documentation
27 Test Director - Test Planning (Verification)
28 Test Director - Testing (Verification)
29 Test Director - Defect Management (Verification)
30 Tips & Summary
31 Tips & Summary Document and Synchronize often among stakeholders! Don't try full RE the first time in a time critical project! Expect significant time overhead in your first try. But it will pay out in the long run. Don't expect immediate embrace by all stakeholders! No single (open source) tool which integrates all aspects of requirement engineering (Elicitation, Analysis, Documentation / Specification, Verification and Management) know to us. Commercial Toolchain (Integrator Fraunhofer IESE) The best tools are those which all involved people can work fluently with! (even if it is only MS Excel)
32 Further reading (only German) [Man04] Pascal Mangold, IT-Projektmanagement kompakt, Spektrum Akademischer Verlag, 2. Auflage, 2004 [Rupp08] Chris Rupp (SOPHIST GROUP), Systemanalyse kompakt, Spektrum Akademischer Verlag, 2. Auflage, 2008 [Rupp07] Chris Rupp (SOPHIST GROUP), Requirements-Engineering und Management Hanser Verlag, 4. Auflage, 2007 [Soph08] SOPHIST GROUP [FUBSWT08] Vorlesung Softwaretechnik FU Berlin https://www.inf.fu-berlin.de/w/se/vorlesungsoftwaretechnik
33 Thank you for your attention!
34 Additional Infos
35 Abstract Requirement Engineering deals with the gathering, analysis and documentation of requirements, their environmental conditions and the clients wishes for their product. There are many areas where requirement engineering can be applied: New projects, extension of existing projects / products, the setup of a new laboratory, the development / extension of software, even the preparation of a difficult dinner recipe for gourmets. A good project roadmap and its execution with effective requirement acquisition can avoid misunderstandings and excess work in later stages of the project and can lead to a measurable, consistent result. Associated topics are communication and documentation of planned and finished work items - which allows continuous progress control. In this talk we will give you practical advise on effective requirement acquisition, take a close look at the necessary tools and show you common pit holes.
36 Kano-Model cool features are much more fun than "open+save" support!
37 Requirement Elicitation Exercise Turm 1: Höhe an der Antennenspitze: 368m Kugel für Gäste mit Dreh-Café Aussichtsetage Durchmesser des Fußes: 32 m Durchmesser der Kugel: 40 m Material: Stahlbeton mehrere Aufzüge Geschwindigkeit der Aufzüge: 6 m/s Antennenanlage, Leistung bis 100kW Stromversorgung für Kugel Wasserversorgung für Kugel WCs in der Kugel Blitzschutzanlage Treppe im Inneren des runden Turmes Turm 2: dreieckige Form (v.d.seite) Grundriss quadratisch Stahlkonstruktion, genietet Aussichtsetage mit Café Höhe = 300m mehrere Aufzüge, mit Zwischenhalt am Café Geschwindigkeit der Aufzüge: 6 m/s Antennenanlage, Leistung bis 500kW Stromversorgung für Café Wasserversorgung für Café Blitzschutzanlage Treppe für Notfälle (Ausfall der Lifte) Play the client and have your colleague play the contractor who asks you questions. Afterwards let her/him paint what he/she thinks the tower looks like! Now compare with next slide - did your towers look similar?
USE-CASE 2.0 The Guide to Succeeding with Use Cases Ivar Jacobson Ian Spence Kurt Bittner December 2011 USE-CASE 2.0 The Definitive Guide About this Guide 3 How to read this Guide 3 What is Use-Case 2.0?
Rob Davis Everyone wants a good process. Our businesses would be more profitable if we had them. But do we know what a good process is? Would we recognized one if we saw it? And how do we ensure we can
Guide to Implementing Quality Improvement Principles Foreword Quality Improvement in health care continues to be a priority for the Centers for Medicare & Medicaid Services (CMS). In the Affordable Care
A Survival Kit for European Project Management Advice for Coordinators of Centralised Socrates Projects 2 nd revised edition: For projects of selection round 1-3-2002 and later Contributors: Editor: Holger
MISSION AND GOALS 34 3 DEVELOP A MISSION, AND GOALS When organizations or individuals decide to join forces and work as a partnership, they do so with a purpose in mind. While the individual partners may
Transforming software and systems delivery White paper May 2008 Tips for writing good use cases. James Heumann, Requirements Evangelist, IBM Rational Software Page 2 Contents 2 Introduction 2 Understanding
PLAN THE WORK Strategic Communication Planning for Not-for-Profit Organizations This handbook was produced by the Institute for Media, Policy and Civil Society for the Centre for Community Organizations
Outsourcing Workbook Page 1 Copyright 2008 Notice of rights All rights reserved. No part of this book may be reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, recording,
Table of Contents THE MASTERY LEARNING MANUAL CHAPTER 1 INTRODUCTION TO MASTERY LEARNING Introduction by Carla Ford 1 Perspective on Training: Mastery Learning in the Elementary School 2 CHAPTER 2 AN OVERVIEW
Stay on Track for the PMP Exam with layout, contents and the copyright notes remain unchanged. Items (questions with answering options) from this document may be copied and discussed in public forums and
SECTION 1: DEVELOPMENT POCESSES 1.1 PEFOMANCE MEASUEMENT POCESS 1.1 Performance Measurement Process Introduction Performance measures are recognized as an important element of all Total Quality Management
STRENGTHENING NONPROFITS: A Capacity Builder s Resource Library Measuring Outcomes TABLE OF CONTENTS INTRODUCTION... 4 OVERVIEW... 5 Why Measure Outcomes?... 5 What is Outcome Measurement?... 5 Some Words
Creating Mobile Learning 7 key steps to designing and developing effective mobile learning kineo Creating Mobile Learning Scoping and scheduling your mobile Step 1: 03 learning project Producing the overall
Course: Quality Management, DPT404 Teacher: Conny Johansson Department: IDE, University Of Karlskrona/Ronneby The V-Model Prepared for Conny Johansson Conny.Johansson@ide.hk-r.se IDE, University Of Karlskrona/Ronneby
E-LEARNING C O N C E P T S, T R E N D S, A P P L I C A T I O N S About Epignosis LLC. All rights reserved. Epignosis LLC 315 Montgomery Street, 8th and 9th Floors San Francisco, California, CA 94104 United
Audit Manual PART TWO SYSTEM BASED AUDIT Table of content 1. Introduction...3 2. Systems based audit...4 2.1. Preparing for & planning the audit assignment...5 2.2. Ascertaining and recording the system...7
Process mapping for microinsurance operations A toolkit for understanding and improving business processes and client value MICRO INSURANCE CENTRE Developing partnerships to insure the world s poor Process
So You Want to Do Anthropology in Your Library? or A Practical Guide to Ethnographic Research in Academic Libraries Andrew Asher ERIAL Lead Research Anthropologist Susan Miller Resident Anthropologist,
Top 10 Reasons Faculty Fail When Using Blackboard CMS Dr. Penny Johnson Computer Science Carroll College email@example.com Abstract In today s ever increasing world of information technology it is not enough