System Scope (1.)

Requirements as a key element (2.)

Requirements are the key elements in the system scope. Nearly all elements refer to single requirements. With this kind of reference each of the described changes will cause only a local refactoring. The system-vision is the only exception, as I suppose the system vision to be stable enough to be referenced. The requirements are described at a maximum level of abstraction to succeed with this balancing act concerning the system overview. Requirements have the following characteristics:

  1. They can clearly be identified and referenced (characterized by the stereotype <>).
  2. They are individually version-numbered (characterized by the stereotype <>). As versionable objects, requirements are implicitly changeable, too. Date of change and author are recorded.
  3. Title: Besides the ID, requirements also have a title. According to experience, the title often changes and is therefore not used for referencing.
  4. State: In this case the distinction between [premature, mature, deprecated] is sufficient.
  5. Optionally, the business value can put on record on the requirement level. This is useful for a prioritization of requirements that is independent from costs.

The following types of requirements can typically be distinguished:

Non-functional requirements (4.)

The source of non-functional requirements are often technical frame conditions (memory size, network bandwidth etc.) or performance specifications. A proven notation for non-functional requirements is the “Goal oriented Requirements Language Notation” (GRL). GRL allows to illuminate the “why” of non-functional requirements. In my opinion, that's helpful because the circumstances for e.g. “requests have to be answered in 50 ms” can be completely changed. Than it's helpful to know the why. Wikipedia: http://en.wikipedia.org/wiki/Goal-oriented_Requirements_Language

Use Case (5.)

Use cases are the classical representatives for functional requirements. Sources for functional requirements are the desired functional features or are derived from legal conditions (e.g. privacy). Use cases are closely associated with the budget sponsoring stakeholder. A use case describes how a system allows an actor to reach a target.

  • ID – the unique identifier, is given once at the beginning.
  • title – the title, a short summary
  • state – [premature, mature, deprecated]
  • actor – who is the agent
  • stakeholders And Interests – who is the stakeholder and what are his interests
  • normal flow – the normal case / GoodCase
  • alternative flow – if necessary, variations or errors

Who knows Use Cases will notice that the objective dimension is missing. In our case the overview dimension suffices in most instances. Wikipedia: http://en.wikipedia.org/wiki/Usecase

Aspect-oriented user requirements notation

A further helpful notation for functional requirements is the so-called aspect-oriented user requirements notation. With this notation the cross-sectional functional requirements can be described well. A typical example for such a cross-sectional requirement are e.g. the rights of roles or error logging. For further reading I recommend “Aspect-Oriented Software Development with Use Cases” by Ivar Jacobson & Pan-Wei NG or Aspect-Oriented User Requirements Notation - University of Ottawa (http://www.springerlink.com/content/252645l617782770/) by G.Mussbach.

System Interface (6.)

System interfaces are often derived from functional requirements. But interfaces can also have their origin in used external systems. Elements of an interface description are:

  • version: The version of an interface – because it happens that the interface of an external system is changing without considering the associated systems.
  • source: the source system
  • sink: the system that uses data
  • data Structure: data structure for the provided data
  • description: unstructured description – when information is provided/ fetched, quality of providing, validity period, error handling.

Tips for an efficient notation would be appreciated.

Acceptance test (3.)

In an acceptance test is described what has to be fulfilled that the requirement is seen as implemented. While requirements are expressed on a high level of abstraction as far as possible, important details can be described in tests. Examples of the test descriptions are in appendix in chapter 5.4, the associated acceptance test.

Requirements view (7.)

Views are used to structure requirements. Views correspond to printable documents, composed for the appropriate topic and target audience. In order not to land in the DRY trap, requirements are only referenced here. In order to not only have links in printable documents, a tooling is very helpful which can also display content of referenced requests, too (see appendix, 5.6 A view). In a further expansion stage, the possibility of an additional limitation on other structural elements is very useful (Title, Stakeholder,...).

DomainArchitecture (8.)

The domain architecture or professional architecture describes the differentiation of the technical problem. New findings that arise during analysis, trial or implementation certainly lead to a change in differentiation and structure in the domain architecture. To ensure that these changes do not have a massive effect on already existing requirements, the semantic link between requirements and the domain architecture is realized by means of requirements views. The elements used in the domain architecture like aggregates, entities, repositories, etc. are described in the Domain Driven Design.