Method for developing complex systems

• US 7,165,236 B2
• Filed: 03/08/2001
• Issued: 01/16/2007
• Est. Priority Date: 03/09/2000
• Status: Expired due to Fees

• Current Assignee: Koninklijke Philips N.V.
• Original Assignee: Koninklijke Philips Electronics N.V. (Koninklijke Philips N.V.)
• Inventors: America, Petrus Hubertus Maria
• Primary Examiner(s): Chaki; Kakali
• Assistant Examiner(s): VU, TUAN A
• Application Number:
  US09/801,602
• Publication Number:
  US 20010025236A1
• Time in Patent Office: 2,140 Days
• Field of Search: 717101-117, 717120-123, 707/4, 382/128
• US Class Current: 717/102
• CPC Class Codes: G06F 8/20 Software design

Abstract

A method for developing a family of complex systems having a common software architecture platform. The method entails forming a functional requirements specification (FRS) which includes use cases that describes interaction of users with said complex systems in terms of abstract concept and forming a requirements object model which explains the abstract concepts in terms of a structured vocabulary. The use cases are developed simultaneously with the requirements object model. The FRS specifies the interaction of the complex systems with their users, i.e., the FRS specifies the activities which are performed in the interaction of the complex systems with their users, i.e., ‘what’ the complex systems do. This is preferably done in terms of the use cases which are usually written in a natural language such as English. The requirements object model specifies the concepts to which the activities specified in the FRS relate.

Claims

1. A method for simultaneously developing a family of complex systems, the family having present and future members, the family having a common software architecture platform, the family of complex systems including a plurality of complex systems, the method comprising:

constructing an initial requirements object model which explains abstract concepts in terms of a structured vocabulary,

forming an initial set of use cases based on the initial requirements object model such that the use cases are expressed using the structured vocabulary of the requirements object model, the use cases describing interaction of users with each of said complex systems in terms of the structured vocabulary explaining the abstract concepts;

forming an initial functional requirements specification (FRS) which includes use cases,

forming an amended requirements object model based on the initial FRS and thus in consideration of the initial set of use cases,

forming additional use cases based on analysis of the amended requirements object model,

changing the FRS in light of the additional use cases,

forming another amended requirements object model based on the changed FRS simultaneously with the formation of the additional use cases,

repeating the additional use case formation step, the FRS changing step and the amended requirements object model formation step until all desired use cases have been formed and considered, and

obtaining a final requirements object model once all of the desired use cases have been considered,

wherein since the additional use cases are formed simultaneously with the formation of the amended requirements object models, the amended requirements object models are thereby formed during the formation of the functional requirements specification, and

wherein said method supports simultaneous development of several of the present members of said family of complex systems as well as later addition of the future members of the family of complex systems.

2. A method as claimed in claim 1, wherein the functional requirements specification (FRS) includes one or more chapters, further comprising:

establishing one or more FRS authoring teams for separate chapters,

designating a single object model control team to control internal consistency of the requirements object models,

forming one or more overlapping modeling teams where each modeling team includes members of the object model control team together with one or more members of respective FRS authoring teams, and

providing that overlapping modeling teams for their chapters construct use cases and provide respective portions of the structured vocabulary.

3. A method as claimed in claim 2, further comprising:

constructing the initial requirements object model in at least one of the modeling teams,

performing the FRS authoring of the use cases on the basis of the initial model, and

performing fine tuning of the use cases by the object model control team.

4. A method as claimed in claim 2, further comprising carrying out FRS authoring of the use cases of several chapters in parallel by the respective FRS authoring teams.

5. A method as claimed in claim 1, wherein the differences between the members of the family are expressed in the requirements object models using one or more of the following mechanisms:

specialization, wherein the differences between members of the family are expressed using subclasses of a generalized class,

multiplicity, wherein the differences between members of the family are expressed using different multiplicities in relationships between classes, and

attribution, wherein the differences between members of the family are expressed using different values for an attribute of a class.

6. A method as claimed in claim 1, wherein the complex systems are medical diagnostic imaging systems, notably, diagnostic x-ray examination systems.

7. A family of complex systems, notably a family of medical imaging systems, obtained by the method of claim 1, wherein separate complex systems support respective, different subsets of the use cases.

8. A method as claimed in claim 1, where the precise behavior of one or more use eases differs among members of the family according to variations expressed in the object model, notably by different subclasses of a general class, by different multiplicities of relationships, or by different values of attributes.

9. A method as claimed in claim 1, further comprising the step of expressing differences between the members of the family in the requirements object models using at least one of the following mechanisms:

different members of the family are expressed using different subclasses of a generalized class,

different members of the family are expressed using different multiplicities in relationships between classes, and

different members of the family are expressed using different values for an attribute of a class.

10. A method as claimed in claim 1, further comprising analyzing the requirements object models to identify difficulties and shortcomings, the requirements object models being amended in light of the identified difficulties and shortcomings.

11. A method as claimed in claim 1, further comprising considering the functional requirements specification complete when all of the use cases are expressed in the structured vocabulary of the final requirements object model.

12. A method as claimed in claim 1, wherein the use cases are formed using only the structured vocabulary of the requirements object models.

13. A method as claimed in claim 1, wherein formation of the amended requirements object models comprises changing the structured vocabulary.

14. A method as claimed in claim 1, wherein the use cases are expressed in natural language.