Tuesday, 22 November 2011

week 8 (30/10/11)

updated Chapter 2 :
-Literature review

2.1 Definition of Viewpoint requirement
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
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
8. An engineering/networking viewpoint (domain)
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
7. Incompatibility with other software engineering

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

Oxford Dictionaries
1. facts provided or learned about
    something or someone : a vital piece of
2. what is conveyed or represented by a
    particular arrangement or sequence of
    things : genetically transformed
1. knowledge communicated or received
    concerning a particular fact or
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

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
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

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