Industry Keynotes
Agile Requirements Engineering, Rainer Grau
Abstract: Organizations work on different context levels. The project context targets the goal to develop the next version of product P or service. The portfolio context above projects defines the product or service roadmap and thus initiates the projects.
Portfolio management still often is bound to yearly strategy happenings and budgeting, based on track & control and insufficient feedback from projects. Typically a strict top down strategy implementation with all its drawbacks and impediments is established in organizations.
This classical portfolio management nowadays crashes with the mindset of agile development applied in projects. And how surprising: The link between these two context areas are requirements.
This talk proposes a lean and agile approach focusing on requirements engineering (RE). The merge of best and proven practices in RE with a lean and agile mindset while overcoming misunderstandings in agile development like “no documentation anymore” opens the chance to optimize the requirements-time-cost triangle – in close collaboration on both context levels, project context and the project roadmap context.
Rainer Grau has been working in IT for 22 years. His career steps are software engineer, software architect, project manager, requirements engineer, process consultant, instructor, coach, mentor, evangelist, supporter of the community.
He is member of the Executive Management Board at Zühlke in the role as distinguished consultant.
In addition to his job, he teaches Scrum, Lean Management and Requirements Engineering and Product Management at various universities, travels as a speaker at con-ferences, acts as 2nd Chairman of the International Requirements Engineering Board IREB and board member of the International Software Product Management Association, ISPMA.
Rainer Grau spends the remainder of his time with family, on racing or mountain bikes, and occasionally wind surfing, rock climbing or reading the latest novels by T.C. Boyle and Haruki Murakami.
Warning Signs for Requirements – On Trying to Measure the Quality of Requirements, Chris Rupp
Abstract: Requirements specifications must be of sufficient quality, as they are the foundation for further work in the project. Misunderstandings in this early phase of a project have drastic consequences for nearly all subsequent activities in regards of costs and quality. Therefore, you have to be able to define and assess the quality of requirements and of a specification without doubt. But what is the best way to do so?
Particularly for specifications that consist of natural-language requirements, it seems difficult to make a definite statement about their unambiguousness, consistency, identifiability or necessity.
Exactly this problem is solved by an approach that packs the quality of natural-language requirements into metrics and focuses on linguistic quality while doing so. The lecture addresses the following questions and offers possible solutions:
- How can the quality of a requirement be measured?
- Which metrics exist in this field and which target values are good?
- Which sample sizes make sense for specifications?
- Do I have to measure and assess different types of requirements (e. g. non-functional requirements, general requirements) differently?
- How to introduce an approach based on metrics in a company?
Chris Rupp Head SOPHIST (officially: founder and CEO), chief consultant, coach and trainer.
After 20 years of active involvement in the field of systems engineering I have gathered quite a nice collection: a company … 7 books … 40 employees … innumerable articles and lectures … and a lot of experience. This is presumably due to my passion for consulting – I have not only been managing personnel, challenging them and helping them develop their strengths, but I have also actively stayed in touch with the customer by working in and leading projects. It might also be due to a talent to gather the right team members around me. The vision that drives me is to put good ideas into practice in a way that gives developers, contract partners and users the certainty that they are dealing with a valuable, elaborate and beneficial product.
