D2.1 Requirements and Specification - CORBYS

D2.1 Requirements and Specification
spectrum of usage-context classes to be addressed by the target system.
Specifically in identifying all domain objects and actors and delineating the boundaries of roles and
responsibility spaces, rights/privileges for each actor and/or device in the domain, we are essentially
negotiating a phenomenological analysis of the domain with the users. By further specifying domain
knowledge, taxonomies and a tentative ontology for the domain and negotiating this with various user
communities, it is possible to conclude an appropriately partitioned ontology of the world of the users for
whom the system is intended. Such generalisation ontology serves as a values expression language of the
most-deeply-valued-needs for various usage-contexts.
Building on this increasingly deeper understanding paves the way for formalising the domain knowledge
structure including tacit knowledge, causal, process-related and structural knowledge thus adequately
specifying the domain knowledge structure. This comprises a most important element of the experientiallyderived
tactical/ strategic problem solving knowledge. The domain knowledge is clearly the provenance of
the various user-classes (as distinguished by their usage-contexts) who are to use the system in pursuit of their
everyday practice. It is these communities of practice who are expected to make available to the requirements
engineers and other stakeholders their domain knowledge so as to promote deeper understanding of their
domain requirements including end-to-end interoperability and meta-operability across all implicated entities
including legacy norms, processes, policies, etc. In eliciting the domain knowledge we can establish the goal
structures knowledge for the application domain.
UI-REF advocates that the requirements are classified into the following descending-order priority categories
for implementation; these range from mandatory, as the highest priority class, through to desirable, as the
medium priority class, to optional, the lowest priority class. Prioritisation of requirements is deduced from
careful analysis of user-stated priorities which can be aided also by a consideration of Purpose-Hurry-
Frequency Criteria set re degrees of intimacy and immediacy of the required services and patterns of
interactive online support required to facilitate the user’s life/work-style patterns.
The above priority levels are formally elaborated as a spectrum of target platform core affordances plus
additional ones as follows:
Mandatory – These are those core design features which are perceived by the majority of a user group as
offering the most needed added-value(s) and that can be accommodated by the target system. This category is
expected to include the selected functional and non-functional requirements (look-and-feel interfaces) that are
the common core to all the usage-contexts within the target usage spectrum; including features supporting
scalability, modularity and open design so as to enable the incremental evolution of the system to offer further
features to satisfy future requirements and customisation as appropriate.
Desirable – These are those features that are desirable, but not highest priority design features as candidates to
be accommodated as far as possible, within the resources and technological constraints appertaining to the
lifecycle of the project.
Optional – These are those features said by some users to be of the lowest priority and/or are anyway highly
contextualised to particular (sub)-sectors of the user group and as such falling into the less common, and/or
possibly more controversial and conflictual category.
Once the raw user-stated requirements are aggregated through all elicitation instruments, channels and
modalities, they have to be transcribed, tabulated and cross-checked to prune duplications and delete clearly
out-of-scope requirements. UI-REF promotes a negotiation-based resolution of requirements into the three
18