Defining the System Context

Posted on October 11, 2009 | Tagged as: , | 0 comments

Requirements for a system don’t appear from nowhere but must be identified systematically. The successful definition of the systems border and the resulting identification of relevant context aspects build the foundation for a professional evaluation of the requirements for the new system. If the context is not defined properly within the process of requirements engineering, the system relies on incomplete and inaccurate assumptions which might lead to a faulty behaviour.

The Goal of the context analysis is to separate the system from its environment and highlight those parts which are relevant and affect the requirements. Therefore, assumptions about how the future system will be integrated in its reality must be made. In order to fully and accurately identify the requirements, it’s necessary to find all relations between the system and its future environment.

System and context border

For defining the system context, it’s necessary to border it form the system and the irrelevant part of reality. Through system and context borders, the system context is defined. It covers all aspects which are relevant for the requirements and can not be designed during the development of the system. Therefore, two processes are defined:

Twilight area

Both bounderies mostly become precise not until the end of the requirements engineering process. Afore, some requirements are known only partial or not at all. This fuzziness results in a twilight zone that exists in different times throughout the engineering process. For example, at an early stage of the project, it might be unknown if a defined functionality must be implemented by the system or if it will be offered by an external system.

For the system border, this area might flow, considering aspects that are assigned to the context first and then move into the system itself. For the context border, this area flows if it’s not clear if certain environmental aspects influence the system or if they can be considered as irrelevant.

Documenting the context

Typically, the system context is documented by using use-case, data flow or class models. All three illustrate the different actors in the environment and their interaction with the system. For a complete documentation, different forms are used, highlighting changing perspecitves on the system and its environment.

No Comments to “Defining the System Context”

Comments are closed

agile brand development interaction design leadership mobile persuasion product management requirements engineering search seo service design system design testing user experience user story