Tutorial T07: Requirements-Based ProductFamily Engineering

Description:

Computer-based systems are increasing in volume, size and complexity as more peoplebecome aware of the opportunities they offer for improving many aspects of our lives.Reliability is also a crucial issue because the computer-based infrastructure of manyorganisations is mission critical. Interoperability is another factor as organisationswish to develop new systems, which interconnect with existing legacy systems. Yet althoughwe want bigger, better and more flexible systems, we also want lower costs and shorterdelivery dates. This tension is compounded by a serious shortage of skilled IT staff. Whenthe tension snaps projects overrun or are cancelled. The business case for reuse has neverbeen stronger.

A product family is a group of similar products within a market segmente.g. mobile phones, pensions or spacecraft control operating systems. To achievelarge-scale reuse within a product family, most product family methods advocate derivingimplemented reusable components from early lifecycle workproducts including requirements.If the requirements of a domain are not well understood, there is no basis for makingintelligent decisions on reusable system architectures, designs and components. Inaddition when a requirement is reused, the corresponding acceptance tests and acceptancetest plans and procedures can also be reused.

In building single systems the first task is to select desiredrequirements from the set of product family requirements. Existing methods do not provideprocess details for this task. To address this problem we have developed a method forrequirements authoring and management that describes how to produce a model of productfamily requirements; how to validate the product family model; how to generate a singlesystem model derived from an product family model.

A product family model consists of a pool of numbered, atomic, naturallanguage requirements, a domain dictionary and a set of discriminants. A discriminant isany requirement, which differentiates one system from another. The model contains allrequirements in all the existing systems in the product family and is constructed as alattice of parent-child relationships. The requirements in the model are all related toeach other in parent-child relationships or through their relationship with thediscriminants. A discriminant is the root of a tree in the lattice. The nodes below theroot are the variants. Requirements belonging to each variant appear in the tree beneaththe variant. Making choices at discriminant points drives selection from the model.Requirements belonging to the chosen variant appear in the single system model. Thisdiscriminant-based method gives superior performance than free selection.

The construction of a single system means selecting a valid combinationof desired requirements from the product family model. A valid combination is one in whichthe requirements selected satisfy any constraints imposed by the product family model.Before the selection of requirements for a new system begins we must be sure that theproduct family model is valid. A valid model can be characterised by the answering severalquestions including: does there exist a system which satisfies the relationships in theproduct family model? and what do these "valid" systems look like (i.e. whatrequirements do they contain)?

The tutorial presents the results of the method as it has been applied toProduct-Family Engineering of Spacecraft Command and Control Systems. It will alsodemonstrate a product family engineering software tool that will support the method.

Intended Audience: The tutorial is an in-depth treatment of building arequirements-based product-family model.. It is aimed at practitioners and academics whowant to achieve significant reuse and have an intermediate or advanced knowledge ofrequirements engineering, component identification and the problems of developing mediumto large computer-based systems. The audience does not need to know about the SpacecraftCommand and Control System used for the case study. Sufficient introduction will beprovided about this product for the audience to understand the principles of productfamily engineering.

. Class Size: Limited to 50 participants.

Instructors:

Dr Michael Mannion is a Senior Lecturer in SoftwareEngineering within the Dept of Mechanical, Manufacturing and Software Engineering, NapierUniversity, Edinburgh, Scotland, UK. He graduated with a BSc (Hons) in Computer Sciencefrom Brunel University in 1983 and later worked as a Programmer until 1985 at GEC MarconiRadar Systems, Chelmsford. Between 1985 and 1988 he completed a PhD in ArtificialIntelligence at Bristol University and between 1988 and 1992 he worked as a SoftwareEngineer for Praxis Systems, Bath, UK. In 1992 he joined Napier University as a Lecturer.Dr Mannion is the Group Leader for the Systems Engineering group. Professionally he is anactive member of the IEEE, ACM, and British Computer Society (BCS) and since June 1997 hasbeen chairman of the BCS Special Interest Group on Software Reuse. He has served on anumber of Program Committees including European Reuse Workshop and IEEE Conference on theEngineering of Computer-Based Systems.

Dr Barry Keepence is a Lecturer in Software Engineering within theDept of MMSE. He graduated with a BSc (Hons) in Electronics (1985) and PhD (1988) inRobotics from the University of Wales, Cardiff. Between 1988-1990 he was a SoftwareEngineer for Marcol Computer Systems Ltd, Bristol. Between 1990-92 he was a SoftwareDevelopment Manager at Cyberdrome Enterprises Ltd, and between 1992-94 he was a ConsultantEngineer at Vega Space System Engineering Ltd, in St Albans. He has served on a number ofProgram Committees including European Reuse Workshop and IEEE Conference on theEngineering of Computer-Based Systems. He is a member of the British National Space CentreSoftware Steering Committee and part of a UK Space Industry Trade Delegation to visit theUSA in October 1998.

Proposed Course Outline:

Content:

Requirements-based Product Family Modelling:

Product Family Models;Product Family Domain Dictionary; Reusing Requirements; Product Family Requirements;Requirements Attributes; Structuring Requirements; Requirements Specification; WritingReusable Requirements; Discriminant Types; Identifying Discriminants;

Product Family Requirements Definition:

Viewpoints; IdentifyingProduct Family Viewpoints; Documenting Product Family Viewpoints; Product Family ViewpointAnalysis; Linking Requirements.

Validating a Product Family Model:

Valid and Invalid Product-Familymodels, Formal Basis of Requirement Relationships, Proof of Product-Family Model Validity;Algorithmic and Computational Considerations.

Building A Single System:

Navigation through a Product FamilyModel; Selecting Requirements; Free/Directed Choice; System Validity; ComponentIdentification, Computational Tractability; Managing Change to System and Product FamilyModels, Product Family Model Ownership; System Procurement; Partnerships; Incentives.

Tool Support:

Current RE tools; A Product Family Tool using OfficeProducts; Relationship to CASE tools; Requirements Metamodel, Product Family ModelValidation Tool

Case Study:

Background; Description of Case Study; Criteria forEvaluation; Results; Lessons Learned.

Summary:

Review of work; Conclusions; Future Work

Schedule:

Content

Timing

Product Family Engineering

0900-0930

Introduction to Case Study

0930-1030

COFFEE BREAK

1030-1100

Product Family Models

1100-1130

Building a Product Family Model

1130-1200

Exercises

1200-1230

LUNCH

1230-1400

Validating A Product Family Model

1400-1430

Exercises

1430-1500

COFFEE BREAK

1500-1530

Building A Single System Model From a Product Family Model

1530-1600

Exercises

1600-1630

Tool Support

1630-1700

Lessons Learned

1700-1715

Summary

1715-1730