Abstract functional requirements The basic functions that the system must provide are defined at an abstract level. More detailed functional requirements specification takes place at the sub-system level. System properties These are non-functional emergent system properties such as availability, performance and safety. Characteristics that the system must not exhibit It is sometimes as important to specify what the system must not do as it is to specify what the system should do. An important part of the requirements definition phase is to establish a set of overall objectives that the system should meet. These should not necessarily be expressed in terms of the system’s functionality but should define why the system is being procured for a particular environment. Figure 2.3 The system design process A fundamental difficulty in establishing system requirements is that the problems that complex systems are usually built to help tackle are usually problems’. A problem’ is a ‘wicked ‘wicked problem that is so complex and where there are so many related entities that there is no definitive problem specification. System design System design (Figure 2.4) is concerned with how the system functionality is to be provided by the components of the system. The activities involved in this process are: 1. Partition requirements:You analyse the requirements and organise them into related groups. There are usually several possible partitioning options, and you may suggest a number of alternatives at this stage of the process. 2. Identify sub-systems:You should identify sub-systems that can individually or collectively meet the requirements. Groups of requirements are usually related to so this activity and requirements partitioning may be amalgamated. However, sub-system identification may also be influenced by other organisational or environmental factors.
Abstract functional requirements The basic functions that the system must provide are defined at an abstract level. More detailed functional requirements specification takes place at the sub-system level. System properties These are non-functional emergent system properties such as availability, performance and safety. Characteristics that the system must not exhibit It is sometimes as important to specify what the system must not do as it is to specify what the system should do. An important part of the requirements definition phase is to establish a set of overall objectives that the system should meet. These should not necessarily be expressed in terms of the system’s functionality but should define why the system is being procured for a particular environment. Figure 2.3 The system design process A fundamental difficulty in establishing system requirements is that the problems that complex systems are usually built to help tackle are usually ‘wicked problems’. A ‘wicked problem’ is a problem that is so complex and where there are so many related entities that there is no definitive problem specification. System design System design (Figure 2.4) is concerned with how the system functionality is to be provided by the components of the system. The activities involved in this process are: 1. Partition requirements:You analyse the requirements and organise them into related groups. There are usually several possible partitioning options, and you may suggest a number of alternatives at this stage of the process. 2. Identify sub-systems:You should identify sub-systems that can individually or collectively meet the requirements. Groups of requirements are usually related to so this activity and requirements partitioning may be amalgamated. However, sub-system identification may also be influenced by other organisational or environmental factors.
10IS51_NOTES.docx