-Literature review
2.1 Definition of Viewpoint requirement
Author(s) | Definition |
B. Nuseibeh, J. Kramer, and A. Finkelstein. (2003) | Viewpoints approach is a method where an analyst gathers the fragments of the requirements of a stakeholder (or of a specific group of stakeholders) and integrates them. |
Andres Silva (2002) | Recognizes that there is a multiplicity of stakeholders that take part in a requirements process, inevitably leading to discrepancies between them. |
B. Nuseibeh, J. Kramer, and A. Finkelstein. (1992) | A viewpoint represents an engineering perspective, different viewpoints encapsulate different types of requirements model which are natural to different stakeholders. |
2.2 Viewpoint Requirement
Author(s) | Ian Sommerville and Pete Sawyer (1997) |
Type of Viewpoint | 1. Viewpoints associated with system stakeholders Informally, a system stakeholder is anyone who is, directly or indirectly, affected by the existence of a system. Hence stakeholders may be end-users of a system, managers of organisations where systems are installed, other human and computer-based systems in an organisation, external entities who have some kind of interest in the system (e.g. regulatory bodies, customers of an organisation which has installed the system) and engineers involved in the design, development and maintenance of the system. 2. Viewpoints associated with organisational and domain knowledge Organisational and domain knowledge is knowledge which constrains the system requirements. The constraints may be physical (e.g. network performance), organisational (e.g. incompatible hardware used in different divisions of a company), human (e.g. average operator error rate) or may reflect local, national or international laws, regulations and standards. This type of viewpoint cannot be associated with a single class of stakeholder but includes information collected from many different sources (people, documents, other systems, etc.) |
Range of viewpoints | 1. One or more customer viewpoints, depending on different types of customer such as business and personal customers (stakeholder) 2. One or more bank staff viewpoints covering the operation and management of the system (stakeholder) 3. A security viewpoint (stakeholder) 4. A marketing viewpoint (stakeholder) 5. A database viewpoint (organisational) 6. A personnel viewpoint (organisational) 7. A regulatory viewpoint (domain - banks have external regulators) 8. An engineering/networking viewpoint (domain) |
Disadvantages | 1. Inflexible viewpoint models 2. Fixed notations for requirements definition 3. Limited support for requirements evolution 4. Limited support for requirements negotiation 5. No industrial-strength tool support 6. No recognition of the problems of non-functional requirements 7. Incompatibility with other software engineering methods |
Classes of Viewpoints | 1. Interactor viewpoints These are the viewpoint of something (human or machine) which interacts directly with the system being specified. Examples include human operators who impose usability requirements or requirements for specific process support functions and external systems which impose compatibility and information exchange requirements. 2. Indirect stakeholder viewpoints These are the viewpoint of an entity (human, role or organisation) which has an interest (stake) in the problem but who does not interact directly with the system. Examples include operating organisations and standards/regulatory bodies. Indirect stakeholder viewpoints allow Preview to explicitly decouple requirements which might be generated by an operator from those which might be generated by the operator's organisational structure. 3. Domain viewpoints These represent a set of related characteristics of the domain which cannot be identified with a particular stake or interactor but which nevertheless impose requirements which are implicit in the domain. For example, requirements on a communication system may be imposed by signal propagation time in copper and optical cables. Because requirements arising from domain phenomena are often part of domain experts' knowledge, they may be overlooked if domain expertise is unavailable or poorly utilised. The use of viewpoints to represent domain phenomena provides a defence against this. |
2.3 Definition of Information
Source(s) | Definition |
Oxford Dictionaries | 1. facts provided or learned about something or someone : a vital piece of information 2. what is conveyed or represented by a particular arrangement or sequence of things : genetically transformed information |
Dictionary.com | 1. knowledge communicated or received concerning a particular fact or circumstances 2. knowledge gain through study, communication, research, instruction 3. the act or fact of informing 4. an office, station, service, or employee whose function is to provide information to the public |
2.4 Definition of Architecture
Source(s) | Definition |
ANSI/IEEE Std 1471-2000 | 1. The set of plans that describe how all parts of the IT infrastructure need to behave to support the enterprise needs and goals. It includes all the data required to run the enterprise and the functions, technology and problem that create, access, use or transform that data into information and ultimately, knowledge for the business. 2. The fundamental organization of a system embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution |
Micheal Platt (2006) | The use of abstractions and models to simplify and communicate complex structures and processes to improve understanding and forecasting |
2.5 Definition of Information Architecture
Author(s) | Definition |
Henric Beiers (2000) | Information architecture could be defined as the art and science of organizing information to maximise its accessibility and usefulness. |
Heather McNay (2003) | Information architecture is the construction of a structure or the organization of information. |
Rafidah Abd.Razak, Zulkhairi Md. Dahalin, Rohaya Dahari, Siti Sakira Kamaruddin, Sahadah Abdullah (2007) | Information Architecture is used to identify major information category used within an enterprise and their relationship to their business processes. |
No comments:
Post a Comment